OK, I guess this sort of makes sense, but to which administration unit
should an administrator "belong" to? The "topmost" orgunit?
Yes in my opinion it makes sense to use the topmost/root orgunit. The
administrator is to supposed to be able to perform all kinds of
operations in the system and hence must have access to all org units.
I suppose it might make sense to delete a user entirely , which what
happens if you want to see who last modified a data value, but the
user has been deleted? Isn't it best to "deactivate" them (which does
seem possible) and/or deassign them from all orgunits (which also does
not seem possible)?
The link between data values and users is currently simply text-based
so nothing ugly happens, you only loose the information of which user
saved the value. We should really make this a foreign key rather.
To cater for this I suggest we rather create a function and a property
"disabled" on User. A user can be disabled, if so we simply deny that
user to log in.
The bug can be reproduced by "TRUNCATE usermembership" of less drastic
means, such as deleting all orgunit associations of a particular user
from the "usermembership" object.
In this case, I am sure it was a result of truncation of the
"usermembership" table, which I needed to populate though an external
Excel file which provided the orgunit/user associations, and was
transformed to SQL . However, some users were not associated with any
orgunits (yet) and other users did not make sense to associate with
any orgunits (such as administrators). I suppose I need to either
remove these users, or assign them "some" orgunit, although they do
not really have any at the moment.
I guess the "root orgunit" property should really be an attribute of
the user and should be set to NOT NULL?
What are the implications if a user is associated with multiple
facilities (lowest orgunit level) which exist in multiple districts
but has no true "root"?
A user has a collection of org units (roots). This implies that the
user has access to those org units and each of the sub-trees. The
origin of the many-multiplicity was a requirement from India where
some officers were in charge of multiple districts. One wanted to give
access to those districts with its facilities but not to the province
above. It does not really makes sense to assign org units from
multiple layers, and we should enforce this better in the system.
Anyway, the org units assigned to a user will all appear in the tree
as roots. So in your example you will simply see those facilities
alone in the tree area.
2011/8/27 Jason Pickering <firstname.lastname@example.org>: