delegation of responsibility

In every organisation, the CEO can't do everything by himself, so he/she delegates responsibility to other people, and so on.

Here we look at the problem in a formalised world, the problem of managing objects in a database with a set of actions.

what we have

Lets assume we have

• an hierarchical organisation of people (users),
• responsibility domains : vacancies, leave of absence, hardware,
• a database managed by controllers with actions on objects,
• burocrats : people who delegate responsibility by appointing other burocrats.
• admins : people who perform certain actions on objects ; admins are appointed by burocrats.

For the sake of simplicity, lets assume there is only one responsibility domain. Lets also asume there is a root-burocrat, the root of the burocrat hierarchy. The admins are the leaves in the burocrat hierarchy.

Lets assume the action determines that only appointed admins are allowed to execute them. The controller for the action must determine if the user attempting the action has the appropriate authority.

what's the problem ?

The objective is to enable admins to manage only a limited set of objects. We must be able to

• let admins navigate a set of objects they are allowed to manage
• determine if a selected object may be managed by a given user

solutions

Lets try a few ideas.

1. admins own objects
   That would work. However, what happens if the admin responsibility moves to another user? It could be solved by role accounts, but that would be cheating and cumbersome for the people involved.
2. burocrats own objects
   This has the same problem as the previous idea.
3. organisations own objects
   If all manageble objects contain a reference to an organisation, we would have a hierarchical partioning of the objects: an organsation owns the objects in its organisation subtree. An admin would manage all the objects owned by an organisation (or more than one ?). A burocrat appoints admins for organisations. That seems neat.
4. buros own objects
   The problem with the previous idea is that the organisation tree can change, and so, organisations may disappear. Of course we could let a (remaining) parent organsation inherit the objects, but it would be a hassle.
   We could set up a separate responsibility domain tree (a burocracy of buro's where
   • burocrats are linked to a buro ; and can create sub-buro's,
   • objects are owned by a buro
   • admins manage objects is a burocracy.
   This would also structure the responsibility domain namespace into a tree.
   A DAG (directed acyclic graph) would be even nicer because it would retain the notion of a ownership subtree for admins, while allowing a kind of multiple inheritance for authority (leave/*/totals, where * = cs,math,fi,..)

Number 4 seems to complicated ; let's go for number 3, and facilitate changing ownership of (typed) objects from one organisation to another.

responsibility domains

Responsibility domains are created by root. They contain:

• a name
• a description

duties

Burocrats can delegate responsibility to sub-burocrat by creating a duty. A duty contains :

• a responsibility domain
• a link to the sub-burocrat
• a link to an organisation, limiting the duty
• a link to the burocrat who created the duty

A burocrat can only appoint sub-burocrats for (sub-)organisations.

tasks

Burocrats appoint admins by creating tasks. A task contains :

• a responsibility domain
• a link to a person (the admin)
• a link to an organisation (this determines the set of of objects that the admin can manage)
• a link to the burocrat who created the task