Forum .LRN Q&A: Archiving / desarchiving classes?

Posted by Jose Agustin Lopez Bueno on 12/02/04 12:30 PM

Hello, all!

I am testing the process of archiving / desarchiving
one community. The global process works ok (in Postgres)
but I do not understand which is the meaning for
archiving? Reading docs for dotlrn_community::archive:

1. the community is marked as archived
2. the RemovePortlet callback is called for all users of the
community (both members and GAs) and all the applets.
3. Do this recursively for all subcommunities.

I am tested that one user can enter in one archived community copying and pasting the url to that community. Is a security bug?

Other thing is put the archived community in read only way.
It is possible?

PS: We need copy objects (files, faqs, ...) between communities. Example: one teacher want copy items between two subgroups that he admins. Anybody has any source / utility for that?

Thanks,
Agustin

2: Controling object add/edit/del in any package in a general way (response to 1)

Posted by Rocael Hernández Rizzardini on 12/04/04 03:57 AM

For archiving, I think the original goal was to disallow anybody to access it, but in a fool way without permission security checks. So it is not a long term solution.

For instance, here at Galileo we have the necessity for making our "old" class portals and its contents available for the users, but in a read-only mode, then we did a *clever but dirty* hack to make that possible, now our users can look and download all the content of classes that they took in the past without being able to change anything (those classes are expired).

Works good and we are looking forward to create a general method for this. Probably now that we have a general proc to instantiate objects "package_instantiate_object", then, for making this possible the best might be to create a:
* package_edit_object
* package_delete_object

Then, we'll have one place to control any possible change to objects (create/edit/del) among all the different packages. This might not be a difficult work, but will be a lot of work to refactor everything. Galileo plans to dedicate a developer to make this happen around the first 3 months of the next year. We don't want to fork our installation from the main source, while we think this addition will be important for many real scenarios.

The main point, is not the technological implementation, is that we aim to create/grow an e-learning environment that contains the history (interactions, postings, documents, grades, etc) of every student, while this is in part a repository of learning objects, beyond that is the learning experiences accumulated through the time as a record that will be preserved for the future centered in the user. Like many have already said, .LRN goes beyond an LMS.

3: Clonning package instances (response to 1)

Posted by Rocael Hernández Rizzardini on 12/04/04 04:02 AM

Application clonning is also needed, some packages have some sort of that implemented, I remember faq has a clonning db proc. Clonning among package instances is needed for enhancing the user experience in real scenarios. We did some sort of that at evaluation package, for instance, the professor wanted to post a given assignment, but he's teaching 3 classes, so he has 3 portal classes, so we simply offer to add that assignment to other classes that his professor as well at the time of posting it. This is not exactly clonning, but is another way to handle one time post for multiple classes. But clonning is important.