You know how it shows the YAML output in configuration task when you Build Yaml? Maybe something like that… a way to see it like YAML. I know its not saved as YAML but something to visually see it before committing maybe.
Such transformation (XML > Editable and Editable > XML) needs a lot of development. I can’t promise a quick solution but I have some plans to improve YAML format for partial imports (like updating a single custom data of all entities). While doing that I can also look that.
See I need it today for GQL-Modules. I created a bunch of Exports, and today I changed some of the HUB Rules (maybe 2 out of 13-ish, and maybe I added a Rule, or whatever, I don’t remember), and now I need to re-create the Exports.
But which ones? And what did I select for Export last time? Will I miss something this time? Probably… So it would be so much easier and less error-prone if we had this.
I mean, I forget what is in the Exports already, and I just made them 2 days ago. And even then if I miss something and I notice it, then I need to re-make it on the spot again, and again, and again… tedious and subject to missing something again and again.
Yes, also had similar problems with modular partitioning of automation sets and keeping track of changss. In our case we are 2 people making changes to 2 different versions of the system in different areas. While I’m updating rules and possibly breaking things, a colleague is running tests and making small changes.
My plan was to simply merge the new automation into the other db with Import/Export. But alas, there are various scenarios which cause the import to break, and last time it took me hours to merge. Looks like Import needs some work.
After getting everything working smoothly after many hours work, it is disheartening to get see the error “Sequence contains more than one element” at which point I suspect the neighbors are wondering what’s going on next door. Sounds exciting but not.
QMcKay I would love to use your new extension to the phpApp to at least review prior to import!
It seems the best would be to use Configuration tasks as Kendash suggests, because I often rename rules for clarity and organization and after transfer end up with a load of rule duplicates and need to manually go through and delete them.
It would be much cleaner to delete everything In a “module” name space by matching a token or prefix, then import the replacements.
To avoid conflicts between function modules I have been using cloned tasks with module prefixes instead of using generic tasks even when they are currently identical. It’s an attempt to create independence where possible, but so far it didn’t help much because of so many import errors. I mean it still takes too long to sort it all out!