You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The name of the capability "isteacher" is not fortunate, and as a consequence it then requires a lot of additional comments and explanations in both code and the UI.
What about if it was called something like mod/collaborativefolders:restrictedaccess.
Also, I don't fully understand why it needed to be implemented in this "negative" way:
Note: This is a restriction, not a capability. Don't use for deciding what someone MAY do, consider as MAY NOT instead.
Although such capabilities exists in core too, they should still be used rarely as exceptions really. Would not it be cleaner if
mod/collaborativefolders:view was given to everyone as it is now (because it has an inbuilt behaviour used by the core) but it would represent the minimal /restricted level of access to the activity
there was another, something like "edit" or "manage" or so which would give the user the full access to the folder - and this one would be then granted to students only.
This existing negative logic makes things only confusing. What if someone sets the "mod/collaborativefolders:isteacher" as prohibited etc. - all such multiple negations make things unnecessary complicated imho.
However, I can see how whole this concept of "being a teacher" (which was abandoned around Moodle 1.7 times) is hard-coded in the module's internal APIs so I don't expect this would be actually addressed.
The text was updated successfully, but these errors were encountered:
The name of the capability "isteacher" is not fortunate, and as a consequence it then requires a lot of additional comments and explanations in both code and the UI.
What about if it was called something like
mod/collaborativefolders:restrictedaccess
.Also, I don't fully understand why it needed to be implemented in this "negative" way:
Although such capabilities exists in core too, they should still be used rarely as exceptions really. Would not it be cleaner if
mod/collaborativefolders:view
was given to everyone as it is now (because it has an inbuilt behaviour used by the core) but it would represent the minimal /restricted level of access to the activityThis existing negative logic makes things only confusing. What if someone sets the "mod/collaborativefolders:isteacher" as prohibited etc. - all such multiple negations make things unnecessary complicated imho.
However, I can see how whole this concept of "being a teacher" (which was abandoned around Moodle 1.7 times) is hard-coded in the module's internal APIs so I don't expect this would be actually addressed.
The text was updated successfully, but these errors were encountered: