As designed Usergroups and Permissions - error when testing as user

Don

Member
Sorry to jump in like a "me too" parrot, but I'm having some issues that I did not notice before.
A user pointed out to me that she couldn't edit her post and wanted to correct a spelling error. I had made a wrong entry in the Usergroup config, so I set "Edit post by self" to Allow.
I tested the user's permissions and her posts still do not show the 'edit' option. I checked the Node settings and the Category setting for that node and found them set to Allow.
All entries in user's individual record were set to Default. I changed them to Allow, except for the Moderator settings.

I can't swear that something changed, but I was pretty sure everything was working properly...possibly before the latest upgrade.
But for now, I am unable to allow users in the Registered group to edit their posts. Any ideas?
 
But for now, I am unable to allow users in the Registered group to edit their posts. Any ideas?
The permission is definitely "Edit post by self" under Forum Permissions.

I just tested and confirmed this using my test user group.
 
I just tested it with a user from a different group, with the exact same settings and he can edit.
For some reason the changes I make to the original user are not being saved in the database.
I went one step further than refreshing Firefox... closed it and reopened.
I think I will take a peek at the database.
 
I just tested it with a user from a different group, with the exact same settings and he can edit.
For some reason the changes I make to the original user are not being saved in the database.
I went one step further than refreshing Firefox... closed it and reopened.
I think I will take a peek at the database.

Closing and opening doesn't necessarily remove cache in that scenario. A CTRL/CMD + F5 is certainly recommended.
 
Well, several hours later, I'm still not able to change this user's permissions. I'm pretty sure I have a good understanding of how it all works after all this practice.
I set up a dummy usergroup and put a dummy user in it. When I tested his permissions, it showed that he could not edit his posts, which I had set to 'allow'.
Then I logged on as him and the Edit link showed up in his post. I previously flushed the Firefox cache and history every way from Sunday. I even switched to
Safari (iMac) temporarily with the same results. Then I flushed the Xenforo database caches.

I'm really stuck here now. I don't have a clear picture of who can do what. One usergroup shows up as having Moderator permissions which are all set to Deny, but apparently only
when I view one of the members with the Test function.
The inconsistent feedback that I am getting on the screen has got me totally confused now. I don't know what to do next. This has really got me whipped.
Any encouragement would be appreciated.
 
Hmm. I am familiar with the permission system. I can take a look at your problem if you want to trust me with your admin login. I would also need the name of the problem user as well as instructions to reproduce the issue.
 
Hmm. I am familiar with the permission system. I can take a look at your problem if you want to trust me with your admin login. I would also need the name of the problem user as well as instructions to reproduce the issue.
Thanks, Jake. I think it's time for another pair of eyes on this. Send me your email in a PC and I will send you the info and attachments.
 
I have just about exhausted all avenues on this problem. Thanks so much to Jake for verifying my config and assuring me that I have not gone off the deep end.

Since I am out of ideas, I will just report the status here for anyone who is interested. I seem to be the only one having this problem.

Basically, the Test Permissions function LIES to me constantly. It does not show the actual permissions of the user being tested. In fact it show that they have Admin permissions in some cases.

I know the results of the test are not real because:
  1. I can log in as a dummy user and see which actual permissions are configured. As Admin, using the Test Permissions function on the same dummy user, the permissions are different.
  2. Jake and I have checked the actual permission settings and found them to be correct (many times).
  3. The bogus information shows up on different machines, PC & Mac and different browsers (Firefox, Safari, IE).
Here are the steps I have taken to eliminate the possibility of a browser cache issue:
  1. Flushed cache (within XenForo)
  2. Deleted browser history, cache, saved pages.
  3. Tried test on different computers, some of which have never accessed the site previously.
  4. Thoroughly examined MySQL database. I'm no expert, nothing jumped out at me.
  5. Ran "repair database" on server.
  6. Upgraded to ver. 1.0.0 Beta 3. No change.
Here's an example of what I see when I am in Test Permissions mode. User X should be able to Delete and Edit his own posts. His posts show only that he can Edit, but not Delete. It also shows that he has Delete, Edit and IP address links in MY posts (Admin). But all of this is untrue because I can log in as User X and my permissions are as set in user config.

I am a pretty good troubleshooter and don't give up easily, but this one has me stumped. The problem is consistent across different clients, which points me to some consistency in the database or on the server. What could cause that? After upgrading to Beta 3 and still having the identical experience, I am really baffled. And why is nobody else having this issue? Which templates are involved? (Could one of them be corrupted from Beta 2 but not replaced in Beta 3?)

By the way, I think Test Permissions was working correctly when I first installed Beta 1, but I can't be sure now.

Test Permissions is really a great tool if it works right. It is useless to me now, but at least I know that if I carefully set the permissions they will act as intended. I just have no way to verify them.
 
I didn't check all settings and permissions. Rather I tried to reproduce the problem but couldn't. The edit / delete links were showing correctly in test mode and when logged in as the actual user.

I can look again if you want me to check another user that is having the problem. I just need instructions to reproduce the problem.
 
Have you still seen issues with this in the latest release? There have been some permission calculation tweaks if I recall.

Secondly, I've added a clarification to something in the permission tester that might not've been clear before. It relates to permissions like editing your own posts. The permission tester applies someone else's permission concepts to your user. This means that if they can only edit their own posts, then you can only edit your own posts (not their posts). Having this work differently would create some very strange inconsistencies.

With that caveat in mind, if you're still having problems, then send me login details to have a look and I'll see if I can track it down. There's no reason I can see for the permission tester to give different permissions.
 
Thanks for asking, Mike. The 'Test Permissions' function seems to be working much better after upgrading to Beta 5.

When I am logged in as Administrator and test permissions for user "John", the only permission I see in others' posts is 'Report', which is as it should be. I set John's usergroup to have Edit Own Post privileges for 12 hours. The only inconsistency I see is when looking at a post he made an hour ago. It does not show Edit as one of his permissions. Everything else seems fine. I should emphasize that the permissions always worked as configured. It was just the Test function that was not reporting correctly.

I will do some more testing and let you know if I see anything else that appears inconsistent. Thanks again.
 
Try looking at one of *your* posts within the last 12 hours (and one outside that range). That's what I meant about it applying the permission "concepts" to you. You're still logged in as you, it's just as if you changed your user group configuration to match his.
 
To bad we couldnt just log in as user. I know there are some privacy concerns but that made alot more sense when it came to trouble shooting some of these usergroup permission issues.
 
Top Bottom