How to set a relationship field editable at the backward-direction, but not editable at the forward direction?

[JensN.]

Hi @all,

we have an item-type which is representing a hierarchical structure of release artifacts (function-packages). If we are developing new functions, then these functions can be splitted into packages, and the packages can also hold other packages (and so on) until we come to the smallest development artifact (a module).

In integrity we have built an item-type "package" which is holding both sides of a relationship field. The forward direction of this relationship field is named "subordinated packages" and the backward direction is named "superordinated packages". So in each package the users can see, which other packages are holding the package which the user is viewing and which other packages this package contains.

There are also some triggers which are reacting if the hierarchy is changing. So as example the item type is containing date-fields (for planned release dates), which will be inherited in each subordinated item by such triggers.

Now to my problem: if i have an existing hierarchy of 3 packages: package A at the top, package B in the middle and package C at the bottom, and i want to put a fourth package D as a subordinated package into package B i can do this by editing the relationship field in two ways.

The "downstream-way": i am editing the forward-part of the rel-field in package B and add package D into this field.

The "upstream-way": i am editing the backward-part of the rel-field in package D and add package B to this field.

Both actions are triggering the above mentioned inheritance, but only the downstream-way is working. If we are trying to use the upstream-way, the trigger is starting in the superordinated package B and if it comes to its own subordinated packages, it will try to modify the date-field in the subordinated package D, which is already modified. So we are running into an cyclical trigger error (see the attached screenshot)

Now we had the idea to permit the users to modify these relationships by the upstream-way by setting the backward-part to "not editable". But this doesn't work as we cannot build relationships at all if we do so.

Is there any way to work around this cyclical trigger? Or to set the backward-part of this relationship field to "not editable" for direct, but not for indirect modifying?

Thanks, Jens

added a scheme of the mentioned hierarchy...

[mrump]

Hi Jens,

some ideas:

1 instead of completely disabling the relationship edit, limit it to "system user" (if anyhow possible)

2 use IBPL ("superordinated package") and QBR (""subordinated packages") fields.

his will allow only the "upstream-way" as in package D you must/can define package B. But Package B the QBR will automatically find/reference Package C and D.

But:

+ QBR fields are read-only by definition, so no editing conflict.

- you'll be limited to a "single-value" relationship for the "superordinated package" (a typical tree design)

3. maybe you could change your "copy dates trigger" from rule / event base to a schedule one. That should eliminate the circle detection, as you have no event.

- e.g. define a query for packages that changed in the last hour

- run a trigger hourly that uses this query, to find and analyse/modify the items base on the "downstream relation".

HTH Matthias

[JensN.]

Hi Matthias,

thanks for your answer. Unfortunately nothing of your ideas will work in our environment 😕

1. I didn't find such a systemuser in our environment and i don't have an idea how to create or implement some kind of such a systemuser.

2. Unfortunately a single-value field for the "upstream-way" isn't an option.

3. I somehow like the idea of scheduling the "copy dates trigger", because it would help us also in some other cases, where we encounter some kind of "race conditions" with some triggers. But this wouldn't be accepted by the users, because they have already a problem with seeing changes or results only after clicking "apply" instead of seeing them instantly. If they have to accept to wait for results of their actions for a certain time they won't accept the tool at all.

kind regards, Jens

[mrump]

Hi Jens,

there is of course always option

4. create a custom GUI (POJO or Web-based) that analyses / visualizes your relationship tree, locally stores changes and finally publishes them to Integrity. (comparable to the "Edit in Work" workflow).

This is expensive but might be worth it

HTH Matthias

[JensN.]

Hi Matthias,

this option is used here more often in the last time. And more: our company is working on a system (kind of a middleware), where Integrity will be used more or less as a data sink. Integrity will still hold the basic workflows and the basic permission management, but the intelligence will be outsourced into external functions. Some years ago, as i heard of this attempt i thought this would be the wrong way, but every time i encounter the pain to put some functionality into Integrity and the slowlyness und inflexibility of PTC to help us, it changed my mind a bit. Sure, we have a very complex process image which we want to see in Integrity, but it seems more and more that Integrity isn't the tool we should use for this.

For this special use case i realized another "solution" (and solution is really not the right word for this, because its "von hinten durch die Brust ins Auge" (which means the most complicated way to get a solution)): I was creating a new relationship field, this field i generally not editable by users and will only filled by a trigger. The upstream-way works simply by copying the original relationship field. The downstream-way is working by copying only selected related items in the superordinated package into the backwards relationship field. It's a mess, its complicated, i'm sure that i will not understand it again if i have to look at it one year later, but now the users doesnt see an editable relationship field and this helps us... 

kind regards, Jens

[KaelLizak]

Hi Jens,

A "System user" would just be a user id which doesn't correspond to a particular individual.  You could create one in whatever backing realm you had for purposes such as this.

You could also use a trigger script to see which side of the relationship you're editing from, and veto it if it's from the wrong side.

-Kael

[JensN.]

Hi Kael,

i know about this kind of a system-user, but this wouldn't help me in this case, because i cannot move the "ownership" of editing a relationship field between both sides of the relationship field. If a standard-user is editing the "downstream-field" in an item, the "upstream-part" of the same field in the subordinated item will be "edited" by the same user.

kind regards, Jens 

[KaelLizak]

Hi Jens-Uwe,

I haven't tested this, but what I was thinking was that you allow the edit at the permissions level, but have a trigger guard the edit from the "wrong" side.  The sysadmin in me shudders at this as a solution, but the hacker in me sees that as the best way to solve the problem.

Another way to do it would be to have an integer field, in which you could type in the IDs of the items to be related, and then have a trigger actually populate them, possibly using impersonation.  I think this is actually a worse solution for usability reasons.

-Kael

[mrump]

Kael Lizak wrote:

.. Another way to do it would be to have an integer field, in which you could type in the IDs of the items to be related, and then have a trigger actually populate them, possibly using impersonation.  I think this is actually a worse solution for usability reasons.

To continue that idea...

Why not using 2 different relationship fields.

- Field 1 is editable for the Users

- Field 2 is only editable for a System account

A pre-event Trigger catches every change in Field 1 and "copies" that change to Field 2 using the system credentials. The Change in Field 1 is deleted (like it never happend).

This keeps the usability for the end users, but separates the permissions.

The only disadvantage I see is the possible irritation of the end user regarding the name of the field that was changed (and the account performing the change).

‌

[JensN.]

Hi,

i tried a similar way: I changed the relevance-setting of the original relationship-field, so that it is invisible for the standard user. I created a second relationship-field, which isn't editable for the user, and a trigger, which synchronizes both fields. So the user can always see the "write-protected" field and cannot see the original field. But we didn't release this solution yet, because it will have some impact at the performance and (more critical) we had two time the problem, that the server, where we did the tests with this solution, is running into a infinite trigger-loop, and we couldn't see if it was caused by our trigger. We had to restart the whole server, which seems not to be very practicable in a productive environment     

kind regards, Jens

[kjain-2]

Hi Jens-Uwe,

If you have to create relationship field either backward or forward non editable then you can set editability rule on one of them and just check on Never editable in Editability rule tab. Hope this helps or let me know about this.

Regards

Kapil Jain

[JensN.]

Hi Kapil,

thanks for your idea, but this doesn't work. If an user tries to edit the relationship (at the side where it is allowed), after clicking apply he will get the error message:

"MKS124128: You are attempting to add the item 12345 as a relationship to this item. The target item 12345 does not permit editing the reverse relationship field <name of the relationship field>, which points back at the item you are trying to update."

kind regards, Jens