Easily Move a Type to Another Theme
As a solution builder,
I want an easy way to move a type to another theme,
So that I can re-organise types into the right themes,
The benefits are that it will be possible to maintain a meta-model, as it grows organically, so it still reflects the business it represents, and it will be possible to re-organise themes with too many types into multiple other themes, each with fewer types.
The acceptance criteria is that in "Manage Repository" it is easy to move a type from one theme to another, either using drag'n drop, or by being able to select from a drop down the theme that a type belongs to.
Priority is normal.
Today, it is possible to "move" a type to another theme by creating a matching type in the new theme and then move all the elements from the old type to the new type. This is so cumbersome to do that we only do it in rare circumstances. The result is that we in many of our repositories have a bad meta-model, because it is too cumbersome to clean up.
Regards,
Peter
-
Yes, that is correct.
Except, I think it should not be necessary to invoke magic; types should just have a simple reference to a theme, making it simple to move a type to another theme. After a type has been moved to another theme, the "Manage Repository" dialog is closed, and the explorer is refreshed, the elements of the moved type will naturally be shown under the new theme.
-
Peter, Hi
We discussed this in the roadmap team today, and rated it as something we would like to iterate a bit more.
We perceived that the challenge you were having was moving instances of types between themes, and that moving types might have been a solution. We also noted Giles comments about trickies in the story as raised, and postured that an alternative approach might be to raise a subtly different story enabling the duplication of types between themes.
This could give a multi-stage process to migrate content, giving the user the time and space to properly consider the movement of elements across the theme boundary. (particularly important in hierarchically arranged themes).
1. Duplicate type
2. Move instances as required. Assuming themes have the same relationships (including both source and target), then no data should be dropped here.
3. Remove original type
How does that feel / do you think it might fit the need?
-
It feel like there I need to take a backup first, try the move, then verify that it was successful, i.e. check that no data was lost. In order words, it feels like things can still go wrong. The assumption you write in step 2, I think should be a step on its own.
What about a wizard with these steps:
- User select theme, then types within this theme to be moved
- Wizard check if there are other element types in the element hierarchy that will prevent the selected type from being moved
- User select theme where the types should be moved to
- Wizard duplicates the selected types, modifies relationships, moves the elements, deletes the old types
This way the wizard helps with the difficult parts and verify the right prerequisites so no data is lost.
-
I realise I am a bit late to the party here, but I want to support this from our perspective. This is something we have done a couple of times and it is a real pain. What we would like to be able to do (using the "wizard approach" - so some magic involved after all) is:
Select the element types we want to move. We envision three possible cases
1. Hiearchies are "simple" (i.e. all elements of the type are only in hierarchies which only contain this type of element)
2. Hierarchies are "complicated" (i.e. all elements of the type are only in hierarchies with parents which are strictly of the same type or are top nodes)
3. Hierarchies are "muddled" (i.e. elements are distributed throughout its "main theme" without any ordering
The "simple" approach is fairly straight forward in that what needs to update is where the theme is "placed" and then to move all the instances of that theme to it's new main theme. Relationships to/from the theme and all instances should be retained.
The "complicated" and "muddled" approach is a bit more, well, complicated. Here, we would like to be given the option of moving the themes and all themes which are affected to its new main theme. We realise this could be quite a bit more complex. The criteria for when something can not be moved in this fashion is if the affected themes have parents in themes which would not move (e.g. you get a set of boxes you have to "tick" to be able to do the move).
Other than this, we like Peter's "wizard" idea. We would like to add that queries and matrices would potentially be affected, so those would have to be taken into account as well...
Please sign in to leave a comment.
Comments
11 comments