Permissions/Constraints for multiple-object cable terminations

[georg-again]

Hi,

I have a special permission that allows users to edit/create/delete cables if they are the "Owner" of both devices.
Up to v3.3.0 I used a permission-contraint that used 'termination_a' and 'termination_b' to check that both ends
have an interface with the correct device connected.

I just found out that 3.3.0 introduced a new data format for cable terminations and my solution does not work anymore.
The changelog (https://github.com/netbox-community/netbox/releases/tag/v3.3.0) claims that the fields were renamed
to 'a_terminations' and 'b_terminations', but I cannot use those in my constraints.

The only option that works is using the complete 'terminations' List in the constraint. This allows me to ensure that
at least one connected interface/device is correct, but not both (or actually: all).

Questions:

• Why do 'a_terminations' and 'b_terminations' nor work in the constraint? Is the changelog documentation wrong?
• Is there a way to express that all connected objects in the 'terminations' list must comply to the constraint?

[vink78]

Dear @georg-again,

I've the same issue as yours. Can you explain how you mitigate the constrain to work with at least one connected device is correct?

[vink78]

In my scenario, I only need to have one termination to belong to the specific tenant. I was able to set up my constraint as following:

[{"terminations___device__tenant__name": "<name of the tenant>"}]

[georg-again]

TLDR - there is no solution

Details:
As far as I understand, the code that checks the constraints uses the model and its attributes, but only the
part that can be executed/performed by the database itself. 'a_terminations' and 'b_terminations' are derived
attributes and not part of the database. Thus they cannot be used in the constraint, only in API calls.

As for the 'at least one' connected device problem: This is also integral part of the constraints. The constraint
is true if at least one (overall) object is found that matches the constraint. It is not designed for lookups that
return several objects.

As such I did not find a reasonable mitigation and my problem is still open.