Semester 1 2013 roll-out - can lists be transferred over?

[ssu-readinglists]

Basically, at the moment, we do not want lecturers to be able to back-up/restore reading lists into different units without us knowing about it because then digidocs could end up on different/multiple units without having the appropriate copyright information, and we have to avoid this.

However, for Semester 1/2 2013/14 I believe that we will want existing reading lists to be copied over into new units - I think the LTU does this for lecturers as part of the summer work? If so, then I think reading lists should be included within this process, if done by members of the LTU (so admin logins only and not general staff logins). Then, we can go with Lauren's suggestion of if the digidocs have not been asked for again, we can have a page instead of saying 'unavailable' saying something like 'this article has not yet been requested for 2013-14. Please check with your lecturer. Lecturers, please contact readinglists@solent.ac.uk if you wish to restore access to digitised materials@ [or something along these lines]

This is something we'll need to look at all together as part of the 2013/14 preparation, but think key things for the minute

1) lecturers are not able to back-up/restore reading lists across multiple units - and should never be able to do this (provided such a restriction is possible) - they need to contact readinglists@solent.ac.uk to request this will numbers of students/unit codes

2) admins can move reading lists across as part of annual updates and then lecturers need to contact us for things to be re-instated etc

[ssu-readinglists]

Discussed in technical meeting 20/12/12:

There will be an 'import' feature which lecturers can use to move across data. Reading Lists are to be excluded from this procedure. Lecturers will need to contact readinglists@solent.ac.uk to request lists/digidocs are re-instated and updated.

Import feature on reading lists to only be set to admins/infolibs so we can move the RSS feeds across as required - RE confirmed that this can happen when the unit is already populated with other data

NEED TO TEST THAT THIS IS POSSIBLE WITH ROLES/PROCEDURES - arranged meeting with RE to discuss

[ssu-readinglists]

See also digidoc issue - Is an amnesty required again related to digidocs? How does this relate to units being roll-over?

[RogerEmery]

Can Reading Lists be removed from the import options for tutors? (preference) Can text be added to import routine to remind tutors to contact library regarding reading lists and digidocs? Can 'Reading List Master' be restricted so they can only import Reading Lists (and no other unit content)? (to avoid confusion)

[RogerEmery]

Tested import - Reading List can be import from/to any unit with a few mouse clicks.

[ssu-readinglists]

After meeting with Roger, we need to decide possible ways to take this forward. 2 options - opinions please:

1) Can we just add the capability to permission import/back-up by roles etc? This might be easiest

2) More complicated, but reading lists seen as a sub-resource currently - can we restrict by this - so reading lists become a self-contained type which is not affected by generally code changes - would allow different icon/settings so might help with other issues? Can we re-class reading lists as separate from other resources thus giving them their own permissions?

[ostephens]

I'm not sure I understand this completely.

What do you mean by 'reading lists seen as a sub-resource'?

[ssu-readinglists]

RE - please can you explain the above? Thanks

[RogerEmery]

This is a hang over moodle 1.x I think. In some area's all 'resources' are just labelled 'resource' eg in the activities block and during back-up, restore, import. Whereas each 'activity' is seen as a separate item. In 1.x label, files and so on were 'types' of 'resource' and 'resource' was a type of 'activity' (mod) Is it possible to make the reading list fully independent for the purposes of the activties block, back-up etc? Does it need to be re-classified as an activity to acheive this?

[ostephens]

In Moodle 2.x as you say the concept of a 'sub-resource' no longer exists - so the reading list mod is already independent - it has it's own backup etc.

[RogerEmery]

It must be a hangover from 1.x that the activities block doesn't list RL as a separate item from the other resources. I've just discovered this type of page lists all RLs individually http://mycourse.solent.ac.uk/mod/readinglist/index.php?id=89

[ssu-readinglists]

does this mean then that we can already look at the back-up/restore functions within reading lists as being separate from the general procedure - so can set restrictions on who can backup-restore - either by roles or permissions?

[ostephens]

The functions supported by the RL mod are set in lib.php:

/**

• List of features supported in Reading list module
• @param string $feature FEATURE_xx constant for requested feature

• @return mixed True if module supports feature, false if not, null if doesn't know */ function readinglist_supports($feature) { switch($feature) { case FEATURE_MOD_ARCHETYPE: return MOD_ARCHETYPE_RESOURCE; case FEATURE_GROUPS: return false; case FEATURE_GROUPINGS: return false; case FEATURE_GROUPMEMBERSONLY: return true; case FEATURE_MOD_INTRO: return true; case FEATURE_COMPLETION_TRACKS_VIEWS: return true; case FEATURE_GRADE_HAS_GRADE: return false; case FEATURE_GRADE_OUTCOMES: return false; case FEATURE_BACKUP_MOODLE2: return true; case FEATURE_SHOW_DESCRIPTION: return true;

  default: return null;

  } }

It's the first line of the switch/case that makes RLs appear as a resource - but I don't think this will affect much except the grouping of RL as a 'resource' or an 'activity' in the UI. I think everything you need is already there for backups etc.

[ssu-readinglists]

What we want to do Owen is to exclude the RL from the standard backup/restore that lecturers use to move their materials across into new blank units each semester/year (because of digitised materials, new editions - we need to know which reading lists are live and being used and numbers of students). Therefore, we either only want roles with certain permissions to be able to do this, or to be able to exclude just the RL from this process, and then allow readinglistmaster login or admins to import across afterwards. Does the backup already in the RL mod makes this possible or do we need to develop something? We feel it would be better to set something within the RL mod to control this rather than in the general back-up/restore process. Hope that makes more sense?

