Change a WorldGuard parent without losing track of inherited membership
Changing a region’s parent can alter inherited members and policy even when its own member list stays the same. Review those effects before reorganizing a group of plots.
Follow the procedure
- Inspect the child, current parent and proposed parent in the correct world. Record explicit owners, members, flags and priority for each relevant region.
- Read the installed priority-and-inheritance documentation. Distinguish inherited values from entries stored directly on the child; a short member list may not describe effective access.
- Write a small access matrix for an existing child member, a parent-only member and an ordinary nonmember. State which accounts should retain access after the change.
- Rehearse the parent change on staging or a disposable region with comparable policy. Use the documented set-parent command and check that no inheritance cycle is introduced.
- Test the selected build and interaction actions using the three ordinary accounts. Include a flag inherited from the parent so the test covers policy as well as membership.
- Apply the reviewed relationship to production and reinspect the child. Record the previous parent and the observed access results for a precise rollback if required.
Check the result
The child should inherit only the intended parent policy and grant access to the expected accounts. Explicit entries should remain as recorded unless separately changed. A parent label changing successfully does not prove the resulting membership and flags are appropriate.
If the result is wrong
If unexpected users gain or lose access, restore the saved previous parent and retest. Do not compensate with broad owner grants or random priority increases. Review the inheritance chain and explicit child overrides before attempting the organizational change again.