We have recently started using ODAGs within Qlik Sense Enterprise Self Managed. We are looking at changing part of our process of how the selection app and the detail template generate data.
Today, we use QVDs for mostly everything. My citizen developers have access to QVDs only and not the database connections directly. We do like this process, but we are running into some issues.
The overnight process to build the QVDs for the detailed app templates take a while to rebuild each night. I'm looking at swapping the detail template apps to pull data from the database directly when the app is initially loaded and any subsequent refreshes by citizen dev's.
Here is my issue and I am wondering if this can be adjusted via a security rule or something else. To my knowledge, the citizen dev still needs to be able to see/view the data connection in order for the ODAG selection app to fire off the query, initial load the detailed app, and subsequent refreshes. However, I DO NOT want a citizen developer to able to "select data" from the connection in the ODAG app (or any other app for that matter) and be able to look through the database at available tables, views, etc.
So how do I allow the ODAG to use the database connection when a citizen dev loads an app, but also restrict them from seeing or selecting data from the data connections pane?
I think I found my answer, but need some validation. In order to refresh the detail app, say the next day after it was generated, you would go back to the summary app and find the detail app in the list you need to refresh. From there you just run a reload. That in turn should use the service account that connects to the db and rebuilds the app just as you did from the start, correct?
To the best extent of my knowledge and experience, this is correct.
Hi @AvsFan1 You may want to consider creating a dedicated data connection specifically for ODAG, and assigning it a user with read-only permissions limited to the required tables. This can help improve security and ensure more controlled access to the data.
Insofar as using the ODAG app, the user does not need connection access. We use the same process (ODAG to directly query DB) without issues. However, letting people develop their own ODAG apps without giving them access to the data connection in full is something I don't think you can feasibly do. A full-access developer will have to develop the ODAG app, presumably, since authoring the target app necessitates connection access (someone has to write the actual queries...)
Hi, I think you can accomplish this with a combination of:
-Data Connections owned by a service user -Security rules limiting access -ODAG template apps designed to use pre-defined load scripts -Disabling data manager / data load editor features as needed
in this way ODAG should query the database directly and citizen developers could trigger ODAG workflows (query, load, refresh) without being able to browse/select tables or views manually through the data connection in the hub or data manager.
We have considered this, but I would need to have several "users" on the db side that have different access to different views/tables. Not sure if we are ready to have that overhead or not. ODAG aside, we sort of do this process today using folders, QVDs, and custom properties. We segment QVDs by business areas and give access to those QVD folders/files as needed by assigning a property.
For this to work on the db side, seems like I would need to have our DBAs create a lot service type user accounts that have different access to the db. From a security standpoint here, that isn't going to work. It can get messy quick.
Our selection app is running off of transformed and aggregated data in the form of a QVD. The detail app template has the db connection. This seems to work just fine as you had mentioned.
I think my initial question (before I did a lot more testing a research) was once the detail app is built, how is the user able to refresh their detail app without the db connection in their list of connections.
I think I found my answer, but need some validation. In order to refresh the detail app, say the next day after it was generated, you would go back to the summary app and find the detail app in the list you need to refresh. From there you just run a reload. That in turn should use the service account that connects to the db and rebuilds the app just as you did from the start, correct?
I would assume if you just opened the detail app and tried to refresh it on your own, its going to look for the database connection you may not have access to.
Is this how the process should be working? From all of my testing this seems to be process. Generate the detail app AND refresh your detail app(s) from the selection app when needed. Not refresh directly in your detail app in the load script editor?
I think I found my answer, but need some validation. In order to refresh the detail app, say the next day after it was generated, you would go back to the summary app and find the detail app in the list you need to refresh. From there you just run a reload. That in turn should use the service account that connects to the db and rebuilds the app just as you did from the start, correct?
To the best extent of my knowledge and experience, this is correct.
