UU.NL HOME cs.uu.nl

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
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

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:

duties

Burocrats can delegate responsibility to sub-burocrat by creating a duty. A duty contains : A burocrat can only appoint sub-burocrats for (sub-)organisations.

tasks

Burocrats appoint admins by creating tasks. A task contains :

UU CS INFO FIND INDEX
penning@cs.uu.nl, Mon Jan 23 10:16:38 MET 2006