|
Peter Schott
Topic creator
registered since: 03/17/2007
Posts: 321
|
I think I'm going crazy. I've tried to set up a new back-end group on our church site to let some of our people admin the various WEC_Discussion elements on our site. I've created the group, set their permissions to allow the various "Discussion" exclude fields, given them rights to add new pages/sys folders as needed for new blog setups. That part is probably working.
However, when I try to give them rights to the current pages and sysfolders, they refuse to show up. I go into the Access menu item as an admin and add that BE Group w/ all checkboxes and recursive on, but the page and sysfolders will not show up. I'm at a loss on what to do next. Any suggestions on what I might be missing? Does a lack of rights override "Allow" rights in TYPO3? I double-checked against my "Sermons" config and they seem to be really similar as far as Access-type grants to pages goes.
I'd love a hint or two on this one. I'm about at the end of my knowledge.
-Peter
|
|
Mark Johnston
registered since: 04/10/2009
Posts: 54
|
"Peter Schott" wrote:
... I've created the group, set their permissions to allow the various "Discussion" exclude fields, given them rights to add new pages/sys folders as needed for new blog setups. That part is probably working.
However, when I try to give them rights to the current pages and sysfolders, they refuse to show up. I go into the Access menu item as an admin and add that BE Group w/ all checkboxes and recursive on, but the page and sysfolders will not show up. I'm at a loss on what to do next.
Peter,
You're not alone on this one. Setting up permissions is a challenge, and there is more than one way to make it work, but many more ways to miss the mark. (Believe me, I've missed the mark more than once!)
Here's my take; there are basically four aspects of permissions in TYPO3. One of these is workspace access permissions, which I will assume is not necessary to consider at this time. That leaves three remaining: user interface ("Access Lists" ), DB and File Mounts (which control the contents of the user's Page Tree and File Administration windows, respectively), and Access privileges. All three are necessary in some combination to allow access.
In the WEC starter package, there are two levels of DB and file mounts provided, Content Editor level and Basic Admin level. These mount patterns are defined in the backend user groups of the same name. For your purpose, it sounds like you need to start with a copy of the Content Editor group, perhaps call the new group Discussion Admin (or whatever makes most sense in your context) and make the backend group you have created a subgroup of this new group. If necessary, remove any subgroups that were included from Content Editor that are not necessary for the new Discussion Admin group. This new group will be well-aligned with the permission strategy that comes with the WEC Starter Package. Other permission organization strategies are possible, but unless you are already using a different organization I recommend continuing along the same lines for consistency.
The WEC Starter Package functional capability groups (for want of an official name for them) include Blog, Calendar, Devo, Forum, Map, News, Photos, Prayer, Sermons, Serve and Staff Directory. Each of these is tied to a specific set of user interfaces (through their Access Lists group settings and also has a given set of access privileges via the Access menu. The Content Editor and Basic Admin groups bundle a combination of these capabilities into one group, along with DB Mounts and File Mounts appropriate to the page tree and file organization of the WEC Starter Package. Users are assigned to the bundled group, which allows the capabilities to be altered independently as needed for your particular site.
It's probably a good idea to create a prototype user (discussionadmin comes to mind) whose primary backend user group is the Discussion Admin group. As administrator for the site, you can log in using this user and verify that all the functionality exists that you wish the folks in this role to have. Creating new users based on this user becomes a process of copying the prototypical user and adjusting the name, email address, etc.
I hope this is clear enough to help you create the capabilities you need in this new role.
Peace,
--Mark
[This article was edited 2 times, at last 02.09.2010 at 02:22.]
|
|
Peter Schott
Topic creator
registered since: 03/17/2007
Posts: 321
|
Mark,
I appreciate the tips, but I have a pretty modified website from our original Starter package. I think our starter package may have been a very early TYPO3 3.x package (possibly 2.x, but I don't think it's quite that old). I do know that we modified the site from the original home page as a link to some page within the tree to an actual page as the home page, which I'm pretty sure resulted in blowing away any permissions that were tied to that "virtual" home page.
In any case, what I would normally expect to show up for basicadmin and content editor doesn't seem to show up now. Trying to add access to the system folders and their contents is giving me fits. In fact, I know I've set permissions using the "Access" menu for this BE group, but nothing's changing when I switch over to that user to test it out.
I would definitely love to make copies and go from there, but enough has changed that I need to get the original access rights working first and for some reason, they don't seem to be working the way I think they should.
I appreciate the suggestions and look forward to being able to take that more simplified approach.  If you have any idea why my Access permissions may not be working the way I think they should, I'd appreciate the pointers.
-Peter
|
|
Mark Johnston
registered since: 04/10/2009
Posts: 54
|
"Peter Schott" wrote:
Mark,
I appreciate the tips, but I have a pretty modified website from our original Starter package.
...
I appreciate the suggestions and look forward to being able to take that more simplified approach. If you have any idea why my Access permissions may not be working the way I think they should, I'd appreciate the pointers.
OK, I think what I hear is license to go in a whole different direction ... 
You need to have DB Mounts as well as access privileges, so at this point I would go ahead and add one or more DB Mounts to the new group you have created. (You do that in the Mounts and Workspaces tab.) Make sure that the group also has the Edit Live (Online) checkbox checked. The most important DB Mount is probably the root page (may be your home page). Next
most important are any sysfolders that standard users need access to. Also choose any file mounts that users need to use to as sources for pictures, etc. You should not select any mount points for a page or folder that you have already selected an ancestor page or folder in the site tree as a mount point.
Your group also needs Access Lists that relate to Page operations (Modules Web, Web>Page, and Web>List at a minimum, Tables Page and Pagecontent and any other user interface fields you want the user to have), and also Standard page, Shortcut/Link to External URL and Sysfolder Page types.
You've already set up Access rights for this group; you should be able to check the Access list by selecting this group in the group list then selecting each of the mount points you set up for that group from the page gree and verifying that the access is granted to this group as you expect.
I did the above for a new group I created, and created a test user with only this group as a subgroup and I see the page tree I selected as the mountpoint-- I'm using the WEC local server on Windows. With no allowed exclude fields, all I see is the Pagetitle when I try to edit a page, but that's due to the need for more refinement in the Access Lists.
These are all the settings that you will need for your group. I checked, and removing the DB Mount and then logging back in as the same user I can still see the Page module listed on the left, but nothing in the middle pane even though I did not change the Access permissions.
Hope this helps you identify the missing setting.
Peace,
--Mark
[This article was edited 4 times, at last 03.09.2010 at 03:22.]
|
|
Peter Schott
Topic creator
registered since: 03/17/2007
Posts: 321
|
Mark,
Thanks for the pointers. You've confirmed that I was actually doing things correctly and the information is good for the next person setting up security. I really appreciate the detail you've put into the responses.
The issue seems to be resolved and I was actually doing the correct things to set up permissions. It seems that there's a bug in the be_acl code that results in the cache not being cleared properly when changes are made. I was making my changes, then using the "switch user - switch back" functionality to test. Because the cache was still active, it looks like I never saw the new settings. I logged in today and everything was as I expected (and probably more than necessary). Jeff Segars suggested dropping back to v1.3.3 of be_acl as that doesn't use the same caching settings so that will likely be my next step.
Anyway, the problem is resolved as far as I can tell and I can now proceed to train without all of the noise of a full admin account.
Thank you again for your help and for following up on such an obscure issue.
-Peter
|
