Collection: view access updating at problematic time

[Stacey Walker]

When a user creates a new collection and they get to the views stage access for each views access is updated immediately as it is added.

This means that if a user decides that they don't want the collection anymore and cancel then the view access is already updated and they have lost original settings on views.

The user might also just add a view and then immediately decide that wasn't the right decision and remove from the list.

This is an issue for both new and existing collections.

The help file does mention this is going to happen, but I'm thinking it is not the most appropriate event for access updating to occur on anyway.

Solutions might be to:

For new collections:
a) update access only on the final stage when user saves collection completely
b) alert user somehow that views are going to have their access updated when they navigate past the views page

For existing collections:
a) only update when the user is completely finished with the page (clicking 'Done') and ensure it is clear that the access will be updated at this time

Any other ideas?

[Dan Marsden (danmarsden)]

+1 from me to update access on final stage (sounds like the easiest option)

unless it's easier to store original access details on views and if they remove it from the list/cancel the update/creation then revert to original access

[Kristina Hoeppner (kris-hoeppner)]

Don't have a better idea. Yours sound logical to me, Stacey.

[Richard Mansfield (richard-mansfield)]

I don't think I agree with either solution really, because if you add some views, and then navigate away without clicking any of the next/cancel/done buttons, you end up with a collection in a state where it has views in it, but all those views have different access rules.

That's a problem with both creating new views and creating new collections -- they're pretending to be a wizards when that's not really what they are (they have 'cancel' buttons down the bottom that aren't really cancel buttons, they're 'delete' buttons).

For views it's not so bad, because a half-created view is pretty harmless - only the owner can see it. With collections you end up with broken links which is worse, and potential upgrade headaches for us later on when we eventually merge access across collections properly in the db.

So I'd prefer to either:

(1) leave it as it is, and add a message to the user to say what access was added every time views are added (admittedly this is still a bit yuck), or

(2) Change the way the page works so that the views are not updated at all until you save the page (by clicking next/save) - then the cancel button really means cancel. We can tell the user at that time what access rules will be added. Stacey, I think you had a half-finished view picker widget that will do this job, right?

[Dan Marsden (danmarsden)]

hmm - makes sense Richard - I hadn't realised how collections pages were working until you explained.

The new Moodle 2.0 restore process works a bit like the way the page works now - at each step it makes changes to db/updates and if the user hits cancel it just goes through and reverts those changes.

I don't think the "cancel" button has to really mean cancel and can be a delete/tidy up function but it definitely causes problems if the user can easily navigate elsewhere and leave a half created collection in place (and they are unaware of this)

Stacey - how much work is involved to add a small notification to the page each time a user adds a view like Richard mentions in point 1?

[Stacey Walker (stacey)]

Richard - the views picker widget is just a wish item at this stage and no development has been started. Hopefully one day, I might create a wishlist bug for this so we have it on track etc :)

For now though, I have gone with what you suggested by adding an extra sentence to the notification that states:

"Collection has been updated to include access from new view." (or views if multiple were added).

This doesn't say what access was added but at least offers the user some more information that access changes are occurring.

Have committed this patch seeing as it is trivial.

Stacey