[Zope] HR Department Org Chart

[Chris McDonough]

> 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