Admin Configuration Page Setup

@shelly-goel - a Firefly app is deployed to a workspace that you specify, which assigns a Runtime namespace and relevant State lib access for it.

Speaking about app state, there are 2 separate concepts:

• build variables: used for building and deploying the app. Those are the values set in .env such as Runtime namespace and auth key, product API key, etc.
• application variables: used by the application to manage its state (such as a list of customers, product names). You could use aio-lib-state for these.

Can you elaborate on the request? Which kind of variables are you asking about?

Hi @shelly-goel we have implemented something like this, maybe the following ideas give you a starting point.

"Define Admins": we use "Product Profiles" to define which user should be an admin. basically we created a new product profile and added users as needed. The benefit is that you can now check the ims object if the current user of the firefly app is an admin or not (by looping through ims.profile.roles - is some work to figure out the details about a specific role). remark: the Role ID is stored in the ENV-File, so you need to create the product profile before deployment. But since you might use the same product profile for all environments, you already need it for testing and therefore it is aready available for production.

"Store Config Settings": we store the config settings using aio-lib-files and store the config as json object in a single file. but you can use aio-lib-state as well, but don't forget to set the right expiry if using state... using this setup allows to change the config after deployment (see below) without the need to redeploy anything.
Remark: the filename for the config file is defined in the .env file so that all actions have access to the right file - no need to change all over the app...

"Admin Screen": the core of the solution is a defined view in react with special behaviour and some additional actions. here are some points about this admin screen

1. Admins only: the screen is only accessible by admins - means in the component we check for the role and only display the real content if we can find the desired role in the ims profile. for everybody else we just display an error message like "no access - admins only"
2. Display current settings: The settings are fetched with an action and they read the current JSON from aio-lib-files. If the file does not exists already, it will be created with some default content (defined during deployment). be careful to handle future "expansions" of the JSON ...
3. Change settings: the current settings (see 2) are displayed in a form and allow to change the settings and "save". the submit is triggering an "update" action and request to save the input data to aio-lib-files. the action returns the result from the update process as well as a status (display update result to end user)

As an additional security step we implemented a manual check for the user permission on "fetch settings" and "change settings". Just in case somebody is able to see the admin screen, this additional check would prevent the display and modification of any data. How it works: on both actions (2+3 above) we make a manual API call to Adobe User Management and fetch the roles of the end user separately. Drawback is that you need some special permissions (and therefore additional API credentials) to access the User Management API. maybe it is enough if you just add an additional (almost hidden) key + timestamp to the action request which you check before doing anything.

"Use settings in the app/actions": last step is a class that allows to fetch the current app settings. basically you load the class and on init it returns the config object. this way all actions can access the same settings ...

While I think this setup allows a lot of flexibility, it also takes some time to make the setup. so be aware that this will cause more effort compared to just releasing a new version on the desired environment.

Happy to discuss pros and cons - or to answer additional questions