4 Replies Latest reply on Jun 5, 2018 2:06 AM by BKallweit

    Object Permissions


      I need to implement this scenario:


      - certain incidents must only be visible for users with a particular role

      - tasks contained in such incidents should be accessible for users with any role


      I.e., the contents of the incident itself must stay private; the incident owner can create tasks within this incident and assign them to anyone.


      I tried to implement this using object permissions. There is a incident field called Realm that controls access; for the 'private' role I defined object permissions on Incident as 'Realm is equal to <something>', while all 'public' roles have object permissions 'Realm is not equal to <something>' to prevent them from viewing (or modifying) this incident. This works very well, as expected.


      However, if a user with a 'public' role tries to save a task contained in a 'private' incident, an exception is raised: You do not have rights to update Incident (3CB585C3FCEB4FC9B818601FE983ECAF).

      Running Rule Trace I can see a >Trigger 'Update My Item' object event 'On Update' Incident --> RunForChild: 'Update My Item'< which is defined to run on any update to incident.


      My question is: why does an update to a task also performs an update to the related incident? Is there a way to prevent this?



      I'm experiencing this on ISM 2017.2.1.



      Thanks for your thoughts!

        • 1. Re: Object Permissions
          Jonathan.Schmidt SupportEmployee

          Hi BKallweit,


          Relationships will carry over a Last Modified date/time to the parent when child records are manipulated.  This is simply the design of the product.  I'm not sure how you could make all tasks visible but hide their parent Incidents entirely via the Object permissions dialog.  You might need to use form level visibility controls per field and multiple layouts, one for each of these specialized roles in order to have the parent Incidents exposed but the data you need private to stay hidden on those cases.


          Another option is to adjust your working processes such that these roles that work in Task only ever see Task and simply not expose the Incident workspace to them at all.


          Another route would be to log a feature request to make the update of related object's date/time fields optional, but I know OOTB configuration leverages that exact ability in several places so I'm not certain Product Management would go for it.


          I hope this helps!


          • 2. Re: Object Permissions

            Hi Jon,


            thanks for your explanations!


            For the time being I will consider modifying layouts (forms) to hide sensitive fields (probably pretty much all of them) from the incident form and make child tabs unusable as well; this will take some effort and bears the risk of new fields being overlooked.

            Do you see chances that a feature request could be successful asking for a change in those internal rule, which updates LastModDate?

            I would not suggest to make this update rule optional (because it is a useful feature), but to have this rule bypass (potential) access restrictions. ISM should always be able to write this field (plus perhaps LastModBy, or all 6 mandatory business object fields), regardless of access restrictions.

            This should have no impact on existing installations, but would allow for the scenario I need to implement.




            • 3. Re: Object Permissions
              Jonathan.Schmidt SupportEmployee

              Hi Bernd,


              I'm sure there's a chance it'll be accepted and a chance it'll be declined by PM, but if you never log the request, you forego any opportunity for PM to say "YES!"


              I was thinking there may be another possibility.  The BeforeSave rule for LastModBy and LastModDateTime might be able to be modified in such a way that they would be skipped upon any update coming from a user who is not "allowed" to see the record in question.  I don't know for sure if it'd work, but it's another avenue you might explore.



              • 4. Re: Object Permissions

                Hi Jon,


                I will try another feature request for this matter.


                I ran Rule Trace and saw that the the only rule triggered on Incident was Update My Item, which runs whenever any field is modified in Incident. I couldn't see any indication of a rule changing any field in Incident. I would think, that the Last Modified update was done by some internal rules, which are not directly visible or configurable from the administrator.