Class FolderGrantRequestAction

java.lang.Object
io.jenkins.plugins.batchcontrol.action.FolderGrantRequestAction
All Implemented Interfaces:
Action, ModelObject

@Restricted(org.kohsuke.accmod.restrictions.NoExternalUse.class) public class FolderGrantRequestAction extends Object implements Action
R4-14 (D-66): the folder counterpart of JobGrantRequestAction, a "Request Change Permission" entry on a folder that opens the grant request form prefilled for the folder (scopeFullName=<folder>). D-71: the window names this folder only and confers no permission on the items inside it (its settings still affect them, D-71a); Create starts checked for a regular folder, Configure for a computed one.

spec-review-S6 m-5: the entry has exactly one URL form, the same as the job entry's: batch-control/grants/new?scopeFullName=<rawEncode(full name)> (relative to the folder's URL) and, for the dialog, the same single parameter on batch-control/grants/dialog. There is no actions parameter: the form preselects the action from the item it resolves (GrantsSection#isPrefillAction).

No URL space, no view of its own and no state: the entry links to the Grants screen's form (/batch-control/grants/new, or its dialog), whose own gate and @RequirePOST create endpoint make every check that matters.

Who sees it

Change control is on, the caller holds BatchControl/RequestGrant, and the caller does not already hold every permission a window can carry here: Item/Configure on the folder, and Item/Create on it when it is a regular folder (D-71: a window's Create applies only to a regular folder, and its Delete never to a folder) — so administrators, and a holder of open windows for all of them, see no entry. The folder page already requires Item/Read.
  • Constructor Details

    • FolderGrantRequestAction

      public FolderGrantRequestAction(com.cloudbees.hudson.plugins.folder.AbstractFolder<?> folder)
  • Method Details