Project

General

Profile

Usability #3081

View-rights on categories in weblcms

Added by Nathalie Blocry over 8 years ago. Updated almost 8 years ago.

Status:
Bug resolved
Priority:
Normal
Assignee:
-
Target version:
Start date:
11/03/2011
Due date:
% Done:

0%

Estimated time:

Description

You can restrict publish rights to certain categories and you can publish to platform and course groups (buggy), but you can not limit publication for specific groups only in a category.

so if a user needs to publish something for a specific group in a category specified for that group alone, he always has to remember to publish only for this group.
while it would be reasonable to think that documents posted in a group's category are published for this group alone (unless specified otherwise)

We can have a short-term workaround by adding view-rights to categories,
so that even even when you publish for everybody in a category that is only viewable for certain users, only the users who have view-rights on the category will get to see the publication (category should be hidden to users with no view rights). when group-publications need to be viewable by everybody or everybody specified in the publish-form you can just set the view-right to "everybody".

History

#1

Updated by Hans De Bisschop over 8 years ago

So ideally we would have to further filter out the list of people or groups the object can be published for based on the actual rights on the tool / category as well. Allowing people to publish things for people who actually don't have any rights on the tool or category will inevitable lead to problems. Alternatively (or additionaly) I guess extra rights could be granted if we publish something for someone in a tool / category which they can't normally see.

The problem is whether to treat that as a mistake or an explicit choice of the user. Perhaps this is something we could ask him or her via javascript if and when the situation occurs. Then process the selection based on the answer?

#2

Updated by Nathalie Blocry over 8 years ago

I think we need a system where view-rights can be "inherited" from categories.
where you substitute the default "everybody" with "everybody who is allowed to view this category".
you can then still give the option to give view-rights to less people (like only one or two people who have view-rights on the category) but I think we should avoid the option of giving view-rights to more people (so to people who normally don't have view-rights on the category). this would be too confusing for the user.

If I, as a teacher, make a category where only certain people can view/read and only certain people can publish/post, I don't expect them to be able to "bypass" my wishes and publish something for other people there.

we want to be able to make standard categories in all our courses, mimicking some of the tools in 1.8 like "student publications", where everybody can post and read, "teacher publications" (documents) where everybody can read and only the teacher can publish and "dropbox" where only teachers can read and all students can publish. we cannot enforce that with the current system.
We also need the functionality of the "group" documents that are only accessible to members of a group.
The functionality is there already offcours, you CAN publish only for a certain group, but it needs extra actions from the user.
In the long run everybody will get used to the "publish for" system, but for the time being we want to keep everything as simple as possible and avoid mistakes.

#3

Updated by Hans De Bisschop over 8 years ago

Nathalie Blocry wrote:

I think we need a system where view-rights can be "inherited" from categories.
where you substitute the default "everybody" with "everybody who is allowed to view this category".
you can then still give the option to give view-rights to less people (like only one or two people who have view-rights on the category) but I think we should avoid the option of giving view-rights to more people (so to people who normally don't have view-rights on the category). this would be too confusing for the user.
If I, as a teacher, make a category where only certain people can view/read and only certain people can publish/post, I don't expect them to be able to "bypass" my wishes and publish something for other people there.

I like that idea a lot. I'm not a fan of being able to formulate exceptions either. It's not only confusing for the end user ... it'll also a nightmare for the administrator who has to figure out what went wrong when and if someone can't access something: were the category rights the culprit? the object publication proberties? the status? the tool? Better to enforce consistency then.

Nathalie Blocry wrote:

we want to be able to make standard categories in all our courses, mimicking some of the tools in 1.8 like "student publications", where everybody can post and read, "teacher publications" (documents) where everybody can read and only the teacher can publish and "dropbox" where only teachers can read and all students can publish. we cannot enforce that with the current system.

The more I think about it, the more I'm starting to wonder whether it was a good idea initially to merge all those tools into one. So far all we've gotten out of it is being forced to "hardcode" certain folders, misery with category rights and overal confusion at the side of the end-user. Is it really worth it? Perhaps something worth discussing.

Nathalie Blocry wrote:

We also need the functionality of the "group" documents that are only accessible to members of a group.
The functionality is there already offcours, you CAN publish only for a certain group, but it needs extra actions from the user.
In the long run everybody will get used to the "publish for" system, but for the time being we want to keep everything as simple as possible and avoid mistakes.

The first thing that comes to mind is some kind of filter for the documents tool based on the group(s) you're a memeber of: course groups and/or subscribed platform groups. If you're using that "filter" publishing could automatically be for that "filter" (= group) I think that's more or less similar to something you proposed elsewhere for publishing in categories in general.

#4

Updated by Sven Vanpoucke over 8 years ago

Just want to note out that using the rights system for the view right is currently not a good idea, and is currently not implemented in the weblcms. (because in the weblcms the rights are splitted to the actual rights system for publish, edit and delete and the view right is done through the publish for).

I do agree that we should also provide this functionality for categories, this is very related to another issue which I currently can't find which states that it is not possible to hide entire categories / folders which was possible in the 1.8 version. But I propose that we extend the categories to define extra properties instead of using the rights system.

#5

Updated by Nathalie Blocry over 8 years ago

Sven Vanpoucke wrote:

Just want to note out that using the rights system for the view right is currently not a good idea, and is currently not implemented in the weblcms. (because in the weblcms the rights are splitted to the actual rights system for publish, edit and delete and the view right is done through the publish for).

I think that is a very big part of the problem. mixing 2 right systems in the same application/tool does seems like a very bad idea, no?

#6

Updated by Sven Vanpoucke over 8 years ago

I agree that it isn't such a good idea. But I don't like to use the global rights system for such things because it's just TO heavy imho.

#7

Updated by Stefaan Vanbillemont over 8 years ago

  • Project changed from Chamilo LCMS Connect to Courses
  • Category deleted (2)
#8

Updated by Stefaan Vanbillemont over 8 years ago

  • Target version set to 2.1.0
#9

Updated by Koen Favere almost 8 years ago

  • Status changed from New to Bug resolved

Also available in: Atom PDF