uwazi
uwazi copied to clipboard
huridocs
Read only instances
After https://github.com/huridocs/uwazi/issues/6493 we currently have a situation where it’s not clear when a tenant should be ‘read only’.
A criteria could be that it has synced templates, or that the collection settings have the sync config present. Currently, tenants that are synced, cannot edit synced templates. They can however create their own templates, and create entities for all templates even if they are synced.
There are cases where tenants have no default template. Operations like uploading PDFs to create entities will throw an error since the process needs a default template defined.
A good general solution would be that synced templates cannot be used to create entities. To solve the upload PDF issue we could disable the button if there are no default templates, or allow users to choose what template they should upload the PDF for.
In any case, it’s important to identify how we want to handle data creation/edition on synced instances, or if we should disable it altogether. For the latter we need a clear identifier that the tenant is ‘read only’.
This is important to address. The existence of "synced templates" is a good approach. The sync config present is not, as that resides on the parent collection and not the child one. Other than that "synced" flag on templates, there is actually no other current way to define a synced child collection.
We could add a simple flag to the general settings signaling it's a synced collection, which would have to be manually done at this point, or maybe the sync process itself could set that flag on the child collection.
Yeah, there are a couple of approaches we can look into.
There was a question around allowing "extra" templates and entity creation on those. The problem here is that, while this could be useful for presentational purposes, particularly items using thesauri, and, more critically, relationship properties to synced entities, would fail if they are edited on the parent collection, as these processes are done at the DB level and no higher-level functions are triggered: re-denormalization, re-indexing, sanitization (in case of deletion), etc.
So we should prevent any edition on Templates, Entities, Thesauri, Relationship Types (this list may need expanding).
The only editable areas should be Pages, some Settings, Custom CSS and Custom JS. On pages, Public Forms should, ideally, have always a "remote" flag, but we could delegate this "good practice" on the admin for the time being.