• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Are permissions IP based?

CBI Web

Well-known member
#1
The thread title might sound like a strange question, but I'm not sure why my permissions are working the way they do.

Starting with a fresh install, with whatever default permissions there are, as a super admin I did the following:
  1. In Firefox I created a user named Test1
  2. Set Test1's permissions to be denied starting threads in a specific node.
  3. In Chrome, logged into the forums as Test1. Permission setup works as expected.
  4. In Firefox, still logged in as Administrator, I now cannot start threads in that same node.
So either the permission system reads IPs, or I just don't understand the system yet. Advice please?
 

dieketzer

Well-known member
#2
The thread title might sound like a strange question, but I'm not sure why my permissions are working the way they do.

Starting with a fresh install, with whatever default permissions there are, as a super admin I did the following:
  1. In Firefox I created a user named Test1
  2. Set Test1's permissions to be denied starting threads in a specific node.
  3. In Chrome, logged into the forums as Test1. Permission setup works as expected.
  4. In Firefox, still logged in as Administrator, I now cannot start threads in that same node.
So either the permission system reads IPs, or I just don't understand the system yet. Advice please?
is your admin a member of the 'registered' usergroup?
did you set registered membergroup perms to 'never'?
never will always override yes or no across the board.
set the perm to 'no'
 

CBI Web

Well-known member
#3
Yes, as a matter of fact, Administrator was in the Registered usergroup! And that group was indeed denied. I put myself into the Administrative group and all is well. Thanks! (y)

(kinda wondering if that was a brain fart, or was it different with the other software I used to use...)
 

CBI Web

Well-known member
#5
Yes, I was reading through that, but couldn't see anything that helped in this case. It's probably there between the lines somewhere. :)
 

Brogan

XenForo moderator
Staff member
#6
Yes, I was reading through that, but couldn't see anything that helped in this case.
It's mentioned very early on in the document:
A user may belong to more than one user group and may have specific permissions applied as well. When we calculate their final permission values, we look at all of these permission sets. The final value is taken from the highest priority value (see below).
Permission value priority is set in this order: (highest priority first)

  1. Never – this will not grant the permission. This can never be overridden, so should be used sparingly.
  2. Allow – this will grant the permission.
  3. Not Set (No) – this will not grant the permission. This is the lowest priority value; any explicit allow will override this.
Thus, if a user has not set (no) and allow for a permission, the final value will be allow. The Test Permissions system can help confirm that permissions are set correctly.
 

CBI Web

Well-known member
#7
Thanks, Brogan. I guess the problem was that I'm used to my previous software, where the permissions are more or less independent of each other. For instance, out of the box if I changed Registered perms in that software, Admin perms were not affected at all. dieketzer's post pointed me in the right direction to learn that by default in XF, Admin is in the Registered group, not its own Admin group. I had to set it. Far as I can tell, that sort of thing isn't mentioned in the manual? Or it's somehow not explained clearly. I dunno.
 

Brogan

XenForo moderator
Staff member
#8

CBI Web

Well-known member
#9
So it's basically a cascading principle, like stylesheets. Just as you might do this:
Code:
body {
font-size:100%;
}

#sidebar p {
  font-size:80%
}
You would set XF permissions like this (expressed in CSS context as an example):
Code:
All members {
group: Registered;
permissions: normal;
}

#User1 {
group: Administrative; /* secondary group */
permissions: admin status;
}
 

Brogan

XenForo moderator
Staff member
#10
Not quite the same, as with CSS it's (usually) the last one in the cascade which takes priority.

With permissions, Never has the highest priority and will override the same permission in every other group.
 

CBI Web

Well-known member
#11
Right. But yeah, I understand what's going on now. Mainly have to remember that everyone is Registered, and stays there, and I simply add or take away secondary groups and perms as needed.

CBI Web primary = Registered group w/normal perms
Secondary = Administrative group w/added perms for admin duties.
Third = Moderating group w/added moderator perms

How many extra groups can a member be added to?