Mercury Features

[edda]

• Requests should be on project level, i.e. all people with access to the project (or maybe only people with a specific role (t.b.d.) should be able to see and interact with all requests made for this project
• See if there's a way to add data from project request to masterdata when project is approved
• Add possibility to add a comment or notice for the requestor that they can see (e.g. "New capacity is about to be rolled in. We will be able to process your request in about two weeks")
• Add possibility for internal comments that only processors can see
• It shouldn't be possible to make multiple requests on the same resource. If possible ask user if they want to adjust the values requested in the exisiting request
• Better filters for processors: filter by project, domain (?), resource, ...
• Allow processors to somehow "flag" certain long running requests that have to stick around a while before they can be processed so they can be filtered out of the list of stuff to be processed
• Sorting: sort by date, ...
• See if we can offer a global view of all requests instead of regional, i.e. the region would also just be an attribute that can be used for sorting and filtering

New (after meeting with controlling team):

• Payload should contain a section "stats" or similar which contains data to be exported to prometheus
• CSV export needs to export content from payload into separate columns instead of one column that contains the whole payload json
• Email notification service. Admins should be able to configure email notification for requests. Selectable options: type of request, region, event types (e.g. only on new, all, etc.). Multiple configurations must be possible. Users can also self subscribe for notification, this is for admin users who can choose the context (domain, etc.) and also for end-users, where the scope of notification is fixed (e.g. only project). Or we don't allow self-subscription for end-users and only notify the requestor
• add additional identifier for request type (something like "sub type" that can be used to further identify the request, e.g. we know that it's a resource request and the "sub type" contains information about the type of resource that was requested. This is so that we can prevent the creation of duplicate requests for the same resource