✨ Add server.getConfig endpoint to ozone #2494
Conversation
| "viewerRole": { | ||
| "type": "string" | ||
| } |
There was a problem hiding this comment.
I wonder if we can future-proof this by making this instead: viewer: { role }. That way if there is more viewer-specific info, as I expect there could be, we have a place to put it.
packages/pds/src/lexicon/lexicons.ts
Outdated
| properties: { | ||
| configured: { | ||
| type: 'boolean', | ||
| }, | ||
| url: { | ||
| type: 'string', | ||
| format: 'uri', | ||
| }, | ||
| }, |
There was a problem hiding this comment.
What is the purpose of configured? For example, would it ever make sense to serve { url, configured: false }?
There was a problem hiding this comment.
A related thing to look at is whether any fields should be required. Right now all of these are in play, for example, and I think they may be interpreted the same way:
appview: undefined
appview: {}
appview: { configured: false }
appview: { configured: false, url }There was a problem hiding this comment.
I guess we can infer from the presence of url if the service is configured or not which makes the configured prop redundant.
| url: { | ||
| type: 'string', | ||
| format: 'uri', | ||
| }, |
There was a problem hiding this comment.
Does the ozone UI ever need to use this URL, or is its presence simply used to determine whether certain functionality appears in the UI?
One reason I ask is because another approach to this could be to serve flags that advertise what functionality the Ozone backend will support for a given user, and in turn what functionality the Ozone UI should display. This could take into account both the backend's configuration as well as the user's role.
I've had some luck with this in the past because the backend is the defacto source of truth for what functionality is available to the user, and the alternative is for both the backend and frontend to interpret config/roles/ACLs independently and come to the same conclusions about which features are available, which can be prone to error.
There was a problem hiding this comment.
Yeah I think I like this approach as well 👍
Although I still think it might be useful to return some of this config info just for giving additional details when navigating Ozone. For instance, just being able to see what your authz level is and maybe a "config/introspection" panel where you can see the services that Ozone is hooked up to
There was a problem hiding this comment.
as of now, this is just for display/introspection purposes. my thinking is that the backend will publish generic config and the frontend will determine, based on the raw config, which features to enable.
however, I'm open to BE publishing capabilities based on viewer role too. how does that look like in your mind? is it just an array of strings that contain the actions a user can perform, i.e: allowed: ['listUsers', 'listTemplates']? or would it be more evolved than that?
There was a problem hiding this comment.
Yeah, I think it could essentially look like a set of flags, which might be modeled as a list like that or like { listUsers: true, listTemplates: true }. I slightly prefer the latter, since it's more flexible if some of them call for a value other than a boolean.
It would have to be able to express more than which endpoints are available to the user, since there are some access rules like "can takedown account" which is a specific usage of the emitEvent endpoint. The sweet spot may be to make each flag a logical grouping of capabilities such as "can communicate with users" / "can view communication templates" / "can manage communication templates" / "can takedown accounts via label" / "can takedown accounts from infrastructure".
There was a problem hiding this comment.
alright we talked it out a bit ago but wanted to keep some traces here. as a next step, I will get a frontend PR up to better clarify how these configs will be interpreted and used on the frontend before making a final call on whether or not the backend should send more detailed and granular permission definition.
| "role": { | ||
| "type": "string" | ||
| } |
There was a problem hiding this comment.
We'll want to remember to sync this with your work in #2460 👍
Should we look ahead and at least start by using compatible role values with the ones used in that PR?
This helps ozone client to be aware of what the server is capable of and adjust the UI accordingly.