-
Notifications
You must be signed in to change notification settings - Fork 429
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
Navigate directly to created change requests #4114
Comments
That was next on my list of feedback :) I agree adding the link(s) to change requests from the feature modal would help. Haven't thought about how we would handle multiple change requests for the same feature since AFAIK we can't filter change requests by target feature. Maybe we could inline each change request IDs/titles/target dates/authors/links.
I don't think this is a common scenario, especially when creating change requests that others will need to review. If an environment requires change requests to begin with, it's likely because it's sensitive and users need to tread carefully when making changes - to me this is a sign that this workflow should be optimised for confidence (i.e. immediately show the created change request for validation) rather than speed. To me, this is a similar reason why we keep the Feature modal open when directly saving changes instead of closing it - we give users confidence by staying on the page to give them a chance to re-read what they just changed. Browsing directly to the change request makes it faster for users to share the link to the change request to others for approval, instead of needing to find where the link is on the page, or manually browsing to it and then copying it from the address bar or using a Share button. Imagine if you're a junior developer making your first ever change request on a Flagsmith production environment - I'm fairly sure the first thing you would do after creating the change would be to browse to it, to be 100% sure that your changes are correct. Browsing directly to the change request is more reassuring and not as scary as popping up a warning box saying that there are open change requests. We know this warning box exists ahead of time, but to unfamiliar users it's not far from being a jump scare (it would still be jarring if it's an info box IMO) I was going to suggest that another way of making changes to multiple features quickly would be to CMD+click or middle-click each feature to open them in their own tab, but this isn't actually possible - each feature in the Features list is a
I can see the argument for either - what I like about the warning is that it warns users that any changes they make might get overwritten by existing change requests. This might not catch their attention so much if it's an info box. The same reasoning as above applies - environments that require change requests are sensitive, so I would err on the side of caution (warning).
Agreed. |
Is your feature request related to a problem? Please describe.
When a change request is created, a toast notification showing "Created Change Request" is shown. However, there is no link to such change request, and users need to manually navigate to Change Requests to find it. This can leave users wondering if they actually created the change request correctly, especially if they don't notice the notification before it disappears.
Describe the solution you'd like.
I see two possible solutions:
I believe option 1 makes more sense for several reasons:
Describe alternatives you've considered
🤷
Additional context
change.request.mov
The text was updated successfully, but these errors were encountered: