Design discussion: Virtual registries

Release notes

Problem to solve

Intended users

User experience goal

Proposal

From David's comment, this is the high-level UX proposal:

Because the cache settings are stored per registry and not at the root level, I think I'm leaning towards having a standalone subgroup menu that would allow both usages:

1. Inspect existing registries, upstreams and cached_response.
2. Create or update registries, upstreams and adjust (cache) settings.

What I mean with that is that the starting point should be a new entry in the Operate menu (next to Dependency Proxy). From that entry, users should have access to whatever their permissions allow them (either read-only navigation or administrate the settings). I would not have settings in the group settings menu. Why? Because, at some point, we will have multiple registries and each of them will have their own settings. Thus, I don't think it's a good idea to have a duplicated navigation through registries in the Operate menu and the Group settings menu.

The next description is the UX for the first iteration which has the restrictions that are mentioned above.

The starting point is users have the read_virtual_registry permission on a root group. They will see a Virtual Registries entry. Clicking on it will show:

• List registries page
  • if no (maven) registry exists, an empty screen is presented. If user has the create_virtual_registry permission, a "Create Maven registry" link/button is shown. Clicking on this will lead the user to the Create Maven Registry page
  • if a (maven) registry exists, it is "opened" and users are taken to the show Maven registry page.
• Create Maven registry page
  • Presents the form to create the maven registry. The form is mainly the cache settings.
  • Usual save/validation UX.
  • Upon a successful save, users are led to the show registry page.
• Edit Maven registry page
  • Same as "Create Maven registry page" but form is filled with the existing registry settings.
• Show Maven registry page
  • if no upstream exists, an empty screen is presented. If user has the admin_virtual_registry permission, a "Add Maven upstream" link/button is shown. Clicking on this will lead the user to the Add Maven upstream page.
  • If an upstream exists, it is "opened" and users are taken to the show upstream page.
• Create Maven upstream page
  • Presents the form. Mainly the url and the credentials (in Maven case, it's a username / password combo).
  • Usual save/validation UX.
  • Upon a successful save, users are led to the show upstream page.
• Edit Maven upstream page
  • Same as "Create Maven registry page" but form is filled with the existing upstream settings.
• Show Maven upstream page
  • Show the url of the upstream.
  • If user has the admin_virtual_registry permission:
    • an edit registry button/link is shown. Clicking on it will bring users to the Edit Maven Registry page.
    • an edit upstream button/link is shown. Clicking on it will bring users to the Edit Maven upstream page.
  • If user has the admin_virtual_registry permission, a destroy upstream button/link is shown. Clicking on it will destroy the upstream (and its related cached responses) and route the user to the Create Maven upstream page.
  • If user has the destroy_virtual_registry permission, a destroy registry button/link is shown. Clicking on it will destroy the registry (and its related upstream along with the cached responses) and route the user to the Create Maven upstream page.
  • A list of cached response are shown (paginated) with relative_path, content_type, last_downloaded_at, download_count.
    • On each row, if the user has the admin_virtual_registry permission, a destroy button/link is shown. Clicking on it will destroy the cached response and reload the current page of cached responses.
  • A search on the relative_path should be possible.

For the UX, the goal is trying to balance:

• Present a very simple user flow and
• Prepare things for when we have multiple registries (of different or same formats) and when we have multiple upstreams.

To achieve this, the idea is to have show pages that would usually show the associations (for example, the show maven registry page would list the upstreams) but given that we have restrictions in the first iteration and only one package format, these pages should take users to the next underneath level if that is possible. Basically, the navigation should take the user as deep as possible.

Thus, when there are no objects, we present empty screens. However, when we have a Maven Registry and a Maven Upstream set up, clicking on the Virtual Registries menu entry, we should take the user down to the show upstream page where the user can browse the cached response.

As said in the introduction above, the settings links and forms will live close to the show pages. Users with the correct permissions will see the buttons to create, edit and destroy the different objects.

❓ Questions:

• Is this ok for the first iteration?
• Do we need to validate this UX and/or create some designs?
• To accelerate the implementation, we should find an example of rails views used on a collection of elements that has a search and pagination feature.

Further details

Prior designs:

1. Virtual repositories: Design an interface focused on enabling users t... (#212168 - closed)
2. Remote registries: Investigate: Dependency Proxy to include packag... (#241604 - closed)

Permissions and Security

Documentation

Availability & Testing

Available Tier

Question for @trizzi : What tiers are we supporting? This will be useful to prepare for code organisation as well

Feature Usage Metrics

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

What is the competitive advantage or differentiation for this feature?

Links / references