Geo Replication - Confirm Resync/Reverify Action
What does this MR do?
Closes #327587
We have had a few instances where users clicked the "Resync All" button with the UI filtered to only Failed Items. Understandably so the users thought this resync button would respect their filter but in fact the action applies to everything. This misunderstanding can cost these users hours upon hours of resync time with very large databases.
The long term fix here is to add filtered resync support to these buttons. However, as a first iteration this change simply adds a confirm modal to make sure the user is aware of what they are about to do.
Important Notes
We are currently maintaining 3 variants of the Geo UI depending on the maturity of the replicable item.
| Data Type | Frontend | Data Source |
|---|---|---|
| Projects/Uploads | HAML | Rails Controller |
| Designs | Vue | RESTful API |
| SSF (everything else) | Vue | GraphQL API |
As of right now only Projects and Designs support any sort of UI actions to resync/reverify making this change a lot smaller than it may could have been in the future. Since the long term solution here is to provide filtered based actions, a lot of this is subject to change and thus this change is mainly a bandaid to help prevent the worst case where a user re-syncs millions of data objects.
There are parts of this change that are not very generalized (mainly the Projects related changes in Rails). These things will be changed either by moving them to the GraphQL API or by the filtered based actions (whichever comes first).
Screenshots (strongly suggested)
Vue - Resync Only
Legacy/HAML - Projects Resync
Legacy/HAML - Projects Reverify
Does this MR meet the acceptance criteria?
Conformity
-
I have included a changelog entry, or it's not needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. - [-] I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec - [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team
Related to #327587