Here is a draft of a proposal for the creation of a new usergroup.
I'd really like feedback on this proposal, especially from the gods, who,
obviously, would have the greatest stake in the change. Thanks in advance.
Make a special group, the members of which have the power to apply patches. No other divine powers are conferred. The intent, as currently envisioned, is that certain meritorious pmdevils will then be given patch application power. Membership in this group expires at the end of a certain period, to be determined by the gods on a case-by-case basis. It will allow the specially deputized pmdevil expeditiously to create and apply patches as necessary for some focused project — overhauling our xml generation capability, for example.
The steps necessary to create the group are:
- Create a new usergroup, "patchappliers". (Only gods can create a group.)
- Create an accessrule, "CanApplyPatch", defined as (in_gods||in_patchappliers).
This could be done by appropriating (patching) an existing unused accessrule;
or (possibly) via a request for new code node. Otherwise, the gods can simply create the new node.
- Patch certain nodes (applypatch, patch edit page, and patch display page)
to use this accessrule rather than isGod().
There is one complication: applypatch calls updateNode to do the work, and
updateNode checks for authorization based on the type of the target
- Add patchappliers to the updaters_user for all the patchable nodetypes.
One potential problem stems from the fact that canUpdate/isApproved only check for
user identity to one user/group (not including gods; they can always update any node*).
If we find any patchable nodetype already having a value in its updaters_user field,
we'll have a problem.
- In applypatch, call updateNode() with a user value of -1, rather than $USER.
This would work because isGod(-1) returns true.
And since -1 is not a real user, there's no chance of the patch applier
spoofing another user. (This would only affect the paper trail.)
These functions (updateNode, canUpdateNode, isApproved, isGod) all live in Everything/NodeBase.pm.
* The Everything code does provide a way to close this back door: a 'notgod' parameter. But this feature is not currently used in the PerlMonks codebase.
Much credit and thanks go to Petruchio, who had the original idea
upon which this proposal is based, and who helped me elaborate it.
A word spoken in Mind will reach its own level, in the objective world, by its own weig