Tuesday, January 23, 2007
New Authorization model for upcoming 2.1 release
In the January 2007 newsletter, I mention the changes in the QVCS-Enterprise authorization model coming in the 2.1 release (release date tentatively scheduled for March 16). I thought I'd supply a few more details here.
The basic idea is that each server action has an associated privilege. If any of the roles that a user has been assigned has the privilege to perform the given action, then the server will permit the user to perform the action. If none of a user's roles has privilege to perform the action, then the server will not allow the user to perform that action.
Already existing roles (READER, WRITER, and PROJECT_ADMIN) are carried forward to the 2.1 release so that existing users can migrate to 2.1 without making any changes; a user with the READER role will see the same restrictions as with the 2.0 releases.
The table below lists different privileges/actions -- i.e. these are the actions that can be enabled/disabled for each separate role (this list is not yet complete, as it is missing the new actions for directory meta-operations like directory rename, or directory move):
| Action | Description |
|---|---|
|
(Admin tool): Assign user roles |
Use the admin tool to define the set of roles associated with a given user. For example, assign roles READER and WRITER to userA. |
|
(Admin tool): List project users |
Used by the admin tool. Determines whether user can list the users associated with a given project. |
|
(Admin tool): List user roles |
Used by the admin tool. Determines whether user can list a user's existing roles. |
|
(Admin tool): Maintain project |
Used by the admin tool. Determines whether a user can perform project maintenance type actions. For example, this privilege is required in order for the user to change the reference file location for a project. |
|
Get file |
Allows user to view a project, and to retreive files from the server. |
|
Get directory |
Allows user to perform a directory level 'get'. |
|
Check out |
Allows user to checkout a file. |
|
Check in |
Allows user to checkin a file. |
|
Lock |
Allows a user to lock a file. |
|
Unlock |
Allows a user to unlock a file. |
|
Break lock |
Allows a user to break file locks, i.e. with this privilege, a user can break a different user's lock on a file. |
|
Label |
Allows a user to apply a label to a file. |
|
Label directory |
Allows a user to apply a label at the directory level. |
|
Label at checkin |
Allows the user to apply a label at checkin time. A user needs this privilege (along with the check in privilege) in order to apply a label at checkin time. |
|
Remove label |
Allows a user to remove a label. |
|
Remove label from directory |
Allows a user to remove a label at the directory level. |
|
Rename file |
Allows a user to rename a file. |
|
Move file |
Allows a user to move a file from one directory to another. |
|
Delete file |
Allows a user to delete a file. |
|
Set file attributes |
Allows a user to set the QVCS archive attributes for a QVCS archive file. |
|
Set comment prefix |
Allows a user to set the comment prefix for a QVCS archive file. |
|
Set file description |
Allows a user to edit the file description for a QVCS archive file. |
|
Set revision description |
Allows a user to edit a revision description. |
|
Create archive |
Allows a user to create (i.e. add to version control) a QVCS archive file. |
|
Add directory |
Allows a user to add a directory to version control. The directory's parent directory must already be under version control. |
There will likely be added privileges for move directory, rename directory, and delete directory.
The cool thing about this approach is that the ADMIN user can now define new roles and associate appropriate privileges with those new roles. For example, it might be useful to define a TESTER role, and assign that role 'Get file', 'Get directory', 'Label' privileges. Another useful role might be JUNIOR DEVELOPER that had the 'Get file', 'Get directory', 'Lock', 'Unlock', 'Check out', and 'Check in' privileges. With the 2.1 release, the ADMIN user will be able to define and maintain these role definitions.
Beefing up the authorization model had been in the back of my mind since the early days of Enterprise. The pleasant surprise was that I was able to do it without breaking the existing authorization model.
Wednesday, January 10, 2007
Rename reprise
Since back from Florida, I've focused on putting the rename feature into QVCS-Enterprise. Along the way, I've discovered that what I had thought was a simple problem is more complex. As is often the case with software design, the devil is in the details, or put another way, it's always the boundary use cases that kill you.
In this particular circumstance, the boundary use case that I've been struggling with goes something like this:
- You have a file that has a label that points to some existing revision within that file.
- You now rename (or move) that file.
- You now need to create a patch build based on the label described in step 1.
The usability problem is that after step 2, the file now has a different name, or lives in a different directory.... yet to create your patch build, you want to be able to see the world as it existed before the rename occured in step 2, i.e. you want to see the file as it existed before the rename (or move).
Other version control tools that I'm familiar with get around this problem by using a 'view', or 'sandbox', or some similar method to virtualize the user's way of looking at the files of a project.... and I'm thinking that a similar approach may be the only way to avoid user confusion.
The challenge is to make things dirt simple to use and to understand.
