Users need to relog for permissions to take effect #199


  • Defect
  • Replied
Open
Assigned to _ForgeUser6902175
  • _ForgeUser5803084 created this issue Feb 7, 2012
    Tester

    Describe to us the issue that you're having:
    We have users in the default group by... uhhhh... default.  When we promote them to the registered group (either through the webgui, or using the commands, or our Greylisting plugin) the prefixes show correctly, but the users do not get access to the permissions from the registered group until they log out and log back in.

    Which steps will reproduce this problem?:
    1)  Add another group to a user
    2)  Test permissions given by the new group - User gets errors that they don't have permission.
    3)  Have user relog - test again - permissions work as expected
    ....

    Do you have an error log of what happened?
    Nothing of use, no.  CB b1846 and bPerm 2.8.3

    Which version of bPermissions are you using?: (Please don't say "latest"!!!)
    2.8.3

    Which version of CraftBukkit?: (Please don't say "latest"!!!)
    b1846

    Which OS?
    Ubuntu 11.04

    Any other information we may need (plugins, configs, etc):
    Yes - will attach backup of permissions.

    Please fill out this form properly! Failing to do so may result in your ticket being marked invalid.

  • _ForgeUser5803084 added the tags New Defect Feb 7, 2012
  • _ForgeUser5803084 added an attachment bPermissions_2.8.3.zip Feb 7, 2012

    bPermissions_2.8.3.zip

    <p>bPermissions Backup File</p>

  • _ForgeUser5803084 added an attachment bPermissions_2.8.3.zip Feb 7, 2012

    bPermissions_2.8.3.zip

  • _ForgeUser5803084 added an attachment server.log Feb 7, 2012

    server.log

    <p>server.log file - might be a mess - has the results of p debug in it.</p>

  • _ForgeUser6902175 posted a comment Feb 8, 2012

    1) Add another group to a user

    What is the command you are running to do this?

  • _ForgeUser6902175 self-assigned this issue Feb 8, 2012
  • _ForgeUser6902175 removed a tag New Feb 8, 2012
  • _ForgeUser6902175 added a tag Waiting Feb 8, 2012
  • _ForgeUser5803084 posted a comment Feb 8, 2012

    Usually I use the WebGUI to do it (I click the update button of course), but if not, then I use this series of commands:

    /world Utopia /user <username> /user addgroup <groupname> /p save /p reload

  • _ForgeUser5803084 removed a tag Waiting Feb 8, 2012
  • _ForgeUser5803084 added a tag Replied Feb 8, 2012
  • Forge_User_53439273 posted a comment Feb 8, 2012

    I'll work on this and see if I can track down the issue - lots of unit tests will be designed!

  • Forge_User_53439273 posted a comment Feb 8, 2012

    Initial testing:

    #################################################
    default, moderator, admin assigned to User 'user'
    'user' has groups:
    [default, admin, moderator]
    default priority: 0
    moderator priority: 5
    admin priority: 20
    test0 expected admin got admin
    test1 expected moderator got moderator
    test2 expected default got default
    #################################################
    default: permission.build:false
    moderator: permission.build: true
    admin: unset
    non-builder: permission.build: false priority: 100
    admin -> moderator -> default
    user has group: admin
    expected: true - user has permission.build:true
    addgroup: non-builder
    expected: false - user has permission.build:false
    remove permission.build from group: non-builder
    expected: true - user has permission.build:true
    
  • _ForgeUser5803084 posted a comment Feb 8, 2012

    I am not sure if this is related or not, but, something is funky with my setup. I cannot see what I'm doing wrong.

    New backup file being uploaded:

    User in question: DiamondUP

    World: Utopia

    Problem:

    User used to have only: diamondplots j-mod level2 registered smoke

    I tried to assign the s-mod group as well. Permissions seem to take effect (user relogged, so can't be sure if he had the same problem as described on the ticket), but the [s-mod] prefix does not show - it still shows his [j-mod] prefix. If I remove the j-mod group, he gets the [MAJ] prefix - which is given by the level2 group.

    I fully admit this may well be a bChatManager problem. Probably is in fact. Can anyone confirm?


    Edited Feb 8, 2012
  • _ForgeUser6902175 posted a comment Feb 8, 2012

    <<reply 532271>>

    Could it be that he is adding a group to a user, not setting the group? (adding group means the old group is kept)

  • _ForgeUser5803084 posted a comment Feb 9, 2012

    @Sayshal: Go

    I do a bit of both. I can't seem to see a difference when I do it. When I add a group (not removing another group) I need to relog for permissions. If I add a group and remove another group, I seem to need to relog for permissions to take effect.

  • _ForgeUser6902175 posted a comment Feb 10, 2012

    @TnTBass: Go

    Only reason I'm asking is because I'm not having this issue. I know this is the old command system but try this:

    ./perm <worldname> setgroup <groupname> <username>

    See if you get permissiosn properly from that. If you do, this might be the new command system? Doubt-able but worth trying?

  • _ForgeUser7930329 posted a comment Mar 30, 2012

    I believe I reported the same issue for Version 1.9.x... (Ticket #79)

    After a /p reload the permissions are correct for the user, but it's extremely nasty to do so - especially when the user who promotes someone is not an bPermissions-admin (like Mods...).

    What's about completely recalculating the players' permissions when changing his group membership?

  • Forge_User_53439273 posted a comment Apr 8, 2012

    That's what's done... I'd assume it works, but hey I'll recheck all the logic.

  • _ForgeUser8129395 posted a comment Apr 10, 2012

    I have bPermissions v2.91 And bukkit 1.2.4-R1 - build 2126

    I get this issue from time to time.

    I have created my own plugin that uses the ApiLayer for modifying permissions. It seems as if when a user gets promoted to the next rank in their track, they lose some permissions... possibly from the original group.

    The way i promote is: First remove the old group from the user, then add the next group in the track.

    I have also noticed that if they travel between worlds their permissions are fixed. My current temporary fix is to use my plugin to override the permissions check and allow the commands to run as intended; however, it would be nice to get the permissions check working properly.

    I wish I could give a solid procedure to recreate this error, but so far it seems like for some reason, some users have permission to use the command, while others do not... even though both users are in the same group and should have the same permissions.

    One other possibly related issue to this problem is i notice that permissions remain on a user when they travel between worlds. This has happened often with the mcmmo plugin. In the survival world, on the server, we have mcmmo. Survival world connects to hub world, which is used to connect to all other worlds. If a user travels from survival world to hub world, then they still have the mcmmo permissions even though in hub world they do not have the mcmmo permissions node. The only way to prevent this is to negate the mcmmo permission in hub world. Is this an intended feature of the plugin?


    Edited Apr 10, 2012
  • Forge_User_53439273 posted a comment Apr 11, 2012

    This issue is a superperms one, rather than a bPermissions one, but I'll add further logic checks and see if I can get it to detect updates.

    Do you mind sending me the source for your plugin so I can double check all my code that you're accessing?


To post a comment, please login or register a new account.