Edwin Brown

v403 CMS Permissions

31 Comments

on Mon 22nd Feb '10 at 1:23pm (16119 Views)

In v402 CMS permissions were additive- each permission granted also granted the lower permissions. So, for example, if you had "Can Use HTML" rights you were also granted all other rights. There were several complaints about this, and it was clear that's not how the community wanted this. Also there were several people who wanted the ability to control access to view/download attachments.

Therefore we have changed how CMS permissions work. In v403 there are two linkages:

If you grant any rights you have granted "view". I think it's fairly obvious that if you want someone to be able to, for example, download attachments that you meant them to be able to view the page.

If you grant "Can Use HTML" you have also granted "create" rights. Again, if you meant for someone to be able to enter HTML in an article you must have meant them to be able to create the article.

Otherwise the rights are separate. So you could, for example, grant "publish" and "view" but nothing else. We also use javascript to display this relationship. So if, for example, you click "create" then the "view" list will be checked. If you uncheck "view" then all the other rights will uncheck.

Tags: permissions

Categories: ‎ vBulletin CMS

Email Blog Entry

« Static Pages Main CMS Query Counts »

Comments

Carnage- - Mon 22nd Feb '10 1:32pm

Would it be possible to add these permissions on a per content type basis? I know there is currently only one content type, but i'm sure there will be lots more over time (i've got one in the works)
Edwin Brown - Mon 22nd Feb '10 1:35pm

At the moment, no. That would require a database redesign and interface change. If you feel that's necessary please submit a feature request in Projects.
Darkshenron - Mon 22nd Feb '10 1:49pm

Thanks for letting us know Edwin, I see a great improvement but I still insist on what Freddie and David said in Bug 35610. No matter if that would allow people to set up useless permissions; the forum/user group permission system does allow to set up useless permissions, but at least it grants a 100% control over it.
Edwin Brown - Mon 22nd Feb '10 2:49pm

If that's what the community wants, it's easy to remove the code that enforces that. Is there anyone who objects to removing the code that enforces the two relationships above?
Lynne - Mon 22nd Feb '10 9:09pm

Thanks again for another blog regarding how the CMS works, Edwin. I find these to be very informative. Sometimes things get added, or changed, and it's good to hear from the developers about what is changing.
edenx - Tue 23rd Feb '10 3:34am

Originally Posted by Edwin Brown

If that's what the community wants, it's easy to remove the code that enforces that. Is there anyone who objects to removing the code that enforces the two relationships above?

I second this. I want 100% control on what the users can do or not. No relationships at all.

Thanks.
x626xblack - Tue 23rd Feb '10 9:45am

I agree. No relationships. Complete control to decide what is or is not allowed..... However you know you are going to have people who assume that granting one thing will grant a second....
Carnage- - Tue 23rd Feb '10 11:25am

Originally Posted by Edwin Brown

At the moment, no. That would require a database redesign and interface change. If you feel that's necessary please submit a feature request in Projects.

I feel its absolutly nessisary and i'm sure once more content types become avaliable a lot of other people will feel the same.

I agree. No relationships.

Can you give me any use cases that might require someone being able to use html while creating content but NOT be able to acctually create content?

I can slightly see the need for not being able to view content but being able to create it; so how about splitting that permission into 'can view' and 'can view own' equally, publish should be split 'can publish' and 'can publish own' (adding 'can publish others'* would be nice too) then you have

'create' implies 'can view own'
'publish' implies 'can view'
'publish own' implies 'create'
'html' implies 'create'

* this would create a really nice setup where by you can have a group of members creating articles which can only be published by another member of the group; essentially, someone else needs to review the content before it can be published.

Updated Tue 23rd Feb '10 at 11:32am by Carnage-
akia - Tue 23rd Feb '10 7:16pm

I don't get some people, why would you want them to remove the code that sets the links between permissions automatically just so you can feel that your "100%" in control. Its far more user friendly with it than without and like Edwin said it would be pointless to give one without the other. And if anything they need make things simpler rather than more confusing and this is a small thing that am sure will stops lots of forum posts and support ticket when people are asking why they can't create new articles when the've ticked the allow HTML but forgot to tick create content.

