Portal Actions Referencing Moved or Invalid OUs

Question

Hi,

we have a custom action in our Adaxes portal that allows users to select only users from a specific country and only if they are members of two specific groups.

Due to a recent restructuring, these groups were moved to new OUs. We noticed afterward that the action criteria was not updated and is still pointing to the old OU.

Is there a way to automate this or make the criteria dynamically update when such changes occur?

Or do we need to manually review and update our actions each time objects are moved or restructured?

Additionally, is it possible to receive a notification or run a script that checks for invalid or non‑existing objects referenced in action criteria?

Our action and criteria are as follows:

Answer 1

Hello,

Is there a way to automate this or make the criteria dynamically update when such changes occur?

Unfortunately, there is no easy way to do that. It will require quite complicated custom scripting. Also, you will need to take into account that such updates can be performed outside Adaxes.

Or do we need to manually review and update our actions each time objects are moved or restructured?

Yes, that is correct.

Additionally, is it possible to receive a notification or run a script that checks for invalid or non‑existing objects referenced in action criteria?

Unfortunately, there is no such possibility. However, thank you for the suggestion. We forwarded it to the corresponding department for consideration.

Comments

Hi, I just noticed that the path to user objects under Visibility is updated automatically. Maybe the same logic could be applied to the objects used in action criteria?

At the moment, I was able to use the “Copy all actions” option, which provides a JSON file containing all actions and their settings. From there, I can search for relevant strings and paths to identify the actions that need to be updated.

//Edit

I now see why it is updated automatically for the Visibility section. The object is stored with much more information, such as the GUID and SID.

The criteria, however, only uses the DN as its value.

---

Hello,

You are absolutely right, there is a significant difference. The thing is that the Visibility section stores objects. As uses have properties that never change (GUID, SID) it is possible to still reference them properly in case of a move to another OU. In case of criteria, there s just a DN as a string. There is no way to validate it or catch the corresponding object being moved.