Moodle

Assigning to Martin and adding some VIPs to KTC (know, think and comment).

Thanks for report Robert, ciao

I think that manage is used when we mean add and edit and delete.

Robert, if you have been thinking about this, perhaps you should add a page http://docs.moodle.org/en/Development:Capability_naming_conventions to Moodle Docs. Start with a huge disclaimer about how this is just your personal proposal, as a basis for discussion (as I did at the top of http://docs.moodle.org/en/Development:JavaScript_guidelines. Then post in the general developer forum to invite discussion.

That is the way that is most likely to get something done. It will be easier for Martin, and others, to comment if we have a specific proposal, and if we can already see what others think of it.

I agree with Eloy's comment on MDL-17216 that this should be 2.0 only. We can't mess with capabilities on a stable branch.

A further note:

Add+edit+delete are sometimes combined as "manage" because:

Does it ever make sense to allow add but not edit?
Does it ever make sense to allow edit but not delete for your own? (you'd end up with lots of blank entries)
Does it ever make sense to allow delete but not add or edit?

Well, delete can lead to dataloss, so sometimes (rarely) you want it to be separate. A good example is moodle/course:delete. It makes sense to have that as separate. In a paranoid institution, Course creators can hide their course and ask for admins to delete it.

And we probably want Teachers to be able to edit their courses, but add or delete them.

But I agree that in most cases, manage is sufficient.

Well, if we are talking about being satisfied with "sufficient" as in supporting only mainstream, then indeed this is waste of time.

Martin, there are indeed situations when one would want to allow one and not another. May be not in the combinations you wrote. Here are a couple non-teaching examples from my playground for the database module.

Example 1: List of courses to be offered next semester.

Anyone who is a qualified teacher can create a new entry and edit their own entry. Once the list is officially approved, the deletion is forbidden (withdrawn courses are marked as cancelled but they stay in the list). After publication deadline, editing is also forbidden but creating new entries is still allowed (late submissions).

-> Would love to do it within Moodle but have to stick with an external program displayed as a resource inside a frame.

Example 2: IP addresses in a local network segment.

The pool of IP addresses is managed by several people, keeping track which are free and who/where/which has one assigned. Records are created by admin only since the pool of addresses is fixed. The maintainers should be able to edit any record but not delete any.

-> This made me submit a change request – some users are deleting entries when IP number is made free and I have to keep recreating them.

No time to search forums properly, so only a few quick finds:

time-limited record editing
(such an enhancement not possible without atomic capabilities)
http://moodle.org/mod/forum/discuss.php?d=106883

deleting only by teachers
http://moodle.org/mod/forum/discuss.php?d=107634#p474762

Yes sure I can see there are some added combinations possible that could work, but at a cost of greater complexity and a much longer overrides page (and people already complain a lot about roles complexity)... so that's why some of them were avoided in the original roles design.

I'm with you 100%, though, that we could use a little more clarity and regularity everywhere.

Just a note about Example 2, if those maintainers can't be told to do the right thing, then giving them edit and not delete won't help any, as they'll just blank out the entries instead of deleting them.

I'm probably not being clear enough: I'm not actually against Robert's proposal, just explaining why capabilities were made the way they are now, to help in the design of any new standard.

I am not suggesting any radical changes and it was actually Eloy who thought it might be time for larger review. The proposed task is to review how the plugins (not core, where things are under tighter control/review) follow the current standard, whatever that standard is, AND to verbalize it in the docs. There are so many 3rd party plugins and the experience of their developers vary a lot. Hence some guidelines (-> more clarity and regularity) would benefit all. Atomic capabilities could be recommended IMHO but, of course, there are instances where aggregates make sense. The usage of the data module, however, is so varied that the aggregates there are restrictive.

The overrides page is long anyway and probably someone has to figure out how to split it. More logical and self-explanatory capabilities may actually increase usability. From my own experience, when working with data module, I loaded that page, found I am not sure what is what, had to go to docs, where haven't found clear answers, so I had to experiment by setting certain capabilities to see what they do. No fun.

Re example 2: they are supposed to blank out all fields except one and that one is marked "don't change" on the edit form and separated visibly from others

NOTE: This issue was assigned to the STABLE backlog without complete triaging process. Marking it as triaged, but with this note for future reference.