Capabilities for managing course categories

Capabilities for managing course categories

by Tim Hunt -
Number of replies: 20
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
At the moment we have 4 different capabilities for controlling editing of course categories:
  • moodle/category:create
  • moodle/category:delete
  • moodle/category:update
  • moodle/category:visibility
And by default, only the admin has those capabilities. This seems like total overkill to me. Why don't we just have
  • moodle/category:manage
The reason I am asking is that there are a whole bunch of bugs about the way these capabilities are enforced, particularly when you give some of them to course creators, and the course creator is assigned in a particular category.

The reason it is buggy is because actually it is very hard to work out whether operations like moving a category from one place to another should be allowed. With separate capabilities, it needs to be something like 'you need update in the category being moved, and you need delete in the old parent category, and you need create in the new parent category'. Yuck. Also, with separate capabilities, there are many more things that a user might be able to do that they cannot undo, which is dangerous.

Note that moodle/category:delete does not carry great risk of data-loss. There is a separate capability moodle/course:delete. If you can delete courses, then when you delete a category, you are given the choice of whether to delete all the courses in it, or move them to another category. If you are not allowed to delete courses, then when you delete category, you are forced to choose another category to move the courses too. (Oh, but what happens if there is no other category where you have moodle/course:create. Arrgh!)

So, anyway, while I can see the point of having separate course create/update/delete capabilities (for example, by default, only Admin has delete, Course creator has add too, and Teacher has update) I think it is total overkill for categories. And I have all these bugs to fix, and it is bad enough as it is!
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Robert Brenstein -
Aside from the central issue whether we need to have atomic capabilities or a combo capability, a move is not create+delete but a move. That is, in my mind, permission to move a category is a separate atomic capability.

By the way, what does "update" mean? Edit name or more?
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
OK, so suppose we only have a moodle/category:manage capability. What should the permission rules be?

Each category has three properties, a name, a description, and a visible status, and then the categories are arranged into a tree structure. The root of the tree is the System context, and as well as categories, the tree contains courses.
  1. To add a new category, you need moodle/category:manage in the parent category you are adding to.
  2. To browse a category and the courses it contains, you don't normally need any special capabilities, except that
  • to view hidden courses, you need moodle/course:viewhiddencourses, and
  • to see hidden categories you need moodle/category:visibility (or, at the moment, sometimes moodle/course:create is checked instead! I'll fix that bug. I'll probably rename the capabiltiy to moodle/category:viewhiddencategories at the same time.)
