XenForo node permissions default to Inherit, but any custom value on a node takes priority over the inherited value at that level. This small rule causes some of the most stubborn access problems on boards that use several secondary groups.
The trap usually appears after a perfectly sensible promotion setup. Everyone remains in Registered, selected members gain a secondary group, and the parent category already allows that secondary group to view its forums. You open a child forum, leave the promoted group on Inherit, set Registered to No, and expect the inherited Yes to rescue the promoted members.
It will not. Understanding how XenForo resolves permission values helps, but node inheritance adds one extra rule people often miss.
Consider a member who belongs to Registered and Promoted. Both groups may have View node set to Yes globally, and the parent category may also permit access. If the child forum sets Registered to No while Promoted remains Inherit, the explicit child-node No can determine the result instead of the inherited allowance you expected.
Set Promoted to Yes on that child node and the calculation changes. XenForo now has an explicit Yes at the same node level to compete with the explicit No, and Yes has the higher normal permission priority. Nothing mystical happened. You stopped asking an inherited value to beat a value that was deliberately set on the node.
This distinction matters because secondary groups do not replace Registered. XenForo combines the groups attached to the account. A promoted member still carries the Registered group into the calculation, so restrictions placed on Registered remain relevant after promotion.
The pattern resembles ideas in hierarchical role-based access control, where role relationships reduce repeated assignments while specific authorization rules still need clear precedence. XenForo is not implementing that paper verbatim, but the practical lesson is similar. Hierarchy saves work only while you understand where a more specific rule takes over.
One-user anomalies deserve a different check. XenForo lets you customize node permissions for an individual user as well as a group, so a direct user entry can change the final result while every group row still looks sensible. Inspect the affected account’s user-specific node settings before rebuilding a promotion scheme that works for everyone else.
A global Yes followed by a node-specific No tells you the failure lives in the node path. Check the current node before climbing through every parent category. An explicit value there deserves attention first because current custom values outrank Inherit.
The opposite comparison is useful too. If global analysis already returns No, leaving every node permission on Inherit will faithfully carry the problem downward. Fixing parents or children cannot manufacture an allowance that the inherited starting point never contained.
Never adds one more boundary. An inherited Never permission cannot be overridden by a child-node Yes, so it should not be used as a routine way to keep ordinary members out of selected forums. XenForo reserves it for cases where the denial must survive competing allowances.
Numeric permissions need a separate mental model. XenForo uses the highest numeric value, so a lower node value cannot reduce a larger inherited limit such as a longer editing window. A local number that looks more restrictive may therefore leave the effective value unchanged.
After each change, analyze the same user on the same node again. Permission troubleshooting gets messy when you change groups, nodes, and test accounts together. One user, one permission, one node gives you a result you can actually trust.
The trap usually appears after a perfectly sensible promotion setup. Everyone remains in Registered, selected members gain a secondary group, and the parent category already allows that secondary group to view its forums. You open a child forum, leave the promoted group on Inherit, set Registered to No, and expect the inherited Yes to rescue the promoted members.
It will not. Understanding how XenForo resolves permission values helps, but node inheritance adds one extra rule people often miss.
Inherit is weaker than an explicit node value
Inherit does not behave like a Yes carried down from the parent and dropped beside every value on the current node. It means XenForo can use the permission inherited for that entry only while no custom value at the current level displaces it. A local No is therefore not merely another global No in the usual group calculation.Consider a member who belongs to Registered and Promoted. Both groups may have View node set to Yes globally, and the parent category may also permit access. If the child forum sets Registered to No while Promoted remains Inherit, the explicit child-node No can determine the result instead of the inherited allowance you expected.
Set Promoted to Yes on that child node and the calculation changes. XenForo now has an explicit Yes at the same node level to compete with the explicit No, and Yes has the higher normal permission priority. Nothing mystical happened. You stopped asking an inherited value to beat a value that was deliberately set on the node.
This distinction matters because secondary groups do not replace Registered. XenForo combines the groups attached to the account. A promoted member still carries the Registered group into the calculation, so restrictions placed on Registered remain relevant after promotion.
Parent permissions do not float above local overrides
A parent category is useful for avoiding repetitive configuration, but it is not an untouchable master rule. Child nodes inherit customized parent values until the child supplies its own custom value. Once you edit a permission on the child, you have created a more local instruction.The pattern resembles ideas in hierarchical role-based access control, where role relationships reduce repeated assignments while specific authorization rules still need clear precedence. XenForo is not implementing that paper verbatim, but the practical lesson is similar. Hierarchy saves work only while you understand where a more specific rule takes over.
One-user anomalies deserve a different check. XenForo lets you customize node permissions for an individual user as well as a group, so a direct user entry can change the final result while every group row still looks sensible. Inspect the affected account’s user-specific node settings before rebuilding a promotion scheme that works for everyone else.
The analyzer exposes the level where inheritance breaks
Use node-specific permission analysis on a real affected account after you reproduce the problem. The useful detail is not just the final Yes or No. Look for the node-level entries considered in reaching it and compare them with the global result for the same permission.A global Yes followed by a node-specific No tells you the failure lives in the node path. Check the current node before climbing through every parent category. An explicit value there deserves attention first because current custom values outrank Inherit.
The opposite comparison is useful too. If global analysis already returns No, leaving every node permission on Inherit will faithfully carry the problem downward. Fixing parents or children cannot manufacture an allowance that the inherited starting point never contained.
Never adds one more boundary. An inherited Never permission cannot be overridden by a child-node Yes, so it should not be used as a routine way to keep ordinary members out of selected forums. XenForo reserves it for cases where the denial must survive competing allowances.
Numeric permissions need a separate mental model. XenForo uses the highest numeric value, so a lower node value cannot reduce a larger inherited limit such as a longer editing window. A local number that looks more restrictive may therefore leave the effective value unchanged.
After each change, analyze the same user on the same node again. Permission troubleshooting gets messy when you change groups, nodes, and test accounts together. One user, one permission, one node gives you a result you can actually trust.
