Filter permitted forign keys by attribute in schema?

Hi Florian,

OnSaving script probably not enough?

Besides this, I'm afraid that a UI solution (in WebDesigner, Manager form, Angular portal...) is probably the least unfavorable approach.

Oliver

In reply to Oliver Paulzen (iC Consult):

Hi Oliver,

part of what we try to achive is to make the selection managable for the user.
Our customer has companies in nearly ever country of the world.
Limiting for example the selectable costcenters based on the person would make the live realy easy for the people out there.

We only onboarded three countries and already have 250k cost centers in the system.

In OnSaving I would only be able to punish people for a wrong selection... a selection that defined rules.
So why should I consider to allow users to select forbidden entries in the first place?

I also thought about using database views, but they only allow fixed conditions and, additionally must be check if they need to be changed if the base table gets alterted/extended. In the case of BaseTree objects that could lead into developers nightmare.

Third option, having the logic in UI is also boundled with a huge development effort. As I would expect that the logic is the same, regardless of the UI used.

So best case would be to define that in the object layer schema. But I don't know if there is maybe already a solution for this. I can't imagine that I am the first one with such a requirement.

Greetings Florian

In reply to florian.zedler@computacenter.com (External):

Yes, of course. OnSaving Script would only punish the user but not help to select the correct node. But I also mentioned it as a light-weight method to ensure consistency with your rules, even when the data is maintained outside of any UI (e.g. SyncEngine or Api).

If there's only one UI users use (there should be, right?), development effort shouldn't be that high, right? Could be that column-depend references in WebDesigner (Edit values by column > Foreign key filters) already provide most of the required functionality.

I'd be happy to hear from others if there're ways to address this in object-layer. If not, maybe something worth adding to connect.oneidentity.com/.../feature-request :-)

In reply to Sergei Orlov (iC Consult):

Still a UI solution (ie. not directly backed in to the object-layer) but at least a nifty one that's easy to accomplish. Thanks for sharing Sergei :-)

In reply to Oliver Paulzen (iC Consult):

Not sure what you mean by "regardless of the UI used".
Surely you have a defined way of how users should access/edit those values?
Generally, it is best to expose such functionality through the web portal, in which case your requirements should be very easy to implement using WebDesigner candidate filters, as stated before.
How else do you want to let people access the object layer? I wouldn't think you want to let people all over the word use the rich client tools?

In reply to christian.stevens@devoteam.com (External):

No, but when you think of APIs, you want to limit the assignable objects to the defined subset if there is a rule for it.

I don't want to change the same rule in X areas of the system when the schema would be the best place for that very rule.

I have two ideas where to put this rule:

1. Recycle the Formatting scripts value to accept a list of UIDs if the attribute is a foreign key. This list must be a subset of the foreign keys object type.
2. Introduce a new attribute called "Candidates Script" that accepts a list of primitive objects in its value. This list must be a subset of the foreign keys object type if the attribute is a foreign key.

Either way, the object layer must be adapted accordingly to include the extension correctly in all interfaces (web frontend, API, fat clients, etc.).

In reply to florian.zedler@computacenter.com (External):

Feature Request submitted:
connect.oneidentity.com/.../define-subset-of-permitted-foreign-key-elements-in-schema

In reply to christian.stevens@devoteam.com (External):

WebDesigner, Manager, ObjectBrowser...Admins and developers are people too ;-)

In reply to florian.zedler@computacenter.com (External):

The object layer can only react to values that have already been entered, by evaluating format scripts and so on. There is no part of the object layer that prevents you from entering a "wrong" value into a field - it only prevents you from actually saving that value to the database, reactively but not proactive.

If you want to help users by e.g. presenting them a list of allowed values, that is nothing the object layer can provide for you. This will always need to happen in the UI. APIs would also need to first poll for a list of allowed values, and then write one of them in a separate call.
Every solution will need to include changes to the (all) clients/UIs as well.

For just the sake of central management, defining your own "candidate script"/whereclause through e.g. ConfigParms should be easy enough, and then implement the logic accordingly where needed.

In reply to christian.stevens@devoteam.com (External):

Not yet. But maybe in the future it can :-)