for this links that appear in the admin domain of a class:
# Manage Membership - Add/Remove CS intro A members
#  Create a new Limited Access user - Only use this to create an account for cross-registered students who do not have accounts from a previous class.
# Create a new Limited Access Guest user - Only use this to create accounts for non-affiliated users who do not already have an account. Information about other members of this community will not be available to this user.

We want the dotlrn-admin to be able to decide whether he will allow the professors to access those actions for all the classes or not.

My first though was a parameter, but since each class is a dotlrn instance, each one will have its own parameter, and for me right now there is no clear way to change all the parameters at once, and don't know if this is the best approach or what ....

Also, there's a need for a dotlrn-admin users, that means, the dotlrn-admin might not be a site-wide-admin, any suggestions on this?

It's important for Sloan that the default setup remain that these options are all available to all class and community admins.  This functionality was one of the biggest selling points/wins for the system at Sloan because it gave faculty the autonomy they needed to run their courses and gave communities that same flexibility, especially since many have non-MIT members.  And, for the Manage Membership link, since any member can drop any membership, but not rejoin a closed group, it's important that the group admin be able to add people back in.  The more groups you have, the more adminstrative burden is placed on the site wide admin to monitor, without any tools, the actions of users.

I don't understand exactly what you mean by your last question - can you provide an example or two of this in action?

DeeDee

What do you think of a feature that automatically registeres a user to the requested group if all upper groups are open? Or up to a group and including that group where the user needs approval. From there on the user has to continue manually.

Based on information collected from the user (or information that already exists in the DB), we want to auto-enroll them in certain courses (or groups).

Example: 200 medical students should be automatically added to specific classes/groups based on there status (e.g. first clinical year).

Will have some use cases for discussion in the RFC.

I understand what your needs are, and my suggestion is not to eliminate those functionalities, rather than that, I would like to see a parameter that will allow for an entire .LRN installation (all the classes) to allow or not those actions. In our case is quite important since we don't want those, specially the one for allowing professors to add users to a class, since we do that automatically (add users to groups).


>>Also, there's a need for a dotlrn-admin users, that means, the dotlrn-admin might not be a site-wide-admin, any suggestions on this?

My user scenario is this, we might want to give to some people dotlrn admin priviledges, but to site wide admin, in other words, a dotlrn admin should be able to create class and that kind of stuff, but not be able to install a new package ....
(any technical suggestions on this??)

1. the package will be released by the end of next week and will be documented, right now we dont have something formally written yet.
2. we are tight to the standard, that means that if you have a DTD that is compliant, should work, anyway, I would say that is not difficult to do minor changes on the code in the case you need further customization (in other words, the package isn't written specifically for Galileo)

>vs.
> what will enhance the common use group administration, and how it fits with
>the IMS Enterprise usage that is already present in OpenACS 5.0 (External) Autentication?

The IMS Enterprise v.1.1 spec is divided in 3 parts, <person>, <group>, <membership>.
Right now auth has only <person> which is the import of users from the DTD to .LRN, now we have added:
* <group> which creates automatically from the DTD the departments, subjects, and class instances
* <membership>  which creates automatically from the DTD the *relation* between users and a given class instances, and the specific roles (professors, TA's, students, etc) for that class.

Its more clear now?

I'm on my way to produce the very first basic documentation that will help anyone. Be aware that right now its only for PG, my plan is to make it oracle available as well (will be relatively fast), but first test it more.

More info from IMS: http://www.imsglobal.org/enterprise/entv1p1/imsent_infov1p1.html

This would be amazing!

Greetings,
Nima

How could this be implemented?

Don was so kind to take a look at it:
- it's all properly permissions driven
- they need to have "dotlrn_admin_community" permissions
- there is no UI at present for this purpose
- unclear how it should be with communities, maybe changing otlrn/tcl/community-procs.tcl to give explicit rights
- group would be created in the dotlrn SQL create scripts
- perhaps some custom fiddling of permissions in the dotlrn/tcl/community-procs.tcl scripts

Has anyone tried or implemented this already or an idea on how this could be implmeneted?

Best regards,
Nima

Error in forums::message::new - Database operation "0or1row" failed (exception NSDB, "Query was not a statement returning rows.") ERROR: column "format" of relation "forums_messages" does not exist CONTEXT: PL/pgSQL function "forums_message__new" line 50 at SQL statement SQL: select forums_message__new('3894','forums_message','3893','A new message','This is a new message.','text/enhanced','452',NULL,NULL,NULL,NULL,'452','160.45.11.61',NULL)