Reply to thread

Message: [QUOTE="Bombastus, post: 91914, member: 2178"] XenForo permissions have no automatic default value, so a newly installed add-on can introduce a feature that nobody can use yet. The install itself may finish cleanly, with the add-on enabled and visible in the Admin Control Panel. The missing piece can be permission assignment rather than a broken template, route, or installation. You can reproduce the behavior in minutes on a development install. Create a new permission, leave it unassigned, and the protected control disappears until somebody receives permission to use it. [B][URL='https://goldmidi.com/community/threads/quick-guide-to-understanding-xenforo-permissions.16992/']XenForo’s layered permission rules[/URL][/B] only resolve the values that actually apply to the affected user and groups. Installing a permission definition does not automatically decide which existing groups should receive Yes. [HEADING=2]A successful install can still leave features unavailable[/HEADING] Start with the symptom. An add-on appears in the installed list; its options may exist, yet members cannot see the new button or open the new feature. Before reinstalling files, inspect the add-on’s permissions for the affected user group. A fresh flag permission with no assigned allowance effectively leaves users without access. XenForo deliberately separates defining a permission from granting it. The developer can create the switch, but somebody still has to decide who should get it. The security principle behind [B][URL='https://doi.org/10.1109/PROC.1975.9939']fail-safe permission defaults[/URL][/B] favors withholding access when no affirmative authorization exists. For an administrator, the practical consequence is simple. A quiet feature after installation may be behaving exactly as its permission rules require. Do not assume the Administrative or Moderating group automatically receives every permission added by third-party software. XenForo combines group memberships, and staff commonly receive many ordinary abilities through Registered plus their secondary groups. An add-on can introduce a separate permission that still needs an explicit allowance. Check the real account with Analyze permissions when the setting looks correct, but the feature remains absent. A group screen shows what you intended to configure. The analyzer shows what XenForo actually calculated for that user. [HEADING=2]Installer code decides who receives a new permission[/HEADING] Add-on authors can assign permissions programmatically during installation. XenForo provides setup helpers for global, numeric, content, and administrator permissions, so an author can make a new permission available to sensible groups without asking every site owner to configure it manually. A careful installer does not have to hand the permission to everybody. It can copy eligibility from an existing permission. A new thread-management feature, for example, can be granted only to groups that already possess an appropriate thread permission. So two add-ons can behave differently after equally successful installations. One author may apply a new permission during setup. Another may leave every site owner to choose the groups manually. Neither outcome proves the add-on failed. Automatic assignment deserves inspection too. Granting a powerful new capability simply because someone belongs to a broad staff group can be too generous for sites with split responsibilities. Review newly added permissions after installation even when the feature works immediately. Administrator permissions are separate again. Access to the Admin Control Panel does not mean every administrator should automatically receive every control introduced by an add-on. Limited administrators are useful precisely because their ACP powers can be narrower. [HEADING=2]Upgrades can expose the same permission gap[/HEADING] Permission surprises do not only happen on first installation. An add-on update can introduce a new permission long after your original groups were configured. Existing users may lose access to a new control because no previous setting existed for the upgrader to preserve. Good upgrade logic can assign the new permission conditionally and trigger the necessary permission rebuild. Without such handling, an administrator may need to review the new permission manually. Saving unrelated group settings blindly is a poor substitute for finding the new rule. Treat a feature that vanishes immediately after an update differently from one that has never worked. Compare the add-on’s release changes with its current permission list, then analyze one affected account. Look for a newly introduced permission before changing broad group memberships. Cached permission combinations matter after programmatic changes as well. XenForo rebuilds permissions during normal workflows, and upgrade code can explicitly enqueue a rebuild when new values are applied. If the stored permission looks correct while the live account behaves differently, a rebuild issue becomes more plausible than another round of random edits. Keep server file permissions out of this diagnosis. An installation failure involving unwritable files needs a server-side fix, while an installed add-on whose controls are hidden can be an authorization problem inside XenForo. Similar wording, completely different layer. Check the permission definition, the group assignment, and the analyzed result in that order. If all three agree, move on to the add-on’s own logic instead of loosening unrelated forum permissions. [/QUOTE]

Name