I am getting ready to build an Organizational Chart 'product' within Zope. Since I still consider myself somewhat of a newbie I'm actually trying to plan this thing before I dive into building it (I know that is a scary thought ... trust me, I usually just dive right into things without thinking ... so I am in new territory here <g>)
Cool.
Since several of you have MUCH more experience with Zope I'd like to throw out some ideas with the hope that those of you who have mastered the Zen of Zope can share some of your wisdom. Of course if I do manage to make something of this it'll show up on the Zope site.
THE STRUCTURE
I am planning on a structure similar to the following
/OrgChart - - - - /DeptHead1 - - - /Manager1 - - - /surf1 /peon2 /slave3 /Manager2 - - - /Moe /Curly /Larry etc, etc, etc
I do not see any difficulty with being able to display the charts using the tree functionality. I'm pretty comfortable here.
I would like to be able to have DeptHeads and managers be able to add/delete/edit any objects below them. I am assuming that this will be handled fine through local roles. Does anyone see a problem with this?
Nope... except that it might be a pain to continually administer. An alternative might be to make the leap of faith that the department heads and managers are responsible enough to not delete or otherwise change the information contained in the a subtree that doesn't belong to their department or subdepartment. That way, you could avoid the use of local roles and just give all department heads the "Department Head" and "Manager" roles, and all managers the "Manager" role. Then within the object tree, in your example, you could assign the "delete object" and other pertinent permissions to the user-defined roles "Department Head" and at the departmenthead-related folder level. Likewise, you could assign the same kinds of permissions to the "Department Head" and "Manager" roles at the manager-related folder level. It would mean that: a) Department heads could change all items in their department and their subdepartments. b) Department heads could change all items in other departments and their subdepartments. c) Managers could not change any items at or above the department level (e.g. PARENTS[1]). d) Managers could change all items in their subdepartment. e) Managers could change all items in other subdepartments. This may or may not be acceptable for your requirements. But I imagine you'll find it convenient when people actually use the thing and find that they can rely on each other to change information more flexibly. It won't defeat stupidity or malice on the part of the managers or department heads, but it would make it a lot more usable.
This one has me stumped and am hoping that it is just brain fart. If I have user (employee) log on at the root, but would like for them to be able to edit/manage their own editable information... given the structure above, how do I find their resource. I'm looking for something similar to what the Zope site has for editing /Member/username, however that is a flat structure. I understand how to find things UP a tree structure, but how would I find something DOWN the structure. Do I have to make this thing ZCatalog aware, or can I just use the standard ZCatalog indexing? I think I am making this too difficult, but am stumped.
This is a place where I think local roles could probably be used pretty effectively. For each user instance in the ZODB, script the administration system so that it assigns the "owner" local role to the username which that object represents. Then give the "owner" local role all permissons to the object. This way normal peons can edit their own info, but can't edit anything else. The owner local role is created automagically when an object is created (as of Zope 2.X, I think). Depending on how big the org chart will be, I think it would be wise to *plan* for some sort of find feature (e.g. if you're using ZClasses to represent the employee objects, make them CatalogAware -- actually, does CatalogAware still exist??), but I don't think its necessarily required. You could just let the user find him or herself by using the tree tag. You may also want to provide for a way that managers and department heads can assign peons local roles that give them "administrative access" to the tree... the managers and department heads aren't going to want to edit this information themselves, they'll want to hand it off to somebody else. But that's your call.
If there is employee information which can be edited, would it make sense to have this information stored as properties to 'username' or should I create separate standard DTMLDocuments which can be edited by the user? I'm going to want to hide even the 'Zope' interface from these users as much as possible.
You should probably implement all of the object types you've described (e.g. Department Head 1, Manager 1, peon1) as ZClasses. Instances of ZClasses can have properties just like DTML documents and folders and the like. Plus they are "smart", meaning that if someone calls the URL "OrgChart/Department_Head_1/Manager_1/peon1", you can make the object render itself any way you like. Plus you can give them your own cool icons that show up in the Zope management interface :-).
If a user wants to build a 'homepage' off their directory using a 'web design tool'. Is there a way to create a 'virtual' or 'aliased' directory structure based on userid? Right now, the current FTP server that I am using lets me alias an n-deep directory structure and map to a single root level directory based on userid. It's pretty cool.
Based on this requirement, you might want to model all of those classes you've described as "folderish", meaning that they will inherit the characteristics of the "ObjectManager" class. Then you can do whatever you like in the ZClasses, including providing a method for people to create new stuff inside the object that represents "them" using the Zope management interface (ala "OrgChart/Department_Head_1/manage" or "OrgChart/Department_Head_1/Manager_1/manage", etc.)
I think I understand everything else that I need. Thanks in advance for your wisdom ....
I hope you're using the word "wisdom" loosely :-). Good luck! Chris McDonough mailto:chrism@digicool.com Digital Creations http://www.digicool.com Publishers of Zope http://www.zope.org