Workspace Refactoring: How to relocate a shared component

I faced a need of workspace refactoring after it had got pretty messy. I made up a new directory structure and now I’m going to fill the structure with my current workflows. Well, it’s completely painless to move workflows. But is there a way how I could move shared components many workflows use multiple times, without being supposed to edit source XML files manually?

4 Likes

Hi @jan_lender

that is a really good use case, but unfortunately we have this not very flexible covered right now. As you mention, editing the XML files is an option. However, while I know you are capable of doing this, for most user this is not an option. I will open a ticket for this for tracking and making this possible.

5 Likes

I have a similar need with components I’ve uploaded to my public space on the hub. Having made reference in a few posts over several weeks regarding some components I had created, I realised that I really need to put all my components into a “components” subfolder, and even group certain components into further subfolders, but if I do that, it will presumably break any links I have previously published. On the other hand I don’t really want to leave old and new copies of components around just to ensure that old links aren’t broken. I can’t edit old posts (even if I can find them all), so is there any kind of best practice to relocating public components, or do I just assume that users will do a search of the hub if a link no longer works?

Perhaps my real learning from this is not to publish links, but to just say “search on the hub for xxxxx” in future… and what happens if a shared demo workflow contains a publicly shared component (or somebody actually makes use of a component that I’ve published) and the component is then moved to a public subfolder. Does it then break in the workflows, or does it just no longer find updates?

3 Likes

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.