Overview¶

Ideas¶

Model Draft¶

(this is a summary of what uschi and adrian drafted, just to publish our wishes, needs and ideas somewhere.)

the data model should consist of the following elements:

• organisational unit
• person
• role
• information object

motivation for this abstraction was derived from the fact that in both university we've got people working in different position (with different office hours, postal and email addresses). if we use the person-role-organisation paradigma, we can abstract the organizational structure enough. fluctuations in the organisation (team members move to other teams, new coworkers, etc) are easy to manage this way. german university really like their workgroups. every 6 months members change and roles can differ.
using roles also enables us to filter people based on their function. with a role "coordinator" in the unit "language center" i can add contact informations on one page without having to know or care who really fulfills this role.
i've posted two links in the last section of this topic

organisational unit¶

a organisational unit object stores data about every organisational unit in the framework. an organisational unit is a collection of persons and roles. an arbitary number of information objects can be attached to an organisational unit

person¶

a person is a living human being that is a member of a organisation. every person is a member of at least one organisational unit, can have an arbitary number of roles and information objects. (instead of allowing direct associations between persons and organizational units, it would be more flexible and clean to add a dummy role "member" to every person and attach that role to the organizational unit.)

role¶

every person acts in different roles. a role is a defined as a situational context where the actions and responsibilities of a person are different. eg in one context a member of an organisation is the leader of a project group, in another he is a developer. every role is part of at least one organisational unit. information objects are attached to roles as well.

information object¶

information object are information capsules that can be attached to every unit, person or role. information objects keep attributes of that element (abilitites, skills, names, addresses, etc). to keep the party management framework adaptable to a different number of situations, these information objects can and should be easily extendable. this way we could eg create a information object that stores different projects or publication of a person.

Links¶

http://dn.codegear.com/article/29678
http://step-10.com/SoftwareDesign/ModellingInColour/index.html

Sync'ing¶

for us it's important to be able to sync the elements from a directory service.

Frontend Plugins¶

Backend Management¶

It would be favourable to use the information from the directory services in use as a basis for the organizational modelling effort. An additonal backend module displays the organisation in a pagetree-like view. at the top is our organisation (or organisations). organizational untis are attached to these "root organisations".
If the user clicks on an organizational unit, role or person the "workspace" (right part of TYPO3's gui - what's it actually called?) displays information similar to how it's done in the current svn version.

Attaching a role to a user would involve dragging the person object onto the role (again: like in the pagetree). A context menu pops up and the user can confirm the assignment.