Overview¶

Ideas¶

Model Draft¶

Notes¶

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

Objects¶

the data model should consist of the following elements:

• organisational unit
• person
• role
• information set (better: information sets)

Motivation¶

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. this way fluctuations in the organisation (team members move to other teams, new coworkers, etc) are easy to manage.
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 sets 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 sets. (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. the member whould then be assigned to different roles in possibly two different organizational units.
every role is part of at least one organisational unit. information sets are attached to roles as well.
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.

information set¶

information set are information capsules that can be attached to every unit, person or role. information sets 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 sets can and should be easily extendable. this way we could eg create a information set 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. Basic mapping between properties, groups and containers (or whatever elements the directory service provides) is possible.

Frontend Plugins¶

It will be possible to display informations for organizational units (contact, members, etc), persons and roles. The plugin configuration could be quite similar to tt_news.

Backend Management¶

It would be favourable to use the information from the directory services 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". likewise roles are attached to organizational units and persons are attached to roles.
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.