Forum .LRN Q&A: Permissions admins per package under .LRN

Hi all!

When using .LRN in real life scenarios, the applications that allow you to set permissions over objects of certain applications are:
- non-adequate (showing oacs groups, being able to search for all users, etc., in general non contextualized)
- inconsistent (different UI for the same thing among different applications)

Packages that I know that have this are: forums, file-storage, assessment, others.

They usually use a lib that is under subsite for this purposes, but that lib is basically unsuitable for .LRN.

To fix it we can create an specific lib under .LRN (/dotlrn/lib), that grabs only the user & admin groups for a community and searches for users only within the system. Then create a new param to indicate which lib you want to use. Add code in the applets of each package, so they take care to change appropriately the param to use the right /dotlrn/lib script.

Opinions?
We are on our way to change the UI, and we can contribute a patch and a general fix for .LRN.

Collapse
Posted by Dave Bauer on
It would make more sense to add dotlrn to the list of "subsite-like" packages https://openacs.org/api-doc/proc-view?proc=subsite%3a%3apackage%5fkeys , and then create a page that works for subsites and dotlrn instead of dotlrn specific code that will not be reusable.
Collapse
Posted by Don Baccus on
Yes. Roc's post essentially says "subsite's permission setting lib template is broken". The right answer is "fix subsite", not "parameterize packages to use a fixed version from dotlrn if dotlrn is running".
when activated this breaks applications inside .LRN ...
Collapse
Posted by Dave Bauer on
Roc, then we should fix this of course. Perhaps you can elaborate in a new thread?

We seriosuly need to put effort into making OpenACS/.LRN better, not just adding functionality but improving the code at the same time. Simplifying and reusing code instead of duplicated code is the way to go.