Forum .LRN Q&A: Archiving and deleting communities

Collapse
Posted by Caroline Meeks on
We (Andrew and Dee did most of the writing) have posted a spec for how we believe archiving and deleting classes and communities should work. I'm starting working on implementing that spec and thus am inviting comment and discussion.
Collapse
Posted by Caroline Meeks on
In implementing this I’ve discovered it would be far easier with a data model change.

If you look at the current dotlrn_communities it is a view where archive_p = 'f'.

I would like to change that to its own view dotlrn_communities_not_arch and make dotlrn_communities equivalent to dotlrn_communities_all.

When dotLRN was originally written there was not a clear understanding of what “archiving” and “deleteing” and “not active” should mean for a class.  Someone made the decision that archived communities should not generally be shown.  Now that we have fleshed out our requirements for archiving it turns out that it should not be so strict.

Looking at the code, it looks to me like dotLRN_communities is the generally used table, and that in most cases when it was used a conscious decision to exclude archived communities was not made.

I think it would be better in the long run for me to go through and determine where archived communities should not be shown and explicitly change those queries to use dotLRN_communities_not_arch.

TAB, what do you think? What do other people think?

Here are the new views from communities-create.sql

create or replace view dotlrn_communities
as
    select dotlrn_communities_all.*
    from dotlrn_communities_all;

create or replace view dotlrn_communities_not_arch
as
    select dotlrn_communities_all.*
    from dotlrn_communities_all
    where dotlrn_communities_all.archived_p = 'f';

create or replace view dotlrn_communities_not_closed
as
    select dotlrn_communities.*,
          groups.join_policy
    from dotlrn_communities_not_arch dotlrn_communities,
        groups
    where dotlrn_communities.community_id = groups.group_id
    and groups.join_policy <> 'closed';

create or replace view dotlrn_active_communities
as
    select dotlrn_communities.*
    from dotlrn_communities_not_arch dotlrn_communities
    where (dotlrn_communities.active_start_date is null or dotlrn_communities.active_start_date < sysdate)
    and (dotlrn_communities.active_end_date is null or dotlrn_communities.active_end_date > sysdate);

create or replace view dotlrn_active_comms_not_closed
as
    select dotlrn_communities.*,
          groups.join_policy
    from dotlrn_active_communities dotlrn_communities,
        groups
    where dotlrn_communities.community_id = groups.group_id
    and groups.join_policy <> 'closed';

Collapse
Posted by Don Baccus on
I'd prefer "not_archived" rather than "not_arch", unless the view name is then so long that Oracle barfs.  In general I prefer full names rather than abbreviations.
Collapse
Posted by Caroline Meeks on
yes, Oracle barfed on dotlrn_communities_not_archived.
Collapse
Posted by Michael Feldstein on
This looks great, in general. A couple of comments/suggestions, though...

First, if archiving a group is fundamentally different than archiving a folder, we ought to use different verbs to distinguish between the two actions. I don't have any ideas off the top of my head, but calling both of these actions "archiving" will be confusing to the user. And actually, a group space in which participants still have write access privileges doesn't seem to fit the term "archived" as it is generally understood. It's inactive, maybe, but not archived, which implies preservation in the state it was in at the time it was archived.

Second, there's another set of archiving options that could be useful. (This may be a post-1.0 enhancement, depending on the immediate needs of the sponsor.) As I understand it, "archive" currently means that the course is closed to new users and references to it are pulled from most portlets, but the class itself remains live and writable to class members. I can imagine a situation in which a professor would want to leave the class accessible on a read-only basis to everyone, including people who weren't participants, but prevent anyone from submitting new content. (This is particularly important where an institution may have liability for the content being posted and would therefore want to be sure that the class was being actively monitored by a professor or other responsible party.)

Other than those two suggestions, this looks solid.

Collapse
Posted by Caroline Meeks on
Thanks Michael,

I like your idea of active/inactive vs archived. That change in terminology should also fix the oracle says the name is too long problem in the views discussed above.

For Sloan I think "open in read only state" maybe called OCW. :)  But I do agree its a feature that should be noted for future development.

Dee and I will work on rewording the spec and I'll write upgrade scripts to rename the tables assuming TAB is in agreement.

Caroline

Collapse
Posted by Michael Feldstein on

For Sloan I think "open in read only state" maybe called OCW. :) But I do agree its a feature that should be noted for future development.

I'm not entirely sure that we're talking about the same thing here. Does OCW allow the archiving of the student-generated interactions, or just the instructor-generated course materials? I was under the impression that OCW deals with the latter, and I'm suggesting that it would be useful to be able to do the former.

Collapse
Posted by Carl Robert Blesius on
Heidelberg Medical School Use Cases:

Case #1:
Introduction to Human Anatomy course is offered in the first semester (online course in dotLRN augments the class with notes, discussions, FAQs, diagrams, etc.). Students take part in the course, do well, and move on to other courses (the online course is then "cloned" for the next group and made "inactive" by the course administrator after which it "disappears" from the students portal view in dotLRN). A year later the students would like to review Anatomy lecture notes, questions, discussion, etc. for their upcoming medical board exam. They go to the control panel (to "inactive courses") and are able to access all information (including student-generated interactions) related to the course that they attended. We question if the interactive parts of the course should automatically be closed (students might want to continue discussion with one another or organize study groups).
The course administrators can make a course active again.

Case #2:
Pharmacology courses are offered to BASF employees through an agreement between the school and the company. Courses are offered on a short term basis and are "archived" upon completion (after the content has been cloned for the next group). "Archiving" makes the course inaccessible to all users (only a system wide admin can bring a course "back from the dead").