To update a category's name, description, and/or visiblility, you need moodle/category:manage in the category itself. To move a category from one place in the tree to another, you need moodle/category:manage in both the old and new parent categories (and you are not allowed to move a category to be a descendant of itself!)
To delete a category, you need moodle/category:manage in the parent category and the category itself. In addition, if the category or any of its subcategories contains any courses you need either:
  • moodle/course:delete in all of those courses, or
  • moodle/course:create and moodle/category:manage in some other category that is not a child of this one. (Except that, if this category contains no sub-categories, we don't check moodle/category:manage in the other category.)
Anyone who thinks it is necessary to retain separate CRUD capabilities for categories is invited to devise the corresponding set of rules.

With the above rules, almost every operation someone can do, they can also undo.

(The one exception is when you have moodle/category:manage but not moodle/course:create in some category and its parent - if you delete that category, either deleting the courses in it, or moving them elsewhere, then when you re-create the category, you will not be able to re-create or move the courses back.) ((Unless you have the ability to assign or override roles enough to get the permissions you need wink ))
Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Robert Brenstein -
Yes, please rename moodle/category:visibility to moodle/category:viewhiddencategories !
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Sharon Goodson -

I'd like to add my 1 1/2 cents - I'm not sure it really applies to this thread, but it seems to fit (though you lost me on spooky atomic capibilities surprise...*lol*)

Regarding editing and moving categories. Currently, if you update (or add) a category/subcategory, it's automatically moved (or placed) at the bottom of the tree. To return it to where it was, you have only the up/down option. If you have a lot of categories and/or subcategories, this can be very tedious as you have to wait for a page reload after every single move up.

It would be nice if an existing category would remain in it's 'pre-edit' order, and if categories used the 'move to here' function instead of the up/down function.

Sorry if I butted in, but I thought I'd thrown that out there since your looking at categories...

Average of ratings: -
In reply to Sharon Goodson

Re: Capabilities for managing course categories

by Robert Russo -
this was extremely annoying for us, so we wrote an administrative plugin to re-order them alphabetically. If you're interested, let me know. If more people are interested, we would love to get it into contrib.
Average of ratings: -
In reply to Robert Russo

Re: Capabilities for managing course categories

by Anthony Borrow -
Picture of Core developers Picture of Plugin developers Picture of Testers
Robert - If you would, go ahead and create an issue in the tracker and attach the patch. Let me know what you want to call the patch. Peace - Anthony
Average of ratings: -
In reply to Anthony Borrow

Re: Capabilities for managing course categories

by Robert Russo -
I'll get the tracker issue up on Monday. We use our departments as categories, like chem, psyc, math, engl, so having them alphabetically sorted was the only way to go for us. Our admin is not a developer, so we wrote this to simplify his life. We also wrote this a while ago when we didn't want to touch core, so it makes unnecessary choices compared to just adding a sorting system to categories and items directly. But it works and has been in use for months now. Sorry so long winded.
Average of ratings: -
In reply to Robert Russo

Re: Capabilities for managing course categories

by Sharon Goodson -

I'm not sure alphabetical would work for us, but it might - I'd look to look at it! Our categories are structured more by level and subject, but maybe we could rethink that...

Post the tracker code when it's up! Thanks!

Average of ratings: -
In reply to Sharon Goodson

Re: Capabilities for managing course categories

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Yes. that is a really stupid bug, and is on my list to fix.
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Matt Campbell -
They're for 1.9, Tim, but a couple of tracker issues for this both have patches provided - MDL-15658 and MDL-15910. Not sure how radically things changed for 2.0, but we're using MDL-15658 successfully with 1.9.x.

Thanks,
Matt
Average of ratings: -
In reply to Matt Campbell

Re: Capabilities for managing course categories

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
All the fixes I am doing are for 1.9.4, as well as HEAD. I saw the various patches, they helped me confirm I was doing the right thing, but actually to fix all the various bugs, it is turning into more of a rewrite of some of the files like course/category.php and course/editcategory.php, to bring them more in line with Moodle coding conventions, so I did not use any of the patches directly.

I am aiming to commit the changes to 1.9.3+ just after this week's weekly build, if I can get enough testing done before then.
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Robert Brenstein -
Tim, I don't know whether this qualifies for 1.9 branch, but you might want to look at MDL-17535, an old but working interface to handle the category tree with less effort and pain.
Average of ratings: -
In reply to Robert Brenstein

Re: Capabilities for managing course categories

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I don't greatly like that proposed interface. It is certainly more efficient for super-users, but I don't think it is very friendly for new users.

My preferred approach (at the moment, I am still thinking about this) would be something more like the interface for organising question categories in the question bank, but, when possible, using Ajax so you do not have to wait for multiple page-loads.

As you say, this is not something to be done for Moodle 1.9. It is now on my to-do list for Moodle 2.0.

And thank you for finding all the duplicates of this issue for me wink
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Robert Brenstein -
I did not mean the interface as GUI but as a way to handle the tasks. If you followed to the discussion quoted, you could read that it can take a good minute to just load the category editing page. My implementation, as clunky as it looks, loads in no time and allows to accomplish editing and moving categories faster, partly thanks to page loading faster and partly to the extra actions. I created it as a result of frustration when making a major rework of category structure. I agree, though, that it is not too friendly for new users, although few new users have to worry about such a functionality. Ajax,of course, adds a new dimension to the mix. The question bank has the tabbed interface, which is nice, but its handling of the structure has the same if not worse behavior for a large category tree as far as I can see. It seems to handle, for example, each category or subcategory independently not as branches.
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Dan Poltawski -
Hmm my brain processing this slowly on a friday wink so apologies if this sounds stupid, but just to think out loud:

The one use case I can think of for separate capabilities is where we wish to give a user permission to create subcategories but not delete the parent category itself (a course creator at that context). I think that case is covered by your above scenario by not giving users permission on the 'parent of the parent', right?
Average of ratings: -
In reply to Dan Poltawski

Re: Capabilities for managing course categories

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
That's right.
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by Ray Lawrence -
But, again if I understand what is proposed, it would not be possible to grant users assigned to a role the ability to create a sub-category but not the ability to delete it.

Does this also mean that to be able to see hidden categories one would be able to "manage" all aspects of categories too? If so, why degrade the granularity of the roles system in this (or other) important area? Admins need the ability to devolve duties flexibly in a way that meets the needs of their organisation.

Retrospectively lumping capabilities together like this is a bad move IMO. Better to take longer to fix the bugs than take this shortcut.
Average of ratings: Useful (1)
In reply to Ray Lawrence

Re: Capabilities for managing course categories

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
With my proposal, if someone can create a new category, then can also delete it. However, as admin, you could create one specific new category for that user, then give them permissions to do things within that category, but not delete the category itself.

Seeing hidden categories and managing categories would remain separate.

Yes, admins need flexibility. The question is how much? Each extra capability makes defining role that bit harder. So unnecessary extra capabilities hurt usability. And I don't see any compelling use-cases that require separate capabilities here. So I favour applying the KISS principle here, and ensuring that the simplified system works without bugs.
Average of ratings: -
In reply to Tim Hunt

Re: Capabilities for managing course categories

by David Sturrock -
I support the proposed changes and suggest you ensure the issues about separating course viewing from participation are also taken into account as discussed in (http://moodle.org/mod/forum/discuss.php?d=107390) and http://tracker.moodle.org/browse/MDL-11798. A lot of the time, people being assigned as category managers will not want to have their personal course list expanded to include all the courses within these categories.
Average of ratings: -
In reply to David Sturrock

Re: Capabilities for managing course categories

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Course viewing / participation separation is, I'm afraid, a separate issue. One step at a time.
Average of ratings: -