Export Models about jube HOT 5 OPEN

Hello. Thank you for engaging with Jube and using the software. Let me first apologise for not having seen this issue before now it fell in the cracks with other Github notifications and most of our support tends to come through LiveChat these days. Mental note to check other people's bugs and ideas more often here :)

At the moment this feature is not available, however, it is important. I will keep this ticket open and look to include it as a feature. In the previous version of the software, which was .Net Framework, this feature existed. It is technically not that difficult to implement, but we never got around to it in this version of the software.

The software has started to get a lot of use and there are lots of little features like this backed up.

In the meantime, you will notice that all of the configurations are laid out in database tables and henceforth, you could export the rules via a select \ insert statement. However, there are so many tables and so many dependencies, that this is extremely time-consuming. The pattern in this export will be something similar, serialised to JSON files, zipped up, AES encrypted and available for download. There are some injection risks here, so, it is likely that any export will exclude the compiled assemblies, but they will just get recompiled on start.

from jube.

This is the next project after the Redis implementation #32. The current plan is to achieve the custom export and import via use of the controllers, packing into a custom object bringing those controller responses together, serialised to json for download. In this manner the import export functionality serves to provide a unit test capability, especially if subjected to various integrity assertions as part of the process. As the import export process will wholly use the controllers it implies minimal integrity checking of the file is needed, given that it will use the permissions otherwise granted to the user (insofar as they already have admin). This will not invoke the HTTP endpoints, rather invoke the controller directly, rather than having been serialised from Json.

The recovery step will delete out all data in the tenant logically, annotating a recovery event id alongside the delete. The availability of a recovery event will allow for the rollback to a previous version. There will however be no merge functionality.

Aiming to get this released by July, as the #32 due out June (largely done at the time of writing but needs tidy, test and documentation).

from jube.

We implemented export feature in the following way: a new endpoint returns a big JSON object representing all setup that was done via UI. It has properties like: model, requestXPath, inlineFunctions, abstractionRules, activationRules etc. Each node-object is loaded by calling the code of appropriate GET endpoints returning these objects. Resulting JSON can be big but it is suitable to store it and compare across different environments, installations etc. It is like a big snapshot of all settings.

from jube.

Thanks for feeding back. It is nice to hear you found a scripting solution. I keep meaning to get to this, but not quite where I wanted to be on the Redis work. Furthermore, as I am moving the UI to Blazor as the next big project, those controllers you are using - which will still be available - are likely to have the logic moved to a service dll. It makes sense to get the services together first, and invoke them in this import export routine.

I can't help feeling the http overhead and serialization is a little bit workaround, so, in time I am sure we can make this better.

from jube.

Depends on #43.

from jube.