Updated Tue 23rd Feb '10 at 7:21pm by akia
Darkshenron - Wed 24th Feb '10 9:43am

Originally Posted by mattysheff

I don't get some people, why would you want them to remove the code that sets the links between permissions automatically just so you can feel that your "100%" in control. Its far more user friendly with it than without and like Edwin said it would be pointless to give one without the other. And if anything they need make things simpler rather than more confusing and this is a small thing that am sure will stops lots of forum posts and support ticket when people are asking why they can't create new articles when the've ticked the allow HTML but forgot to tick create content.

How frequently do you see someone asking why he can't access a forum to post in it even if he set to 'Yes' the permission Can Post Threads but he set to 'No' the permission Can View Forum in forum permissions? This is the same exact situation with the CMS.
At most, just add a note saying that in order for any permission to work, you should also grant the "Can Read" permission.
ThorstenA - Wed 24th Feb '10 3:26pm

We also use javascript to display this relationship. So if, for example, you click "create" then the "view" list will be checked. If you uncheck "view" then all the other rights will uncheck.

Nice
Paul M - Wed 24th Feb '10 4:58pm

I take it these relationships only work when access is granted, not when its removed - i.e. if I remove the "Can Use HTML" I do not want to remove any other "create" rights.
melbo - Thu 25th Feb '10 12:52am

So I will be able to set "Can view" for Unregistered/not logged in but disallow them from downloading attachments?
sadikb - Thu 25th Feb '10 2:14am

Hi, there is a very strong need to separate Article Permissions with Section Definition Permissions. At the moment if someone can edit or publish articles he can also edit the section definition page. I mean if you have a MOD whom you have granted edit article rights, he can also change the section layout, 1 column two column etc... That's really dangerous because unsuspecting Mods may accidentally mess up all the section Display settings.

Should I post this as a BUG?
lightbox - Thu 25th Feb '10 10:03am

Please remove the automatic relationship of permissions!
We need to setup special permissions for users and an easy way to (temporary) switch off "create" permissions without removing all the other special (individual) permissions.

Thanks
Martin
Edwin Brown - Thu 25th Feb '10 10:21am

Originally Posted by sadikb

Hi, there is a very strong need to separate Article Permissions with Section Definition Permissions. At the moment if someone can edit or publish articles he can also edit the section definition page. I mean if you have a MOD whom you have granted edit article rights, he can also change the section layout, 1 column two column etc... That's really dangerous because unsuspecting Mods may accidentally mess up all the section Display settings.

Should I post this as a BUG?

In the current working branch I have set so only Publishers can edit the section page. That's not the same as having per-content-type permissions, which would require an interface redesign. I've asked Don to review the current interface, so I can's say what will be in v4.03.
Edwin Brown - Thu 25th Feb '10 10:23am

Originally Posted by Edwin Brown

In the current working branch I have set so only Publishers can edit the section page. That's not the same as having per-content-type permissions, which would require an interface redesign. I've asked Don to review the current interface, so I can's say what will be in v4.03.

That's already in the code, as I explain in the blog, and will be in v4.03. The only issue under discussion is whether admins should be able to set combinations that are internally inconsistent, such as "edit" but not "view". Since the majority seem to want that, I've removed all the links and all combinations are now available.
Darkshenron - Thu 25th Feb '10 3:25pm

Thanks Edwin.
Rayiw - Mon 1st Mar '10 8:09am

Hi Edwin,
I'm using 4.0.2 and cannot display attachments for unregistered users to download.
Do I need to wait for version 4.0.3 to support this?
Under ACP attachment permissions, the unregistered group is missing.

Thanks
Edwin Brown - Mon 1st Mar '10 11:34am

Originally Posted by Rayiw

Hi Edwin,
I'm using 4.0.2 and cannot display attachments for unregistered users to download.
Do I need to wait for version 4.0.3 to support this?
Under ACP attachment permissions, the unregistered group is missing.

Thanks

No, there's something else going wrong. In v402 you can't prevent users from viewing/downloading an attachment if they can see the article. At least as far as the permissions go. If you can't figure it out this sounds to me like a support ticket.