Description of the limitation and why it is relevant to address
As an Admin, I would like to control who creates an app for production so Iām able to control the published app.
We have quite a strict quality system before an app should be published to production. Now Any dev can create an app (thankfully not a workspace). As soon that happened any user can be triggered to ask for a workspace for that, which leads to an unnecessary maintenance burden for the admins. Also now our apps overview is polluted with apps that I donāt want to have here.
I am actually very surprised that any dev can create an app.
Thank you for describing this limitation. In my opinion we are currently missing a ādraftā or āin-developmentā state for apps. I understand that you would like to have controls before flagging an app as production-ready. Currently, you would be able to use the labels to indicate that an app is not production-ready yet.
However, in my opinion it is also very valuable for a developer to be able to test the application or gather feedback from users during the development process. Now this requires an administrator to set up a workspace and add users specifically for testing purposes, which can become a bottleneck when the number of developers grows. So restricting workspace creation to admins is also not an ideal solution.
I think it could be valuable to have an intermediate state where a developer is able create a ādraftā app, publish versions and add users for testing. Upon completion this app could then be āapprovedā by an admin to make it available in the app store for users to see and request access to it. Do you think a flow like this could work?
Iām uncertain if that approach is effective. Weāve observed instances where individuals create apps simply because thereās a button available, and theyād like to explore this further. As an administrator, I strongly advocate for the functionality for admins to remove apps in such cases.
We maintain a strict approach, so I propose making this functionality configurable at the company level. This way, we can carefully decide which permissions to grant.
Additionally, if we adopt your proposal, I recommend that ādraftā apps remain hidden from users in the āappsā overview. This prevents unnecessary requests for access. As you mentioned, our current practice involves labeling apps as āobsoleteā or āin development.ā
I discovered that the ācreate appā workflow automatically generates an app instance.
One of our users believes they need to go through this workflow to start developing new apps. The result is truly problematic: our entire app store is polluted with ātest appsā that are not intended for production. We have a strict process for app creation, along with a set of rules for naming the apps. Because of this possibility, our entire system has been compromised.
Once again, I urge you to restrict app creation to admins, or at least provide the option to restrict it (similar to how I can restrict (private) workspace creation). I donāt understand why this wasnāt included with the workspace iteration:
In my last message I indicated that we were planning to work on an app archiving functionality. That has since been released, so any unwanted apps can be removed from the app store. You can find the archive button on the app details page:
Additionally, we are currently addressing the pain point you mention; to remove the clutter of test apps and apps that are still under development, users will only see published apps in the app store. Developers will see an additional tab āMy appsā that contains apps they maintain, irrespective of publication status. Administrators will have an additional tab to view all apps that have been created in the environment. Below, you will find a screenshot of the design of the administrator view:
In a concurrent development we will also be adding an editable UI name for apps. This UI name will be shown in the app store instead of the unique identifier which cannot be changed after creation. This will allow developers and administrators to decouple the internal name and the name the user will see. It can also be changed during the lifecycle of the app.
If you look closely at the screenshot above it also shows another change that we will be introducing in the product, namely a development workspace per app. That will address another longstanding pain point as this will allow developers to work on multiple projects simultaneously, without the need to clear their database when switching between apps. To support this, it will be required that an app be created before you can access the development workspace associated with that app.
To prevent a situation where a developer needs to wait for an administrator to create an app before development can start, I donāt believe it would be desirable to restrict app creation to administrators. With the changes listed above, which are planned to be released before the end of the year, do you think additional controls are required?
That seems quite a good improvement. Canāt wait untill the launch.
It is not clear to me who will be able to change the publication status ā IMO that shouldnāt be a right for every dev OR at least be the decision of the company.
About archiving apps: that works and I have used it, but it is not really deleting.
Nice to hear that you find the points above good improvements to the product.
It is not clear to me who will be able to change the publication status ā IMO that shouldnāt be a right for every dev OR at least be the decision of the company.
In the current implementation the filtering will take place on whether an app version has been published or not. However, we want to extend the functionality to allow for more control on the status of apps/workspaces. This is still very much in the discovery phase, so it is a bit too early to have a clear description of what this would look like. In that light your input would be much appreciated.
About archiving apps: that works and I have used it, but it is not really deleting.
Would being able to delete apps completely add value for you? What would that add over the current archive functionality?
Iām curious to lean more. IMO this implementation is not complete without the app status control, I would urge you to combine these two features in one release.
About complete deletion: If someone (accidentally) creates an app, I can no longer use the name. It is already in use (even if archived). As a result, even the archive (potentially_ becomes cluttered with nonsense.
Feature Requests - VIKTOR Community)
