ponceta
commented
5 years ago Pully
-1 Solution is used here, fk_district attribute does the job. But we have the chance to have a centralised edition for both districts.
Some tables missed this fk_district attribute.
Client side is a bit more configuration but is quite simple now on QGIS side. -> QGIS enables to set an attribute with default non editable value.
When using a centralized QWAT DB serving different organization, it becomes quickly necessary to offer a way to geographically filter rows so that each organization sees only its owns data.
QWAT has not been designed for that purpose and we'll try to evaluate the different solutions available. So far we see 4 possibilities :
-1 add layer filter in the qgs project and distribute different projects for each customer. Not secure, but helps to prototype and stress out the data model capabilities
-2 Use row level security policies or security barrier on views on DB's side. This would be more elegant, but relies on the same attribute filtering options as solution 1
-3 Distribute local QWAT databases and create an infrastructure to aggregate data in a central reporting database. This is not optimal since most small municipalities can't offer the hosting for the infrastructure
-4 Go to a full web app and handle row policies at the application level. Not planned at all at the moment :)
Any thougth welcome here !