Fork me on GitHub

User Permissions aginst Group permission - looks like a bug!  Bottom

  • I wanted to post this to the bugtracker, but this buggy thing won't allow me to, while itself states that I'm logged in. Sorry to bother you here, but I think it's important:

    For quite a while I've been researching why in the world I could not set admin rights in the group permission like I wanted to. (Actually I could set them, but it didn't work, especially with NS-AddStory, wich seems to be a problem for lots of people who want to work around the article approval procedure!)

    Today I found out: I had set some user permissions for the component Menublock to read. I know that user permissions should override group permissions, but I assume that it's just for the component actually set.
    In this case setting the permissions for Menublock hindered almost EVERY group permission that was set to admin, especially NS-AddStory, Messenger, well, actually it's a long list...

    I think this is not inside what the permission system is set up for. Maybe someone knows better and can explain why this would be in order.

    I work around this now by setting these user permissions for Menublock to admin, and believe you me, I have invested enough time to try any other possible way.

    That's it. Maybe someone can report this to bugtracker, if this thingy allowes him to ;)

    Regards

    Schouw
  • Just remember one thing about permissions...

    Permissions run from top to bottem. If User X is in Group Y and Group Y is not allowed to user Module X, but at the above the rule that states that User X has permission to use Module X. User X will in fact be able to use Module X. It's not because the user permission carries more weight, it's because it's higher on the list.

    That's why you should see Admin .* .* at the top, this keep the Admin free to do whatever they need to.

    Hope this helps,

    Joe
  • Of course I know these rules.

    The point is that a single user permission set for Menublock:: to 'read' seems to influence other components, like NS-AddStory, in group permissions, wich obviously should not be the case. I didn't find out if this is somehow related to the implementation in the Menublock or the permission system itself.

    I'll give you an excerpt of my *working* permissions...

    Code

    Group Permissions:

    Admins Menublock:: Control Panel:(WIKI MS|WIKI TR|WIKI JL|PROJEKTE MS|PROJEKTE TR|PROJEKTE JL): none
    Admins .* .* admin
    Users Shoutbox_Block:: Shoutbox:: admin
    Users Pollblock:: .* add
    Users Menublock:: Control Panel:(ARTIKEL VERFASSEN|About WIKIS|SUCHEN|FAQ|ARTIKEL-ARCHIV|TROUBLE TICKET): read
    Users Menublock:: Control Panel:.* none
    Users Topics::.* .* add
    Users Stories:: .* admin
    Users Wiki:: .* edit
    Users .* .* comment
    Users Stories::Category .* add
    unregistered Loginblock:: .* read
    unregistered Admin Messages:Messagesblock: .* read
    unregistered .* .* none


    User Permissions:

    BV Menublock:: Control Panel:(WIKI BV|PROJEKTE BV): admin
    JL Menublock:: Control Panel:(WIKI JL|PROJEKTE JL): admin
    MS Menublock:: Control Panel:(WIKI MS|PROJEKTE MS): admin

    TR Menublock:: Control Panel:(WIKI TR|PROJEKTE TR): admin


    The user permissions are set for sort of personal menu. And now as soon as I set these user permission below admin (only read is actually needed here), they are for instance no longer able to admin stories via NS-AddStory, like they should be as set in group permissions.
    All users in user permissions are currntly in the group users. I had these also set up seperatly with an extra subadmin group - didn't help either.

    So my question goes, how can the permission set for Menublock be related to permissions set for NS-AddStory?

    Any idea?

This list is based on users active over the last 60 minutes.