|
|
Due to the volume of spam happening on our forums, posting is now restricted to verified members only. If you're not verified, drop us a note with your username.
|
|
Home > FlexCMS Support Forum > User Help > General Support Requests > USER PERMISSION LEVELS
FlexCMS Support Forum
USER PERMISSION LEVELS Started January 9, 2007 @ 5:13pm by cberks
|
Post Message |
|
|
USER PERMISSION LEVELS | January 9, 2007 @ 5:13pm | As permission levels are numbered it appears at first glance that they are hierarchical -- could you confirm that this is not so and that users at level 49 (say) could have permission set that users at level 51 do not.
Next question -- is there a way to allow sub groups of users to access sub groups of articles for example ie permissions by category?
Regards, Chris |
|
|
|
|
|
|
| |
DCSun Administrator
Posts: 625 |
|
|
| January 9, 2007 @ 5:29pm | Chris,
They are hierarchial in how specific content is limited by number. For example, a page with a Minimum View Level of 10 would be accessible by users in group 10 and any group higher.
In terms of assigned permissions, though, no, levels above do not necessarily inherit the permissions of the levels below them.
Also note that level 100 automatically gets every permission assigned to it, and as such that should be reserved for only the highest level users on the site.
Users in level 50 and above will also be able to synchronize the license keys, which isn't really a problem, but I thought you would like to be aware that the option will be displayed to them.
Unfortunately you can't assign users to certain categories with the current system. The whole way permissions work is scheduled to be revamped in the next version, so feel free to let us know exactly how you'd like it to work and we'll try our best to integrate your ideas into it.
David
FlexCMS v3.2 Has Been Released! |
|
|
|
Last Edit: January 9, 2007 @ 5:32pm by DCSun | |
|
|
|
| |
|
|
User Permission Levels, ACL, user groups | March 27, 2007 @ 3:11pm |
Quote (DCSun)
Unfortunately you can't assign users to certain categories with the current system. The whole way permissions work is scheduled to be revamped in the next version, so feel free to let us know exactly how you'd like it to work and we'll try our best to integrate your ideas into it. |
|
Thanks: I'm looking forward to the next version. However, meanwhile I need to check out other products/options.
Security and quality control are my main concerns, since I would like to allow users to sign-in, post content for review (i.e. a proposal or portfolio or resume or whatever), receive permission to start a new group. At that point, the new user should be able to do the same -- review requests, monitor content, allow/deny members, review/edit content on the fly.
I want it to run like a newspaper might operate: a "top tier" of admins (i.e. executive level, superusers -- that'd be me), a small "editorial staff" (i.e. city desk, sports desk, business, arts, etc.), and an unlimited number of "reporters" (authorized users contributing stories/blogs/RSS feeds, etc.)
Minimal "group" functionality I would expect: ability to define 100+ groups in X tiers (i.e. min. 3 levels). I don't have a need for unlimited levels; however, there might be a good reason to do this a) if server performance is not severely degraded, and b) if it can be tied-into some Multi Level Marketing (MLM) compensation system.
Otherwise, I'd guess that a limited # of levels provides enough granularity for corporate intranets, retail store networks/catalogs, larger web design shops, worldwide clubs & organizations, etc.
The above would require "roles" (i.e. conventions used by other collaboration tools like Sharepoint): For documents -- "Reader", "Contributor", "Author", "Editor", "Owner" or whatever. And for groups: "Admin", and...?
Each group administrator should be able to setup its own groups, assign roles, and grant/limit permissions.
Regardless of the roles/functions, the minimum functionality should provide for Content Approval -- 0 to 3 approvers for a new document (effectively, a 3-tier hierarchy of approval). To facilitate collaboration and vetting content, it could be tied-into a secure wiki conversation. The approval hierarchy should be enforceable from top-down, meaning that if A is the sole approver for B, and B is the sole approver for C, C should not be able to post anything unless it's been approved by A.
The group hierarchy scheme should allow a "senior" group to block and/or deactivate users, groups, and content "below" them instantly.
Those are some minimal requirements to start with. I'd be interested in any comments/critique from other CMS users (or prospective users) out there. |
|
|
|
|
|
|
|
|
|
| MEMBERS
|
|
|