ACLPropagation -- unclear how precedence works for "propagate" value

XMLWordPrintable

    • Type: Bug
    • Resolution: Won't Fix
    • Priority: Minor
    • None
    • Affects Version/s: None
    • Component/s: Domain Model
    • None
    • Hide

      I think that the definition here should (preferably) be loosened to say that "the ACE SHOULD be applied to the object and all "inheriting" objects..."

      As currently written we're mandating that propagate takes precedence over "object-only", which will preclude some implementations from supporting the "propagate" ACLPropagation.

      Show
      I think that the definition here should (preferably) be loosened to say that "the ACE SHOULD be applied to the object and all "inheriting" objects..." As currently written we're mandating that propagate takes precedence over "object-only", which will preclude some implementations from supporting the "propagate" ACLPropagation.

      Currently, the definition for the "propagate" value for "ACLPropagation" (section 2.8.5, line 621) says: "indicates that the ACEs is to be applied to the given object and all “inheriting” objects – i.e. with the intended side effect that all objects which somehow share the provided security constraints should be changed accordingly."

      I think this definition is either unclear or two restrictive. Consider the following case: What if a folder "Foo" contains 5 items, and one of the items "bar" current has ACLs set on it that were set with the "objectonly" propagation type. (I.e. per-item permissions).

      Clearly, setting new ACLs on "Foo" with ACLPropagation=propagate should affect the other 4 items in "Foo", but what about "Bar"?

            Assignee:
            Ethan Gur-esh (Inactive)
            Reporter:
            Ethan Gur-esh (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: