Forum .LRN Q&A: dotlrn department and subject adminstration and user assignment

1: dotlrn department and subject adminstration and user assignment

Posted by Peter Alberer on 08/16/02 12:30 PM

Having tried dotlrn for a few days i wonder if there is any possibility to assign users to departments or subjects and give admin rights to them. It seems as if site-wide administrators are the only ones who can create new subjects for a department and new classes for a subject.

Probably there are people responsible for a department that could be delegated these adminstrative rights.

Is there currently a way to give admin rights to not-site- wide-admins or is something like that planned?

2: Response to dotlrn department and subject adminstration and user assignment (response to 1)

Posted by Peter Alberer on 08/17/02 10:25 AM

I noticed that the class-instance administration uses a special community-admin.tcl file while the rest of dotlrn administration uses files in the /dotlrn/admin directory. The files in /dotlrn/admin require admin rights on the whole /dotlrn hierarchy. This indicates that everyone who wants to do any adminstrative work (besides class-instance administration) has to be a site-wide dotlrn admin. Is this not quite hindering when dealing with an academic institution that has a lot of departments and classes?

3: Response to dotlrn department and subject adminstration and user assignment (response to 1)

Posted by Arjun Sanyal on 08/20/02 04:46 AM

yes, the department concept is not as useful as one would expect. currently there is no way to delegate the admin of one department to a user. it's all or nothing. departments currently serve as an organizational tool for classes, but you are correct, in a setting where one dotlrn instance would be used by many departments such delegation would be handy. there's no "quick fix" to this, but we can start thinking about how to impliment this the right way.

4: Response to dotlrn department and subject adminstration and user assignment (response to 1)

Posted by Dan Wickstrom on 08/20/02 05:53 AM

This seems odd. The groups functionality of openacs is fully capable of supporting a delegated admin function for an individual department. Was it originally felt that department admin rights were not useful, or does it have more todo a limitation imposed by some other design decision? I recall some previous discussions on using relational segments instead of groups for dotlrn. Is this causing some kind of problem that prevents the creation of department admins?

5: Response to dotlrn department and subject adminstration and user assignment (response to 1)

Posted by Peter Alberer on 08/20/02 12:05 PM

in a setting where one dotlrn instance would be used by many departments

Isnt this the designated setting? I saw some comments in the source code that indicated there could be problems with multiple dotLRN instances anyway.

As i am not quite sure what the designated use of the organizational unit "department" is could you give an example on how the sloan course structure is mapped to the dotLRN department/subject/class structure? Will there be multiple dotLRN instances for different academic programms? Is there always only one department responsible for a subject?

6: Response to dotlrn department and subject adminstration and user assignment (response to 1)

Posted by Arjun Sanyal on 08/20/02 04:12 PM

dan: right, creating department admins is not difficult, but it will require some work on the admin UI and the dm. since sloan doesn't use department except to organize classes, this issue never really came up. I'm not the authorrity on dotlrn groups/relsegs, so I'm guessing a little, but I don't think that there are deep design issues that prevent this from being implimented.

peter: "Isnt this the designated setting?" sorta. dotlrn reflects sloan's organizational structure in some ways, such as in this case. they don't have a need for many departments, so the functionality for real-world use of many departments is not there yet.

The comments in the code mean that one should not create more than one main dotlrn instance _per openacs instance_. parts of the code assume that there is one and only one main (or top-level) dotlrn instance per openacs instance. on one physical server you can run many openacs/dotlrn instances with no problems. examples would be having one box running a dev oacs/dotlrn server and a production oacs/dotlrn server. so this requirement is not terribly limiting.

i don't know exactly how sloan is using departments, so i'll let them comment on that part.

"Will there be multiple dotLRN instances for different academic programms?"

it depends on how the administration of the different academic programs is structured. if they share common administration, then one dotlrn instance with a dept for each program makes sense. if their admin is completly seperate, then seperate dotlrn/oacs installations makes more sense with the current code.

"Is there always only one department responsible for a subject?"

yes. this is one example of why adding real-world dept functionality to the current dotlrn system is more complicated than it seems both from a code and a UI standpoint.

7: Response to dotlrn department and subject adminstration and user assignment (response to 1)

Posted by Carl Robert Blesius on 08/21/02 10:03 PM

For university wide installations (as we are planning) having a "site wide" administrator that is able to delegate administration on a departmental level would be great, yet it would be much nicer if we had a general solution that allowed easy delegation. In the setup we are thinking about Sloan would be the equivalent of one of our faculties and as it stands we are planning to abuse the "department" function and call faculties departments. Eventually it would be nice if we had the option of assigning a faculty administrator, a department administrator, and maybe even a subject administrator. Actually being able to add new levels of administration rights at any time for groups of courses/communities would be nice. This is a very important design element... and it does not seem like an element that is specific to dotLRN.

Creating a general clean approach to this problem will be important. Like Dan, I found it odd that something like this would be a problem, I thought OpenACS is very capable in the assignment of rights and in the creation of new roles. Is it because departments and subjects have nothing to do with OpneACS groups? When are we going to see some technical documentation?

8: Response to dotlrn department and subject adminstration and user assignment (response to 1)

Posted by Caroline Meeks on 08/22/02 03:03 AM

Carl,

I don't think it will be technically difficult to add department or subject administrators. Mostly UI work to manage the admins and give them views of the classes and a couple lines of code granting privileges when a class is created.

Sloan is not using departments or subjects in any interesting way right now, which is why the UI is not well developed. We only need to assign admin at site-wide or group level. I expect this functionality will grow as other institutions adopt.

I'm interested in the question about being able to have more then one dotlrn instance per server. What is the use case you are trying to solve? Perhaps there is an easier way to solve it.