next round of refactoring #35
Conversation
fixes #12 When tuttle is updated the configuration file, `/db/apps/tuttle/data/tuttle.xml` is backed up to `/db/tuttle-backup/tuttle.xml`. After the installation is finished either - a backup is found an restored and the backup collection removed - no old configuration was found and the example is used (copied from `/db/apps/tuttle/data/tuttle-example-config.xml`) - added cleanup.xq (runs before deinstallation) - post-install.xql was renamed to finish.xq (runs after installation)
- declare max processor version exist-db 6.x.x - drop unused dependency on shared-resources - formatting
- fetching repository state to staging collection - deploying state from staging collection to production collection - incremental update of production collection - add return types - add collection module - rename github:clone and gitlab:clone to :get-archive as that describes what is happening - move duplicate logic from the above functions to the api module - minor reformatting in config module - improve, adapt and extend tests
- replace dbutil:scan (shared-resources) with collection:scan
- set permissions to resources as well
- resources that belong to `nobody/nogroup` are invisible to `admin/dba`
the example permissions are therefore set to `admin/dba` and
mode is `rw-r----` which is quite restrictive but safe.
The comment in the example configuration changed to reflect that.
To test that permissions are applied `guest/guest` or `SYSTEM/dba`
are options.
There was a problem hiding this comment.
Can we come up with something a bit more flexibel for the collection name of the backup files? some minor comments. All in all really good stuff. Can you also add a note on the readme about the v7 known incompatibility. We could now set allow-fail on CI for as long as we restrict installation on exist v7
Is this still a TODO ? https://github.com/eeditiones/tuttle#db-to-git
|
|
||
| (: TODO: $target is not set in cleanup phase :) | ||
| declare variable $configuration-collection := "/db/apps/tuttle/data/"; | ||
| declare variable $backup-collection := "/db/tuttle-backup/"; |
There was a problem hiding this comment.
see my comment on mattermost, I d really prefer a collection name that is more flexible for other apps as well, and won't lead to one collection per app with similar demands. so far we only have system and app following the db root collection. Lets create a third location for this kind of backup files
There was a problem hiding this comment.
I do favour a broader solution as well. Please understand that this is not the right moment to set de-facto standards and the collection in this case is very short-lived. The entire /db/tuttle-backup is removed after installation.
And I would also prefer to discuss a general solution within the community not just among us.
There was a problem hiding this comment.
happy to discuss a general solution with the community. I just don't see what we gain there, by adopting a single use solution now, instead of one that is open to extension
There was a problem hiding this comment.
If we choose a collection name that is
a) the one other apps will be using then it needs extra protection from removal and will have to stay there even if unused
b) not the one we are choosing here, the code has to be changed anyway
|
@duncdrum Please be aware that there are much much more pressing issues than comments at this point. We will get to those eventually. I want to first get the main issues done. |
- hide `index.html` from URL - allow only get requests for most non-api routes - prevent exposure of the configuration file as it might contain sensitive data - move all static resources to `resources`-collection - requests to static resources (css/js/images) are routed to the `resources`-collection, which cannot be accessed otherwise to prevent directory-listings - remove unused /jwt route
fixes #12
Features
blacklisttoignorein configuration and throughout the code 1229819Fixes
http://e-editiones.orgshared-resources