Handle automatic migration of changed ObjectAttribute select fields (or prohibit changing the Key)

t-shehab · September 26, 2023, 7:41am

Title: Handle automatic migration of changed ObjectAttribute select fields (or prohibit changing the Key)

What is your original issue/pain point you want to solve?
When I update a Key/Display pair of an ObjectAttribute’s select field, that change is not automatically applied to all occurrences of that field in the corresponding Objects.
Which are one or two concrete situations where this problem hurts the most?
When I change a Key/Display pair of an option in a single select field, then I have to manually update that field on all Objects where it is set. This is especially painful when I have thousands of occurrences of this ObjectAttribute set to the changed Key/Display pair.
Why is it not solvable with the Zammad standard?
Because Zammad neither prevents me from changing the Key of an ObjectAttribute’s select field, nor does it provide an automatic migration after I have changed it.
What is your expectation/what do you want to achieve?
As a regular user (without too much insight into the inner workings of Zammad), I expect either one of two things:
1. A change I make on the UI to an ObjectAttribute will be reflected throughout the entire software. I do not expect to be forced to manually intervene to have this change reflected.
  or
2. The software prevents me from making a change that would force me to manually update all occurrences to see that change reflected.

If there is any more useful information, feel free to share it all (e.g.: mockup screenshots, if something is UI related, or the API URL/documentation URL for a service you need a connection to).

github.com/zammad/zammad

Replacing an ObjectAttribute's data_option (key and display) does not update the Object if that data_option was selected

opened 11:40AM - 04 Sep 23 UTC

closed 10:16AM - 07 Sep 23 UTC

t-shehab

works as designed / wontfix

### Used Zammad Version 6.0 ### Environment - Installation method: any - Ope…rating system: any - Database + version: any - Elasticsearch version: any - Browser + version: any ### Actual behaviour Replacing an ```ObjectAttribute```'s ```data_option``` does not update the Object if that ```data_option``` was selected. ### Expected behaviour Replacing an ```ObjectAttribute```'s ```data_option``` should update the Object if that ```data_option``` was selected. If a ```key``` and ```display``` of a single-select or multi-select ```ObjectAttribute``` is changed, the affected ```Objects``` should reflect this change. If you have an ```ObjectAttribute```'s ```data_option``` that is set on many ```Objects```, clicking through potentially hundreds or thousands of them every time you want to replace a ```data_option```, is not viable. Either the ```key```-part of the ```data_option``` needs to be greyed out once it is set for the first time (like the ```NAME``` of the ```ObjectAttribute``` itself). Or an automated loop over every Object that uses the given ```data_option``` should be performed upon a user replacing it, to update it to the new values. ### Steps to reproduce the behaviour [screencast.webm](https://github.com/zammad/zammad/assets/114283486/9c151295-8b9f-47a1-90f4-9973cb45a3f0) ### Support Ticket Ticket#10138497 ### I'm sure this is a bug and no feature request or a general question. yes

Your Zammad environment:

Average concurrent agent count:
irrelevant
Average tickets a day:
irrelevant
What roles/people are involved:
irrelevant

Anything else which you think is useful to understand your use case:

Thank you and have fun.