You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 !
The text was updated successfully, but these errors were encountered:
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 !
The text was updated successfully, but these errors were encountered: