How XWiki rights and permissions decide who reads and edits a page
XWiki rights are granted to users and groups at the wiki, space and page levels, and the access a person actually gets is the result of how those grants are combined, not the setting on any single page. A user can hold view or edit rights from a group membership, from a direct grant, or from a rule higher in the hierarchy, and the rights that apply to a page depend on how allow and deny rules interact across all of these levels. For a team moving HR, finance or engineering content off a shared drive or an informal wiki, the design question is therefore not "who can see this page" but "which combination of grants produces that answer, and does it hold for every page underneath."
This is harder than it looks because rules are inherited and can be overridden in ways that are not visible from the page you are editing. A permission set on a space may be overridden by a more specific rule on a page, and a page that was copied or moved may keep rules that no longer match its new location. Deny rules deserve particular care, since they can block access that a broader allow would otherwise grant, and the reverse is also true when a page-level allow widens access beyond its space. Most permission errors in a wiki are not visible as errors at all. They show up as overexposure, where someone outside the intended group can read a salary sheet or a security runbook, and nobody notices until a person outside the group mentions it.
Teams usually need this work at three points: before go-live, when the first sensitive spaces are populated; during a migration, when permissions from an existing system are carried over or deliberately not carried over; and when a new department is added and needs its own spaces without inheriting access it should not have. In each case, the practical step is to write down the intended audience for each space, decide which groups hold which rights at which level, and then test effective access with accounts that represent each audience. Ask your implementation partner or internal administrator to show, in your own instance, how a sample page resolves for a user outside the group, rather than relying on the configuration screens alone.
This section concerns the rights model itself. Connecting XWiki to your identity provider, and deciding how directory groups map to XWiki groups, is covered in the identity integration topic. Reducing the attack surface around guest access, scripting rights and the servlet container is covered in the hardening topic. Confirm with your own administrators which XWiki version and database you are running, because the exact rights screens and their behavior can differ between lines, and check the release notes for your version before relying on a documented inheritance rule.
Which rights objects and levels XWiki uses
XWiki's rights model rests on a small set of objects: users, groups, the three levels where rights apply, and the rights themselves. These cards describe each building block and the decisions it forces. Read them before drafting a permission matrix, because a choice made at one level affects how the others behave.
Users and groups
Users are individual accounts, and groups collect them so a right can be granted once to many people. Confirm which default groups your installed XWiki version creates, and check how it treats guest access as a separate case. Decide early whether group membership will be maintained inside XWiki or synced from your directory, because that choice determines who can change membership. Adopt a naming convention so reviewers can read a group's purpose without opening it.
Wiki, space and page levels
Rights can be set at the wiki, space and page level, and a page inherits from the space it sits in unless a rule overrides it. Use space rights for most team boundaries and keep page rights for exceptions, since page-level grants are harder to review later. Map your knowledge base structure before setting any rule, because moving a page or space can change which rights apply. Test inheritance with a non-administrator account on a sample space before rollout.
Core right types
The everyday rights include view, edit, comment, delete and admin, and each applies at the level where it is set. View controls whether a page is visible at all, edit controls changes, and comment controls discussion. Confirm the exact right names and how they interact in the version you deploy. Test delete and admin separately, because they affect content and rules beyond a single page. Keep a short matrix showing which role holds which right in each space.
Programming and script rights
Programming and script rights let a user run server-side code through scripts and macros, which reaches well beyond ordinary page editing. They are high-impact, so grant them only to a small, named set of trusted administrators. This topic is covered in depth on the XWiki security hardening page, which addresses scripting rights alongside guest access. Review who holds these rights after every role change and during each upgrade.
Wiki administration and global settings
Wiki administration rights sit above spaces and cover settings that affect the whole installation, such as global configuration, extension management and wiki-wide access defaults. Because these settings apply to every space, one change can alter access to many pages without touching any page directly. Limit this role to platform owners, record each change, and confirm which settings your version places under global administration before finalizing your permission matrix.
How allow, deny and inheritance resolve on a page
To predict whether a user can view or edit a page in XWiki, you need three things: the level at which each rule is stored, the order in which those levels are checked, and the way a deny at one level meets an allow at another. Most access surprises come from assuming a rule applies in one place when it is actually evaluated in another. Treat the rights model as a set of rules you can trace, and write down the trace for every page type your knowledge base depends on before you publish the structure.
Rules are stored as rights objects on wiki, space and page documents, and a page inherits from its space unless it carries its own rule. In practice, a rule set on a space flows down to the pages inside it, so a page with no local rights object is decided by the space. An explicit page rule then changes the result for that page only. Check which documents actually hold rights objects, because a rule that looks like it applies to a whole space may be overridden by a page-level rule that someone added months earlier.
The general principle is that a deny rule takes precedence over an allow rule at the same level, so a single deny entry can block a user who is also allowed through another group. How a deny at a lower level interacts with an allow at a higher level is the edge case you must verify rather than assume. Illustrative example: an HR space allows the group Staff to view, and a page inside it denies the group Finance-Reviewers from editing. Members of Finance-Reviewers who are also in Staff should be able to view but not edit. Confirm this exact outcome with test accounts on your XWiki version before relying on it.
Group membership can change results without anyone editing a page. Adding a user to a group, removing them, or changing a group that is nested inside another group can grant or revoke access across many pages at once, and the page history will show no change. Nested groups make this harder to predict because membership may arrive indirectly. Keep a small set of test accounts in representative groups, record the expected view and edit result for each protected page, and rerun that matrix after group changes, after migrations and after every version upgrade.
Choosing a permission model for your XWiki knowledge base
This table compares five permission designs for an XWiki knowledge base, from open editing to a multi-wiki split. Read each row as the operational cost you accept in exchange for a given level of control. The main takeaway is that the right model depends on how sensitive your content is and how often access needs to change, and those answers should be settled before any rights are configured.
| Option | When it fits | Operational cost | Decide before building |
|---|---|---|---|
| Open wiki with broad edit rights | Small, trusted teams where most content is shared and exposure risk is low | Little administration, but edits and deletions are hard to attribute and review at scale; audit depends on page history | Who may edit and delete, whether guest access is allowed, and who reviews changes |
| Space-based access with groups per team | Teams own distinct areas and membership follows the organization chart | Group membership becomes the main control, so onboarding and offboarding depend on keeping groups current | Group naming, who approves membership, and whether directory groups will be mapped in |
| Restricted spaces with page-level exceptions | Most of a space is shared, but a few pages in it need narrower audiences | Exceptions accumulate over time and are easy to forget, which makes effective access harder to explain to an assessor | Which exceptions are allowed, who approves them, and how they are reviewed on a schedule |
| Deny-based rules for a few sensitive pages | A small number of pages must be hidden from broad groups that otherwise have access | Deny rules override allow rules and can block access unexpectedly, so testing with real user accounts is needed | Which pages are truly sensitive, how many deny rules are acceptable, and how denies are documented |
| Multi-wiki split for separate business units | Units have different owners, data classifications or regulatory obligations | Separate administration, search, templates and user accounts per wiki; cross-wiki sharing needs deliberate design | Whether units need shared identity, how cross-wiki links are governed, and who administers each wiki |
How to build a permission model in sequence
This sequence builds the XWiki permission model from the outside in: who owns and needs each area, then groups, then a wiki-wide baseline, then space and page rules. Each step ends with a check you can run, so mistakes surface before content is migrated or users are invited. The output is a written model that administrators can maintain.
Inventory content owners and audiences
List every space or content area, its owner, and the groups that need to read or edit it. Include guest access, external contractors and any auditors who need view-only access. Keep the list in a shared sheet that knowledge base owners can review. Done when every space has a named owner and at least one audience, and each owner confirms the list matches how their team works.
Define groups around actual roles
Create groups around roles people hold in the organization, such as editors for a team, reviewers for a function, and read-only groups for everyone else. If your identity provider already holds these groups, settle group sourcing first, as covered on the SSO page, so you do not build the same groups by hand and then have to replicate them. Done when each group has a purpose statement and a named owner who approves membership changes.
Set the wiki-wide baseline
Set the wiki-level rights before any space exceptions, so the default is the most restrictive level you accept. Decide whether guests can view content, who can create spaces, and who holds scripting or administration rights, since these affect every space. Confirm the exact right names and where they are set in your XWiki version. Done when an account with no group membership sees only what the baseline allows, checked on a sample page and a space index.
Configure rights for each space
Apply view, edit, comment and administration rights to each space using the groups from the previous step. Grant rights to groups wherever possible, and keep the number of space-level rules small so inheritance stays easy to follow. Confirm with a test account that it can view a space but cannot edit it, and that the space's pages appear in its search results only where view rights apply. Done when every space passes that check for each group that uses it.
Add page-level exceptions only where needed
Add page rules only when a page must differ from its space, such as a draft restricted to a small reviewer group or an HR page with narrow read access. Each exception is a place where the model can surprise people, so record the reason next to it. Done when a non-member account searches for a restricted page's title and the page does not appear in results, and a direct link to the page is also denied.
Create test accounts for each role
Create one test account per role in the model, plus one account with no group membership. Place each account in its group and sign in as each one to walk through the key spaces and pages. Done when every role's view and edit results match the expected outcomes, and any mismatch has been traced to a group or space rule and corrected there, not patched with a one-off exception.
Document the permission model
Write the model as a matrix with spaces and pages down one side, groups across the top, and view, edit and admin marks in each cell. Add the reason for every page exception beside it. Store the document where administrators can update it and assign an owner for changes. Done when a new administrator can read the matrix and predict the result of a test account sign-in without asking the author.
What drives XWiki permissions effort and how to keep it down
This table lists the factors that raise the design and build effort for XWiki rights, explains why each one matters and gives the practical step that reduces it. Read it as a checklist to run against your own wiki before asking for a quote, since most of the effort comes from how many exceptions and separate audiences you carry into the model. Each driver should be sized in a written scope so the quote reflects your actual structure.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Number of spaces and page-level exceptions | Each space or page that departs from its parent's rights must be designed, tested and documented. Inheritance is simple to explain, but every override creates a case someone must verify and maintain. | Set rights at the space level wherever possible and keep page-level rules to a short, named list. Review exceptions during design and reject those that only save a click for one user. |
| Number of distinct audiences and groups | Each audience needs a defined set of view, edit, comment and admin rights. The more audiences, the more combinations to map against spaces and to test before go-live. | Define a small set of role-based groups (for example, readers, contributors, space managers, wiki administrators) and reuse them across spaces. Confirm with the business owner which audiences are truly different. |
| Individual users assigned directly to rights | Rights granted to named users instead of groups multiply the work for every joiner, mover and leaver, and make it hard to see who can do what. | Grant rights to groups only. Use directory-backed or group-based onboarding where the identity provider can supply membership. Avoid direct user grants except for documented break-glass or service accounts. |
| Existing Confluence permissions to reconcile | When migrating from Confluence, its space permissions, groups and page restrictions must be mapped to XWiki's model. Differences in how restrictions and inheritance behave mean some rules will not carry over one to one. | Export and review the Confluence permission matrix before design starts. Retire stale groups and unused restrictions first, then map what remains. Pilot a few spaces to confirm how migrated permissions behave in XWiki. Confirm the exact transfer scope with the migration tool documentation. |
| Regulatory or contractual confidentiality requirements | Requirements to restrict access to personal, client or regulated information add review, evidence and testing steps. Each restricted space needs a documented justification and a tested result. | Identify the confidential classes of content early and place them in dedicated spaces so restrictions apply at space level. Agree with compliance which controls need evidence and keep the rule count for those spaces low. |
| Number of wikis | Each wiki is a separate permission tree with its own groups, administrators and global settings. Running several wikis multiplies design, testing and ongoing review. | Use one wiki with well-structured spaces unless there is a real separation requirement, such as a different administrative authority or legal boundary. Document the reason for each additional wiki. |
| Integration with an external directory | Mapping directory groups to XWiki groups requires agreed naming, sync behaviour and testing of joiners, movers and leavers. Misaligned group names are a common source of rework. | Agree the group naming convention and the source of truth before build. Map a limited set of directory groups to XWiki groups rather than mirroring the whole directory. Confirm supported directory and SSO options with the XWiki documentation and the extension you plan to use. |
| Audit trail of rights changes | If you must show who changed a right, when and why, the team needs a change process, recorded approvals and a way to export or review history. This adds process design and testing work. | Route rights changes through a single request process with an owner and approval. Keep a rights register for each space. Confirm with your auditor which evidence they expect before deciding how much logging to build. |
How permission design changes by wiki layout
A single wiki with one space per department keeps the rights model simple, because most decisions are made once at the space level and inherited by the pages underneath. Each department usually maps to a group, and that group receives edit or view rights on its own space. Reading across departments then becomes an explicit grant, so the default settings deserve the closest review.
- Space-level grants carry the design. Assign rights to groups on each departmental space and keep page-level exceptions rare, since every exception is one more setting an administrator must remember.
- Inheritance causes most surprises. A page that inherits from its parent space changes when someone edits the space above it, so record which spaces hold the explicit grants.
- Shared reference spaces need an owner. Cross-department material often ends up editable by everyone, which lets teams that do not own the content change it.
- Administration is easy to over-assign. Team leads given space administration can usually change rights on that space, so decide in advance who may alter permissions.
Confirm in your chosen XWiki version how the rights screens display inherited settings, whether group membership is managed inside XWiki or synchronized from a directory, and how deny rules interact with allow rules on a parent space. Test each department group with a sample account before go-live.
A single wiki serving a large mixed audience, such as all staff plus contractors and partners, usually starts from broad read access and restricts a small number of areas. The design effort goes into those restricted areas: they need clear owners, explicit denies where required and a plan for who may see them. Because most content is open, mistakes tend to expose information rather than block work, which makes testing the restrictions the priority.
- Start from the default read model. Decide which groups can read the general spaces, and whether guest access is allowed at all, before touching any restricted area.
- Keep restricted areas few and named. Each restricted space adds grants and denies to maintain, so a short list with a named owner is easier to audit than many small exceptions.
- Deny rules override expectations. A deny set on a group can block an administrator or an owner who expected access through another group, so test each combination of groups.
- Child pages and attachments need checks. Restrictions on a space do not always make the reviewer's path to every child page obvious, so verify pages and attachments individually.
Confirm in your chosen version whether page titles and search results reveal restricted content to users without access, and whether guest access can be limited to specific spaces. Record the final allow and deny settings in the configuration handover so they survive redeployment.
When business units or subsidiaries need isolation, separate wikis move the main boundary to the wiki level. Each wiki can have its own administrators, spaces and access policy, which fits organizations where one unit must not see another unit's content under any circumstances. The trade-off is that users, groups and extensions must be managed for each wiki, and shared knowledge needs deliberate links or copies.
- Decide where users live. Confirm whether accounts and groups are shared across wikis or local to each one, since this determines how often administrators must repeat changes.
- Delegate wiki administration carefully. Each wiki administrator controls that wiki's rights, so the delegation list should match the isolation promise made to each unit.
- Expect duplicated maintenance. Group changes, offboarding and extension choices may need to happen once per wiki, so assign that work to a named role.
- Cross-wiki access is a separate design. Links, search and shared templates do not automatically respect a rights model that spans wikis, so write down which content is intentionally shared.
Confirm in your chosen version whether several wikis can run in one installation and how that affects extension management and upgrades, and how wiki-level administration is delegated. Keep the isolation model and group ownership in the configuration handover so the separation survives redeployment.
Permission mistakes that expose knowledge
Most XWiki data exposure comes from rights that were granted for a reason that has since passed, not from missing controls. The cards below cover the design choices and hidden paths that widen access over time, and the checks that find them before a reviewer or a former employee does.
Broad view rights from wiki defaults
A view right set at the wiki or root space level flows down to every space and page that does not override it. Teams often grant view to a broad group during setup to make testing easy, then never narrow it. Check the rights on the root space and the wiki-level settings, then open a sample of sensitive spaces and confirm that each one actually inherits what you expect.
Administrative rights for content editors
Editors often receive admin or programming rights because a macro, template or layout change requires them. Those rights also allow editing rights, deleting pages and changing other users' permissions on the affected space. Review which accounts hold admin rights at each level, and separate content editing from rights management where your edit workflow allows it.
Groups with unclear membership
A group named for a project or department can outlive its purpose, and its members may have been added by someone who has since left. Nested groups make the effective membership harder to read, because a user may gain access through a group that was added for a different reason. Export the membership of every group referenced in a rights rule, and confirm an owner for each one.
Page-level exceptions nobody remembers
A single page may carry an allow or deny rule that overrides the rules on its space, and the reason for it is rarely recorded. Over time these exceptions make it unclear why a user can or cannot see content. Search the wiki for pages with their own rights settings, compare them with the space defaults, and document the reason for each exception or remove it.
Restricted content visible through side paths
Locking a page body does not automatically hide its title, excerpt in search results, earlier versions in history, attachment names or comments. A user who cannot open a restricted page may still learn its name or content from these places. Test with a low-privilege account by searching for distinctive terms, opening the history and listing attachments, and confirm that each path respects the same restriction.
How to test that XWiki permissions hold and fail safely
A rights design is only trustworthy once a test has shown that each role gets the access it should and nothing more. Before go-live, create one test account for each role and each group in the design, plus one account that belongs to no group and a guest session with no login. Use these accounts for all checks, and do not test with administrator accounts, since they bypass most of the restrictions being verified. Keep the list of accounts and their group memberships in the test record so that a later reviewer can reproduce the setup exactly.
Next, build a matrix of expected results. Choose representative pages in each space: the space home page, an ordinary content page, a page with restricted rights, and a child page that inherits from its parent. For every test account and every page, write down the expected result for view, edit, comment and admin before running anything. Then log in as each account in a clean browser session or private window and record what actually happens. Confirm the exact right names and their behaviour in your XWiki version, since the administration screens and labels can differ between releases.
A restricted page needs checks beyond the page body. Ask whether an unauthorized account can see earlier revisions in the page history, whether attachments are reachable by direct address even when the page itself is hidden, and whether the page title or an excerpt appears in search results for that account. Repeat the same checks on a child page and on any page that embeds content from a restricted page. Look for leaks in every place that shows content, not only the main view.
Fail safely means that an unexpected result defaults to denial and is visible to an administrator. If a test account can do something the matrix does not allow, treat the result as a failed control, not as an acceptable difference, and remove the access until the cause is understood. Repeat the full matrix after any change to groups, space rights or inheritance, because a single change can alter access on many pages. Store the completed matrix, its date and the XWiki version as evidence, and run it again after every upgrade or migration, since rights behaviour can change between versions.
How to keep permissions correct after go-live
This sequence keeps XWiki rights aligned with your access policy after go-live by assigning an owner, reviewing groups and exceptions, testing after every change and recording each decision. Each step closes with a record that shows the routine ran. Your own policy sets the review cadence, and your organization prepares compliance evidence with its auditors.
Assign an owner for the routine
Name one person, with a named deputy, who owns the permissions routine and holds the review calendar. This is usually the wiki administrator or a platform lead in your identity or security team, and the owner signs off every review in this sequence. Your organization's access control policy should set how often each review runs, and that cadence should be written down before go-live. Done means the owner, the deputy and the review schedule appear in your runbook and the recurring review tasks exist in your team's tracker.
Review group membership on a fixed schedule
Compare the members of each XWiki group used in space or page rights against your identity provider, which should remain the source of truth for who has access. The owner or a delegate removes leavers, moves people who changed teams and confirms that each group still maps to a job function, so named individuals appear only where that is justified. If directory groups map to XWiki groups through SSO or LDAP integration, check that mapping in the same review, because a directory change can alter access without any change in XWiki. Done means a signed review record lists the groups checked, the changes made and the reviewer. Confirm with your identity team how membership syncs in your setup.
Review page-level exceptions after reorganizations
After any move, merge or split of spaces, list the pages that carry their own rights, since these override inherited rights from their parent space. Check whether each explicit grant or deny still has a valid reason and an assigned owner, and whether moved pages kept the rights you intended. Pay particular attention to deny rules, because a reorganization can make a restriction apply to content it was never meant to cover. Done means the list of explicit exceptions matches the approved list, and the review record names the owner and justification for every exception that remains. Confirm with your XWiki version how moves and copies handle rights on the moved content.
Re-run the permissions test matrix after changes
After each XWiki upgrade, extension installation or extension update, and after any group or rights change that affects shared spaces, run the permissions test matrix. The matrix tests representative accounts for each role, such as guest, standard user and space administrator, against the rights that matter most to your wiki, including view, edit, comment and delete, and any scripting rights you allow. Compare each result with the expected outcome stored alongside the matrix. Done means each run is recorded with the date, the XWiki version, the tester and the pass or fail result. Any failure is logged as a defect and resolved before the change is accepted.
Record each rights decision in a change log
Record every grant, deny, exception, group creation and group removal in a change log with the requester, the approver, the reason, the date and the spaces or pages affected. Where your policy requires separation of duties, the approver should be a different person from the requester. The change log is the record that the reviews in the earlier steps check against, so entries should be written at the time of the change rather than reconstructed later. Done means the owner reconciles the log against the live rights during the next scheduled review, and every difference is either explained by a logged entry or opened as an investigation.
Back up the configuration that recreates the model
Include the database and XWiki data in your general backup plan, and separately export the artifacts needed to rebuild the permissions model: group definitions, the rights objects in administrative spaces, the directory mapping configuration, the test matrix and the change log. Store these in a controlled location with access limited to the people who administer the wiki. Confirm with your XWiki version which export method covers each object type. Done means a restore test into a non-production instance rebuilds the groups and rights, and the permissions test matrix passes on the restored instance.
Questions teams ask before designing XWiki permissions
How much does an XWiki permission design project cost?
The cost depends on the scope agreed in writing, not on a standard package, and DeployOpen does not publish a price list. The main drivers are the number of spaces and page trees that need their own rules, how many groups and directory sources must be mapped, whether existing Confluence permissions must be reviewed, and how many rounds of testing with real users are needed. If you want a reference point for consulting time, XWiki SAS lists consulting at 1200 EUR per day on its pricing page, but that rate requires a Business or Enterprise support plan. Ask any partner for a fixed-scope quote that lists deliverables, client responsibilities and the number of review cycles.
How long does it take to design XWiki rights and what do we need to provide?
Duration follows from scope, and no fixed timeline applies to every wiki. The work usually moves faster when you have a named decision-maker who approves the access policy, such as which groups can read, edit, administer or script, and when content owners can confirm which spaces are sensitive. You should also provide test accounts for each role, a current list of users and groups, and access to a non-production instance for validating rules. Ask the partner to state in writing how many review sessions are included and what happens if decisions are delayed.
Can our internal team design XWiki permissions without a partner?
Yes, a capable internal team can design XWiki permissions, especially for a small wiki with few spaces and simple roles. The harder parts are working out inheritance across wiki, space and page levels, deciding where deny rules are justified, and testing the result against each role without accidentally exposing content. Teams with a complex structure, many imported spaces or strict audit needs often choose outside help for the design review. Consider the staff time for design, testing and documentation, and the knowledge that must stay with the team after the work ends.
How do XWiki permissions carry over when we migrate from Confluence?
Confluence Migrator Pro from XWiki SAS migrates spaces, pages, users, groups and permissions, so existing access rules can come across with the content. However, a migrated permission set reflects the old model and is not automatically the right model for XWiki. Review each space after import, check that groups map to the directory you actually use, and remove access that was never intended. The migration tool is priced from 2000 EUR according to the XWiki Store, and its trial is limited to 30 pages per migration, so confirm licensing and trial limits before planning a pilot.
Can XWiki rights be managed from an identity provider?
Authentication can be delegated to an identity provider, and group membership can often be synchronized so that XWiki rights follow directory groups. The xwiki-contrib OpenID Connect extension can authenticate users against an external OpenID Connect provider, and XWiki Pro lists Active Directory and Azure Active Directory SSO applications. Confirm which mechanism your identity provider supports for group claims or directory sync, and test how removals and deactivations propagate. Ask the partner to show, in a test environment, that a user removed from a directory group loses access in XWiki.
What should we receive at the end of an XWiki permission design engagement?
A complete handover should include the access policy in plain language, a rights matrix listing groups, roles and the spaces they apply to, the configuration or change records used to apply the rules, and the test cases with their results. You should also receive a short guide for administrators on how to add spaces, create groups and review access, plus a list of open decisions. Confirm in the written scope who keeps the configuration files and documentation, and whether the partner will review rights again after your next upgrade.
Do we need XWiki Pro to design and apply permissions?
No, the permission model is part of XWiki itself, and XWiki Standard is free and open source under the LGPL 2.1. XWiki Pro adds business applications, connectors and SAS support, including Active Directory and Azure Active Directory SSO applications. Whether you need Pro depends on your identity integration and support needs, not on the rights model alone. Compare the subscription tiers, which are Starter, Basic, Business and Enterprise according to the XWiki pricing page, against your user count and your need for vendor support before deciding.
How DeployOpen scopes, builds and hands over XWiki permission work
DeployOpen designs XWiki rights and permissions as a written, fixed-scope piece of work inside the client's own infrastructure. The work covers the rights model across wiki, space and page levels, group mapping, allow and deny rules, and the handover documentation a wiki team needs to run permissions after go-live.
How we scope
- We inventory the spaces, page trees, groups and users that need access rules in your XWiki instance.
- We agree the permission model in writing, including which rights are set at wiki, space or page level.
- We confirm the XWiki line, database and servlet container that the permission design will run on.
How we build
- We configure groups, default rights and space-level rules, then test allow and deny combinations against sample users.
- We review where guest access and scripting rights are granted, and restrict them to documented roles.
- We validate inheritance behavior on a pilot space before applying the model across the full wiki.
How we hand over
- We document the permission model, group ownership and the rules for requesting or changing access.
- We provide a verification checklist your wiki administrators can run after each space or group change.
- We walk your administrators through the rights model and record open decisions for your governance owner.
How we support
- Ongoing support for permission changes, upgrades and review of new spaces is available as a retainer.
- Engagements are fixed-scope, so any additional permission work is agreed in writing before it starts.
- Confirm with DeployOpen which support scope, response expectations and review cadence the retainer includes.
