I recently worked on an installation of ORS where the
administration wanted to give certain users permission
to sign up during business hours (when supervision was
available) and other (more experienced) users
permission to sign up at any time. These were called
'day users' and 'night users' respectively. A user
could be a night user on one resource and a day user on
another resource, so this distinction was made within
the permission block.
We probably should have something that provides similar
functionality in ORS. To make this reasonably
configurable may require substantial database
modifications because we don't want to limit people to
two user classes and we may want more than allowed
signup times to be configurable (an administrator may
want certain user classes to be exempted from certain
rules, for example). We will need to discuss just how
fine-grained the controls are.
A few questions:
Should we have resource-specific user classes, global
classes, or both?
Which rules should be included in each user class?
Should we also add the ability to create
resource-specific administrators and calendar
authorities along with this?
I have a feeling that there should be both global and
resource-specific classes. In the interface that will
be used to create the classes, we could have an
administrator select which resource(s) the class should
apply to. I think we should also allow as much control
as possible with the classes; administrators should be
allowed to override most of the scheduler rule
definitions with user classes.
In addition to this, I think we should add the ability
to limit user signup times. This would be a great
opportunity to add that functionality. The time limits
should be fully configurable; administrators should be
able to select how much time a user can have per any
interval (and multiple intervals should be allowed).
This way, one could limit users to 2 hours a day but
maybe 8 hours per week and no more than 20 hours per
month. Administrators should be able to apply these
limits for individual resources as well as the entire
scheduler. Finally, there should be hard limits and
soft limits so if a user really needs to exceed their
limit, they may be allowed to do so (up to a certain
point) with a reason.
These features could add a great deal of complexity to
the program but these kinds of controls are important
for using ORS in a high-usage environment where direct
administrative supervision needs to be kept to a
minimum due to cost.
Logged In: YES
user_id=829347
While we are thinking about this we should also consider the
implications for people who want to use LDAP. I think the
Mantis bug tracker (SF project mantisbt) has user access
levels and it also offers LDAP authentication. Perhaps its
database design would offer some insight into how we should
continue.