[ostephens]

I have to admit I haven't got a huge amount of experience with how Moodle lets you control/split up backups. If this is possible in general in Moodle (i.e. to handle different mods separately) then it is possible for the Reading List mod.

I can do further investigation, but if there is local knowledge at SSU about implementing this kind of functionality then please let me know and it might shortcut research I need to do

[ssu-readinglists]

Discussed in meeting 23/01/13

Backing up and rolling lists over is easy, it's just making sure digidocs don't get rolled over too that we need to watch. In addition, Roger and Daran want to avoid making changes to Moodle's core code.

We have two options, both of which require more investigation from LTU:

1) get clever with capabilities in Moodle; 2) employ graceful degradation through customised 404 errors and automated email notifications.

Next step is for LTU to investigate the options a bit more.

[hhy05]

AF thinks easier if lists don't get roll-over at all - otherwise multiple enquiries from lecturers when things not in correct places/needed updating etc? To consider.....

[RogerEmery]

Considerations:

1. We don't back-up at all Dangerous to not have fall back if tutor breaks unit for other reasons and we need to restore it.
2. We back-up, but prevent import/restore Requires core code hacks with potential impact on upgrades and is bad practice, also as above potentially no fall back if tutor breaks unit for other reasons and we need to restore it.

In either case, RSS feeds or full reading lists and links can be copied from unit to unit.

So our recommendation is the look at the digidocs system (I know its on the list) and in the first instance consider using the suggestion from meeting: "employ graceful degradation through customised 404 errors and automated email notifications."

What this means is any links to 'dead' digidoc links could display a 'friendly' message for students and will automatically send an email to appropriate member of staff to flag it up.

Can look at developing reports to show "new" RLs or Digidocs to keep track of any unauthorised copies.

[ssu-readinglists]

Agreed at meeting 27/02/13

Best to stick with myCourse existing procedures and not complicate just for reading lists.
Best also to wait until lecturers import themselves or ask for import rather than put in reading lists ourselves as causes issues.
We can still start earlier by making changes in myReferences which will reflect in the old unit, and then in the new unit once RSS carried across (need to be aware of folder name changes etc though)

So lecturers will be able to import their reading lists along with everything else

Roger and Daran will look at their timeframe and give us a date by which they will have investigated 3 things below.

Can we flag up on import that lecturers should contact the Library about updating their reading list and digitised documents? Can we get a report that shows when lists were last edited so we know what has been updated or not and by whom? Can we send an email to readinglists@solent.ac.uk showing which lists have been imported?

[hhy05]

Quick discussion in meeting 07/03/13

RE and DP done some investigation work:

We can completely prevent import by added capabilities (but likely that we don't want to do this for various reason)

We can add a language string to two files to alert on import - would need to decide text, but could say contact about your reading list etc here

Can be sent a basic notification email on import but more investigation needed as this can be done in several ways - e.g. back up and restore too - DP investigating

RE investigating reports after the event so we could see what was where in moodle.

So a combined approach should give us enough information - more to follow after further investigations....

Can we flag up on import that lecturers should contact the Library about updating their reading list and digitised documents? Yes - via language string

Can we get a report that shows when lists were last edited so we know what has been updated or not and by whom? RE looking at, time stamp problems

Can we send an email to readinglists@solent.ac.uk showing which lists have been imported? DE looking at, partly successful but more investigation required

[ssu-readinglists]

RE/DP to add language string to import advising lecturers to contact readinglists@solent.ac.uk on importing their lists as student numbers required/digitised documents need to be renewed - HY to test

Language string added on dev server to all situations of import/restore. HY tested 14-15/05/13 - DONE

Need to agree wording and then implement and add changes to LIVE - sent to DP/RE to load 16/05/13

[ssu-readinglists]

RE/DP to look at emails to readinglists@solent.ac.uk showing unit name if a list has been imported - HY to test

Email to readinglists working very well - shows unit name/code. Occasionally not received but in minority and no pattern discovered HY tested 14-15/05/13. DONE

[ssu-readinglists]

RE to tweak basic reading list report so shows in date newest order and set to run once a week #38

[ssu-readinglists]

LS to look at 404 error message with IT - a screen saying This digitised document has expired. Please contact your lecturer. Also to see if report can be run showing where hits are from - (there might be a way to get this 404 message to ping out an email as well as a possible report?)

404 message now loaded - stats to still investigate 25/06/13

[hhy05]

TO DO: Need to agree wording - DONE add changes to LIVE - what deadline needed? LTU blanket email When to load digidoc expired notice - agreed end of August after resits

[hhy05]

Agreed 19/06/13 - dates still being discussed as lots of other factors - code from the dev server will be loaded onto live before the email goes out so that everything ties up. Wording below to be added to dev server

If you are transferring an existing reading list you must:

email readinglists@solent.ac.uk with the course title, unit code/title, duration and number of students send us any changes that you require.

WARNING: if you have digitised chapters/articles that you wish to carry over, you must inform us or the links will no longer be accessible.

[hhy05]

LS/SC done logs for digidocs now - available on digidocs server daily - idea is that member of the team will check and follow up after October once most of lists should have been moved over and digis made live again.

[ssu-readinglists]

Roll over successfully managed