Our issues here at Sloan are slightly different and so I hope you can accommodate thatm in what you plan to do. In our case, I close each class at the end of each term so that it is no longer available for anyone new to join it, but unless I am asked, students are not removed from their classes. And i do not use the 'archive' function for classes for the same reason - for the most part, our professors do not mind if their students retain access to class materials after the end of the term and actually, students really like this 'feature.' I think we need to change the way students access content from previous terms, but we haven't gotten to that yet (and by this i mean that we need to expand the functionality of the Join/Drop page to include browsing by term).

So, though some of what you propose - an automated way of expiring classes and the ability to make content read-only - would be very useful to have, i would want the option of allowing students read-only access to their old classes as well. Would you be willing to include this as an option?

That's good news about read-only for students.

>About browsing by term: In the groups portlet (user portal) >We will only show the current courses and will add a link to >show all the 'expired courses' grouped/ordered by term. What >do you think?

I think that is a great idea. Clutter for the user portal for students is an issue here, so this would reduce clutter in the Groups portlet and our students will appreciate that.

DeeDee

For db_dml we block everything that has such permission.
For db_exec_plsql we block also based on the naming convention (i.e. if you are executing something called .new or __new, then that is blocked, the same for .del / __delete) in combination with the permission.
Also we added extra stuff to handle those cases when the db_dml is called from a scheduled proc in order to avoid the check of a permission.

This functionality has been on production for more than 6 months, working fine and no performance penalties has been detected. And it is a general purpouse feature, not just for .LRN.

Unless we as a community want to refactor the whole bunch of applications we don't see a straightforward way to "freeze" an application in a view only mode. As you can see, this is a feature that we need to support.

We would like to go ahead on this and contribute, any comments for a better approach?

In our case, the user is adviced by a "Warning Message" in the header that says "EXPIRED COURSE" with big/red/bold font. The users know that when this message appears any member can't modifiy items.

Course admins should still be able to get to the adminstrative parts of the site. So they need 'admin' privilege.

Some smaller but notable stuff to watch out for:

1) In postgres I'm pretty sure you can modify data in a SELECT some_function(args), which means you may not catch everything. That's mostly an enforcement and engineering standards issue.

2) If you're hanging all of the checks on [ad_conn package_id], you're going to miss anything processed in the background, such as email notifications.

And of course, we base this on an engineering standard, since pg invokes functions in a select statement.

Inboud replies is an special case that needs to be handled.