Phase 4: Core UI Functionality

Mission:

To achieve core functionality in the UI and migrate more screens to console.redhat to win new customers, encourage existing customers to upgrade to a paid plan, increase retention of current paid users, and foster future Quay business through creating partnerships across the Red Hat ecosystem.

Epic Goal:

Enhance the performance and effectiveness of the Quay UI at scale  by building core functionality with all of the functionalities that exist on Quay.io today. 

 Priority: work on UI features that have broadest impact/ require immediate attention for core functionality on Quay.io first

The following UI features that are present in the new UI today that are top 5 in priority informed by data:

1. Tag List- History, Labels, & Expiration
2. Account Settings & Permissions
3. Teams and Membership
4. Robot Accounts 
5. Usage logs
6. Builds
7. Default Permissions (least in priority but only needs review to complete) 

Why is this important?

Supporting core UI functionality and performance at scale is crucial for providing a seamless user experience while providing large paying  customers with large content the functionality required to do business at scale.  Achieving UI parity with Quay.io ensures that users can utilize all functionalities without limitations. Addressing critical UI bugs enhances stability and usability, resulting in higher customer satisfaction and enhance their effectiveness on the Quay UI. 

Acceptance Criteria:

Teams and Membership

Scenario 1: Create a New Team

As a Quay user, I can create a new team within an organization. I can specify the team name, description, and members during the creation process. I can manage membership, add or remove users, and assign roles to team members.

Scenario 2: Modify Team Membership

As a team administrator, I can manage team membership efficiently. I should be able to add new users, remove existing members, and update their roles within the team. This will allow me to ensure that the right individuals have access to the team's resources and repositories.

 

 Tag History, Labels, & Expiration

Scenario 1: View Tag History

As a developer, I can view the history of tags for a specific image or repository. This will provide me with a detailed overview of all the tags associated with the image, including their creation dates and any changes made over time.

Scenario 2: Add and Manage Labels

As an administrator, I can add and manage labels for repositories. I should be able to categorize repositories using custom labels for easy identification and organization. Additionally, I can edit or remove labels as needed.

Scenario 3: Set Expiration for Tags

As a DevOps engineer, I can set expiration dates for certain tags in a repository. This feature will enable me to automate the cleanup of older or unused tags, keeping the repository clean and reducing storage space usage.

 

Settings & Permissions

Scenario 1: Repository Settings

As a repository owner, I can configure specific settings for my repositories. This includes defining access controls, setting default permissions, managing webhook configurations, and adjusting other repository-specific options to tailor the repository to my needs.

Scenario 2: Organization Permissions

As an organization administrator, I can manage the permissions and access control for all repositories within the organization. This involves setting default permissions for new repositories, managing team permissions, and overseeing user access levels.

 

 Robot Accounts

Scenario 1: Create Robot Account

As a developer, I can create a new robot account for automated tasks within the Quay system. During the creation process, I should be able to specify the robot's name, description, and access permissions. After creation, I should be able to manage the robot's permissions and roles.

Scenario 2: Manage Robot Account Access

As a DevOps engineer, I can manage robot account access to repositories. I can grant or revoke access permissions for robot accounts, ensuring secure and controlled interactions between robots and repositories.

Usage Logs

Scenarios:

• Monitor Team Activities: System administrators can monitor team-related activities, such as team creation, membership changes, and role assignments, through usage logs.
• Audit Tag History Actions: Security auditors can audit tag history actions, including tag creations, updates, and deletions, using the provided usage logs.
• Track Repository Label Changes: Repository owners can track changes to repository labels, including additions, modifications, and removals, via usage logs.
• Monitor Expiration Settings: DevOps engineers can monitor actions related to tag expiration settings, such as setting expiration dates or disabling expiration for specific tags, through usage logs

API V2: Design & Pagination

Scenario: Implement Pagination for API Responses

 Pagination should allow clients to fetch data in smaller chunks, reducing the server's load and improving response times for clients. The pagination design should be consistent with other Quay API v2 endpoints.

Dependencies (internal and external):

• Hybrid Application Console
• HAC Dynamic Plugins
• API migration from v1 to v2 works as intended 
• Team feedback on UI efforts and input from Quay.io users for feature parity assessment.

 Open questions:

1. What are the critical UI bugs that need to be addressed for achieving full parity and functionality? (Can we attach them here for tracking)