Merging objects
Beantwoord
Due to more and more users using BlueDolphin, we occasionally find that two objects in the repository define the same thing, but have a different name. Of course, we do not want that, and we do everything we can to prevent it. Sometimes, after weeks or months, we find out that two objects (with the same object type) mean the same thing. Which is annoying, because which one do we choose to relate to or use in our views?
If both objects have already been used on multiple views and have multiple relationships, it is a huge job (including communication) to rectify such a problem.
Solution: Is it possible to have two objects of the same object type merging into one object by an administrator, leaving views visually untouched and combining all existing relationships of both objects on to the persisted object.
EDIT: Translated post.
-
Officiële opmerking
We have an update to your wish. This is not on our roadmap for 2023, but we do have it on our backlog for 2024. We understand the proposed workaround is not ideal, but building a merging feature that would work like this would be a very high-cost feature at this time. That means many other requested and planned items would drop off the 2023 roadmap. Hence, we're further refining this over the year and are reevaluating it in 2024.
Let us know if you have any questions or concerns.
-
Hi Mike,
This is a good wish. Rianne Gillijns, what do you think of this?
I am also interested in finding out how other BD users think of this wish? Please let us know in the comments or vote for MG || Gemeente Tilburg's wish!
0 -
I agree, nice wish! Of course you should avoid this situation happening as much as possible. A good governance on who is able to add objects and for instance agreements on naming conventions on objects should prevent this!
0 -
It should, but it doesn't.
0 -
I translated your wish. Can you take a look at it:
Due to growing usage, two objects sometimes sneak into the repository that means the same but has just been renamed. Of course, we do not want that, and we do everything we can to prevent that. Sometimes, after weeks or months, we find out that two objects (with the same object type) mean the same thing. Which is annoying, because which one do we want?
If both objects have already been used on multiple views and have multiple relationships, it is a huge job (including communication) to rectify such a problem.
Solution: Is it possible to have two objects of the same object type merge into one object by an administrator, leaving views untouched and all existing relationships of both objects going to the persisted object.
0 -
Moved translation to start.
0 -
I agree that it would be nice functionality, but I don't really see this being created any time soon. It has a lot of technical depth to it (which relations to keep, which labels, which properties, etc basically all the decisions you have to make now as well).
On our roadmap we have "Transformation management", which will allow to approve of disapprove newly created items. This is going to help with this as you probably has less "duplicates". But still you could definitely approve a second item by mistake.
For now i can only give my approach to this:
- Choose which one to keep based on the number of views. Keep the one with the most views, regardless of the Title it has (I'll call it "Keep" in the remainder of this post). Or maybe when this is about a business process object, keep the one with the BPMN view you want to keep as you can't replace a business process on a BPMN view (if it's a easy recreate, you might still go with the most views approach)
- Rename the other object so everyone can see it will be replaced soon (I'll call it "Replace").
- On all views with "Replace" on it, add the "Keep" object.
!!! When you don't have rights, you can take ownership of the view, After modifications you can give ownership back to the original owner !!!
- The "Keep" will show all relations to object it already has on the view. Only move (drag and drop) relations from "Replace" to "Keep", when "Keep" doesn't have them.
- Delete "Replace" on the view (not from the repository just yet).
- Repeat this for all views of "replace" (hopefully not too many).
- Evaluate the properties of the "Keep" object. Copy them from "Replace" if needed.
When "Replace" isn't on any public view anymore, delete it from the repository. Rename "Keep" to the Title you want to keep and add the other title to the "name" property (this helps with finding the "Keep" object with an alias name).
0 -
Hi Rob,
Thanks for the elaborate approach, here are my thoughts on it:
The "transformation management" you speak of would slow down the normal day-to-day use for a lot of users, making it less accepted as a tool that is (more and more) widely used (say 30-50 users spread organisationnaly and geographically). If a user can add an object in some sort of preliminary way, we would be winning some cleanliness and time - but the user still has to go back to it when rejected (but I'm not sure how this feature would work...)
All the options you outline next are the steps we use now, but these have several drawbacks.
- It is very time consuming when both objects have 10+ views and 25+ relations.
- The views with the "Replace" object can become a nuisance, especially when you are opening your view with stakeholders. (We use "DUBBEL" now - But this can easily be put into the Name field.
- You have to keep telling your users to clean up the mess.
- The argument "which relations to keep, which labels, which properties, etc." doesn't hold imho because it would still be easier and faster if you get some kind of dialog box when (and administrator is) merging objects, asking these questions. Probably you'd want to keep all relations, delete the double ones, overwrite empty fields, ask which one to hold when fields have a different value.1 -
I added all your thoughts to an existing wish on our wishlist! Thank you for your feedback on this item.
0 -
Thanks for your update. I understand that this requires some technical remodelling, so I can wait, no problem.
0
U moet u aanmelden om een opmerking te plaatsen.
Opmerkingen
10 opmerkingen