Move inactivate version list to standard CRUD UI pattern

[agjohnson]

We are addressing a bug with our version display with #6224. This is an intermediate fix for a bug in the display, the final version to move towards would move us to a standardized pattern for our CRUD interfaces and probably isn't something we'd take on until we are using SUI and have a strong UI base to work from.

We have UI standardization notes about moving towards common UI patterns, so I won't reiterate here. The point of this next step for version admin would be to remove the pattern we're using in the UI here in favor of a UI/UX that is predictable and expected from the user's perspective.

In this case, standardization would involve:

• Add a button to the top of the list view
• This button leads to the create view
• The create view, which is the same form and view as the update view, is where a user selects the version from a filter search list
• The user can also select project privacy while editing the version
• The list view drops the second list view for inactive versions

Why?

• The user is coming to the page with one of maybe two motives: they want to activate a version or they want to update/deactivate a version that is active (or they simply want to see the list)
  • If the user is looking to see or edit versions, they are interested in a list view of active versions, it will be the first thing they see as the list view is prominent
  • If the user is looking to activate a new version, the button, also at the top of the page, will be the first thing they see. They don't need to scroll to the bottom of the page (or worst case don't see the listing of inactive versions at all because they have so many active versions)
• Filter view of the inactive versions is moved to the create view, and the tabular listing that we're using now for inactive versions is removed in favor of a simple search list, because:
  • It greatly reduces the amount of information that the user needs to process to find the version they are looking for -- no scanning redundant buttons, commit id, or version slugs. The user just searches for the branch name they are used to (also similar to the branch/tag search in GitHub/GitLab)
  • The bug of 5xx/timeout on list view display is caused by displaying a tabular view from our templates. Moving to a JS/API driven implementation separates the page load and data load operations. We might load all version from an API endpoint, or might figure out how to do a filtered API query as the user updates the search field, reducing the number of versions the API would have to process.
• Standardization of UI and template code. The UI/UX is standardized for the user. We might end up with a reusable template pattern for development as well. This would mean greatly reducing the amount of redundant template code that we're maintaining.

Examples

Mockups, using live loaded SUI, so the CSS is all wonky. You get the idea.

I loaded 50,000 version objects into search for this. The front end can handle a large number of branches without issue, but the bug that users are noticing could still be present if we're loading all versions through an API call instead of passing into the template. It might be necessary to do a filter on the API call, though would probably be worth testing without. There are several mechanisms we can play with here.

Going to leave this until we aren't blocked on SUI anymore.

[agjohnson]

This is addressed in the new templates already and will be resolved with a beta release of the theme.