Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow different clients to access limited form_config scope #340

Open
signebedi opened this issue Sep 2, 2024 · 0 comments
Open

Allow different clients to access limited form_config scope #340

signebedi opened this issue Sep 2, 2024 · 0 comments

Comments

@signebedi
Copy link
Owner

Presumably, bifurcated server/client deployments may need different clients to have access to different sets of forms. For example, form_1 and form_2 may need to be accessed by personnel employing client_1; whereas, form_3 may need to be accessed by personnel employment client_2. The principles-level question is where should this scope be manifest? Given the proposed design in #329 requires clients to access the REST API using admin-access service accounts. This means that clients already have the keys to the kingdom. Further, servers probably should not concern themselves with the clients that are accessing them, at least as it relates to the server configuration; such an approach would REQUIRE a change to the server config every time we add a client; whereas, in the current proposed designs, there need not be any change to the server config, instead admins need only create an admin-level service account, which merely concerns the relational database. Thus we arrive at the likely solution: that we specify (as a client app config) an exclusive list of forms that the client wants to make available to users. It can default to None, in which case all forms will be made available, which I think is good default behavior.

Originally posted by @signebedi in #329 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant