Repository navigation
Conversation
The "Applied allow/deny permissions" and "Checked permissions" lines were visually indistinguishable when the same authorizable received multiple calls at the same (or overlapping) paths - the glob restriction, including the STRICT one meant to lock a single node, was not visible, so operators had to cross-check the script source to tell apart a wide-tree grant from a single-node protect. The "Cleared permissions" lines carried the same blind spot for the clear(..., strict) flag that chooses between selective and full removal. Every ACL permissions log line now carries a trailing modifier when it applies: Applied allow permissions for authorizable 'X' at path '/foo' with glob 'STRICT' Skipped setting deny permissions for authorizable 'X' at path '/foo' with glob 'STRICT' (already set) Checked allow permissions for authorizable 'X' at path '/foo' with glob 'STRICT' [true] Cleared permissions for authorizable 'X' at path '/foo' in strict mode Skipped clearing permissions for authorizable 'X' at path '/foo' in strict mode (path not found) Suffixes always sit between the main sentence and any trailing "(reason)" parenthetical, so parsers that match the pre-existing format (no glob, no strict) continue to work unchanged. Covered log sites: - AclAuthorizable.apply - four lines (Applied, Skipped composite node store, Skipped path not found, Skipped already set) - Acl.apply - "authorizable not found" variant - AclAuthorizable.clear - four lines (Cleared, Skipped composite node store, Skipped path not found, Skipped no permissions to clear) - Acl.clear - "authorizable not found" variant - AclChecker.check - the single "Checked permissions" line; its template is reshaped from "...with allow 'true' [...]" to "Checked allow permissions..." so that the glob suffix does not stack a second "with" on top of the allow one, matching how the write-path Applied line is written The glob suffix is produced by a new determineGlobSuffix method on both authorizable.PermissionsOptions and check.PermissionsOptions - the two options classes stay symmetric, the STRICT display string is reconstructed from the internally empty GLOB_STRICT_EFFECTIVE marker in one place, and the three call sites just concatenate the already-formed suffix instead of re-wrapping the raw value. The strict suffix is a local " in strict mode" phrase in AclAuthorizable.clear and Acl.clear driven by ClearOptions.isStrict() / the clear(path, strict) boolean. The regenerated api.md / api.json script catalog therefore lists determineGlobSuffix next to the existing determineAll* methods on both options classes. Closes wttech#307
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Applied/Skipped setting/Checked/Cleared/Skipped clearing) now carries a trailing modifier when applicable:" with glob 'STRICT'"/" with glob '<pattern>'"for apply/check sites," in strict mode"for clear sites. Suffix sits between the main sentence and any trailing(reason)parenthetical, so parsers matching the pre-existing no-glob/no-strict case still work.AclChecker.checklog reshaped from...with allow 'true' [result]toChecked allow permissions ... with glob 'X' [result]so the glob suffix does not stack a secondwithon top of the allow modifier, matching the write-pathApplied allow permissions ...format.determineGlobSuffix()method on bothauthorizable.PermissionsOptionsandcheck.PermissionsOptionsreconstructs the"STRICT"display name from the internally emptyGLOB_STRICT_EFFECTIVEmarker; API script catalog regenerated.Example log output
Before:
After:
Test plan
mvn -pl core compile spotless:checkpasses locallyAclAuthorizable,Acl,AclCheckerto confirm the glob/strict suffix lands between path and reasonCloses #307