Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-16293

Enhance signal propagation to be triggered by specific signal origins



    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 7.0.0, 7.1.0, 7.0.1
    • None
    • Module - Relationships
    • None


      Managed orgs have the following notifyRelationships config element for their parent relationship field:

      "notifyRelationships" : ["children", "members"]

      Thus when the parent relationship field is signaled, this signal is propagated on to both children and members. This signal propagation is necessary when a new org is added as a parent in an existing org hierarchy: in this case, the parentIDs RDVP for all orgs must be updated to include this newly-added org, and all members of all orgs rooted by the newly-added org must be signaled so that their memberOfOrgIDs is updated to include this newly-added org. This is necessary so that all members of the org hierarchy rooted by this newly-added org can be administered/owned by the admins/owners of the newly-added org.

      Likewise, when an org's admins or members relationship field is mutated, or a user's adminOfOrg or ownerOfOrg is mutated, a signal will be propagated down the org hierarchy so that each org can update their owner/adminIDs and parentAdmin/OwnerIDs RDVPs. The notifyRelationships clause above serves this purpose. This occurs because orgs can be manipulated by only those admins/owners whose IDs they encapsulate in either their admin/OwnerIDs or parentAdmin/OwnerIDs RDVPs. Thus this signal propagation, and the corresponding RDVP calculation, will allow the newly-added org admin/owner to manipulate all orgs rooted by the org which they directly administer/own.

      However, this signal need not be propagated to all org members - it only need be propagated down the org hierarchy. Thus the addition of a org admin/owner will incur the same overhead as the addition of a new root in a given org hierarchy: the signal will be propagated down the org hierarchy, and to all members. This will be, by far, the most high-latency operation in the org model. 

      The notifyRelationships element of the signal propagation config could be easily modified to address this issue. The crucial element is that the VertexTraversalContext already has the resource path and relationship field of every signal origin/target. Thus every signal has a list of the edges/vertices which the signal traversed thus far. This was done to prevent signal cycles. The notifyRelationships config surface could be changed thusly:

      "notifyRelationships" : ["children" : {"signalOriginResourceCollections" : ["managed/user", "managed/organization"]}, "members" : {"signalOriginResourceCollections" : ["managed/organization"]]

      This config surface enhancement would specify that, when the parent is signaled, signal the children when the resource collection originating the signal is either managed/user or managed/organization. This would serve to propagate all signals to all children, whether they originate because an admin/owner has been added to an org, or an existing org hierarchy has been manipulated. However, the fact that the members relationship field is specified with a "signalOriginResourceCollections" of only "managed/organization" means that members will be signaled when the parent is signaled ONLY if the signal initially originated from a managed/organization. This would exclude the notification of all members when an org admin/owner is added to an existing org hierarchy, and propagate signals to members only when the org hierarchy was manipulated.




            dhogan Dirk Hogan
            dhogan Dirk Hogan
            0 Vote for this issue
            2 Start watching this issue