dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

2011/8/27 Jason Pickering <jason.p.pickering@xxxxxxxxx>:
> Hi Lars,
>
> 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.

OK

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




Lars