#14 Blocker Proposal is Slow
Opened 10 years ago by mkrizek. Modified 4 years ago

Moved from trac [[ https://fedorahosted.org/fedora-qa/ticket/356 | https://fedorahosted.org/fedora-qa/ticket/356 ]]:
"Problem
While the blocker proposal functionality does work, the process of actually proposing the blocker is very slow - it appears as if the page has just stalled for a while as the request is being submitted to bugzilla

Outside of being an annoyance, there is a possibility of users refreshing the page during submission, which would trigger a second proposal. This isn't the biggest issue ever but could end up generating extra comments in bugs.

Analysis
It would be better to show users a "bug is proposing" page until the proposal is complete - that way they wouldn't be tempted to refresh the page and if the page is done correctly, it wouldn't matter if the page was refreshed or not.

Enhancement recommendation
I have some ideas on how to go about fixing this but I need to explore the details before figuring out if any of them are even practical or how long the implementation would actually take."


This is something that would be nice to have, but isn't critical. Changing priority to "wishlist"

Metadata Update from @adamwill:
- Issue tagged with: enhancement

4 years ago

Login to comment on this ticket.

Metadata