This thing https://tools.taskcluster.net/auth/scopes/expansions

This view is synonymous with https://tools.taskcluster.net/secrets/garbage%2Fcag%2Ftestsecret. It should be pre-filled when loading an existing secret, and empty when creating. I know right now we have a view-only mode for showing/hiding the secret value, but we can incorporate this into the form view, which should be the only view.

In the currently documentation structure, docs are in a separate repo on a separate domain, and its settings are managed independently from taskcluster-web. Let's bring those into this repository, still rendered with Markdown, at the /docs endpoint.

This view is synonymous with https://tools.taskcluster.net/aws-provisioner/ami-test/. It would be nice if we could display all metadata necessary for rendering this into different cards in a single query. We may be able to put the definition into an expandable list item similar to what we do for tasks, but I'm not sure. Editing the definition should not be handled in this view.

This view is synonymous with https://tools.taskcluster.net/quickstart. All the help content is not going to be there, since that will be taken care of in the view help feature. Really need some UX scrutiny on this page.

This view is synonymous with https://tools.taskcluster.net/provisioners/aws-provisioner-v1/worker-types/gecko-1-images/workers/us-east-1/i-02ca4d161f8d5c3d9. It is concerned with rendering the metadata for a given worker, and its actions. It is not concerned about taking actions on its related tasks.

This page is synonymous with https://tools.taskcluster.net/aws-provisioner. I'm still not a fan of giving the AWS provisioner a special page over other provisioners, but it is what it is. This view is only concerned with the data and actions of the provisioner itself, and is not concerned with individual worker types, their actions, creating worker types, recent errors or health. Those may be linked, but they will not render in this view.

Every view navigation should register an analytics event.

This view is synonymous with https://tools.taskcluster.net/pulse-inspector. This should utilize the GraphQL message subscription available on the top-level Subscription.

In addition to the dark theme, we can put a preference in the user's profile (which maybe we could rename to settings, not sure), to toggle between a light and dark theme.

This view is synonymous with the list at https://tools.taskcluster.net/secrets. It is not concerned with displaying individual secrets, but will link to existing ones, or creating them.

Should contain responsive menu system along with near-full-height view content.

This will involve making a login mutation to the service, based on either an OIDC flow or manual credentials.

Each page could contain important information for the new user of a particular view, but often doesn't warrant needing to be shown every time. Let's put a help icon in the app bar to show help, perhaps in a dialog or right drawer, showing help for a page.

This view is synonymous with https://tools.taskcluster.net/aws-provisioner/create:worker-type/.

Right now this could be considered synonymous with the page at https://tools.taskcluster.net/credentials. I'd like to make the page specific to the user, so they can manage credentials, clear/view local/remote preferences, etc.

This view is synonymous with the list at https://tools.taskcluster.net/auth/scopes. I'm not sure if the API supports pagination of this endpoint, but worst-case we can paginate it client side. The list displayed here may also be expandable panels instead of a table so we can drill into the clients.

This is synonymous with the task actions you can take at https://tools.taskcluster.net/groups/e4MvyI2FSjqEmLjZ1mUbYw/tasks/S02Aav_PSJOvbQSopKYVyw/details

My initial instinct is to use a speed dial here, although I'm not sure how that's going to look with 14 different actions. We may resort to a drop-up instead with a FAB. We may also consider dropping actions that can't be taken, e.g. disabled actions.

This is the view that is rendered when visiting / when logged in. We could show a list of recent tasks, some guidance to view their profile, or anything else really.

We have decided that the initial theme is going to be a dark theme. We will address a toggleable light theme in #50.

I hate to bake in specific providers, but for Mozilla Taskcluster production we want to capture errors using Sentry.

When visiting the /tasks view without a task ID, let's display a list of recent tasks the user has viewed.

This page is synonymous with https://tools.taskcluster.net/groups/e4MvyI2FSjqEmLjZ1mUbYw/tasks/S02Aav_PSJOvbQSopKYVyw/runs/0/logs/public%2Flogs%2Flive.log, but unlike static logs, it is only concerned for rendering streaming logs. It's associated actions currently include:

• Go to line
• Link to task
• Link to raw log
• Follow log

This is synonymous with https://tools.taskcluster.net/auth/scopes/assume%3A*/role:mozilla-group%3Ateam_taskcluster. We are only going to show the edit form, no need for the view-only mode.

This view is synonymous with https://tools.taskcluster.net/tasks/create. This also needs to take of creating tasks based on a task definition, synonymous with https://tools.taskcluster.net/tasks/JjZoye8zSSadEwUu_FPSkg/create. This does not concern interactive tasks. It may be nice to have a button on the page that can toggle between making the task interactive or not.

The individual search boxes in each view are only meant to search for the parameters necessary to render that view, and are duplicated in every view. Let's create a global search component that goes into the app bar, and can search across many types: tasks, task groups, docs, and more. This can be pattern-based, so a string matching a task ID could show an autocomplete to link to either a task or a task group, etc.

This feature gives third parties the ability to extend the UI with their own views. This would probably be configured at some kind of cluster level, which would install a dependencies and provide metadata about the customization. Initial thoughts we are experimenting with in the MVP:

• Each customization will either be a React component, or a function that returns a React component.
• The customization needs to be pluggable as an npm package, by providing a valid package.json to make it importable at the default export.
• Each customization should provide additional metadata via its package.json at a yet-unknown but well-known property. At a minimum, this would include the route pattern at which to render the customization, as well as a name to show in the navigation sidebar, title bar, app bar, etc.

What is unknown yet is how this can be integrated into a view, and that will drive whether a customization is a function or a component. The main concern lies around the Dashboard component, which handles a lot of view rendering logic for every authenticated view. Should a customization import the Dashboard and render it itself, like all the other views do? At first glance, I would think not. If not, then how do we handle some of the props needed by the Dashboard component? This needs to be solved.

In order to realize the goal of much more efficient views, standard pagination, filtering, subscriptions, etc., we want to use GraphQL with Apollo over taskcluster-client-web. This will significantly reduce the data burden on the UI.

This task does not entail any server-side work, rather just the Apollo and GraphQL bits for the client to make authenticated and unauthenticated queries, mutations, and subscriptions.

This view is synonymous with https://tools.taskcluster.net/provisioners/aws-provisioner-v1/worker-types/gecko-1-images. It is concerned with displaying the metadata for a worker type, and its actions. It is not concerned with individual workers, nor their actions.

This view is synonymous with https://tools.taskcluster.net/auth/roles/hook-id%3Agarbage%2F*. This should display a form with either a blank role or the loaded role. I don't want a toggle between viewing and editing; let's always show the form.

This view is synonymous with https://tools.taskcluster.net/aws-provisioner/ami-test/edit.

This page is synonymous with https://tools.taskcluster.net/groups/e4MvyI2FSjqEmLjZ1mUbYw/tasks/S02Aav_PSJOvbQSopKYVyw/runs/0/logs/public%2Flogs%2Flive.log. It is only concerned for rendering static logs that are not streaming, and its associated actions, like:

• Go to line
• Link to task
• Link to raw log

This view is synonymous with https://tools.taskcluster.net/provisioners/aws-provisioner-v1/worker-types. It is concerned with rendering a list of worker types for a particular provisioner. It is also concerned with the actions you can take on a list of worker types. It is not concerned with an individual worker type nor its actions.

This view is synonymous with https://tools.taskcluster.net/hooks. We are only concerned with the list of hooks here, not an individual hook.

This view is synonymous with https://tools.taskcluster.net/tasks/JjZoye8zSSadEwUu_FPSkg/interactive. Basically any task ID following this route will do a look-up for its task definition, use that as the editor content, with overrides for interactive properties.

This view is synonymous with the roles list at https://tools.taskcluster.net/auth/roles. It is not concerned with editing or creating individual roles, but may link to those views.

This view is somewhat synonymous with https://tools.taskcluster.net/auth/clients/email%2Fbastien%40nextcairn.com%2Ftc-notify-test, but should handle new clients with a blank form. I don't want a toggle between view/edit mode. Let's always keep it in edit/form mode.

This view is synonymous with https://tools.taskcluster.net/hooks/garbage/12345. We should show a pre-filled form when loading an existing hook, and blank when creating a new hook. No need for a view-only mode, just the form view.

This view is synonymous with https://tools.taskcluster.net/purge-caches. The view layout should be the list, with a button to start a new cache purge. The cache purge form should not be always visible; instead we could probably use a dialog form when clicking the button.

This view is synonymous with the list of clients at https://tools.taskcluster.net/auth/clients. It is not concerned with creating or editing clients, but may link to those respective pages.

Every interaction, like button clicks, should register an analytics event. We will probably have to encapsulate this our own button components.

This view is synonymous with https://tools.taskcluster.net/auth/grants. I'm thinking a card layout, where each card can have actions to delete the grant.

This view is synonymous with https://tools.taskcluster.net/index. I hate the UX on this page, so we need some thought here on how to make it better. Maybe a stepper wizard or something. 🤷‍♂️

This is the view that is rendered when visiting / when not logged in. The point of this page will be mostly informational in nature, encouraging the visitor to log in.

This is the view synonymous with https://tools.taskcluster.net/provisioners. This is only concerned about the list of provisioners, and not an individual provisioner.

This view is synonymous with https://tools.taskcluster.net/aws-provisioner/aws-health.

See also:

taskcluster/taskcluster-tools#518
taskcluster/taskcluster-auth#148

This view is synonymous with https://tools.taskcluster.net/aws-provisioner/recent-errors.

This page is synonymous with https://tools.taskcluster.net/groups/e4MvyI2FSjqEmLjZ1mUbYw. In order to address UX concerns, this view will no longer be unified with viewing tasks; it is only concerned about the group itself and its actions.

The task group will be paginated, most likely in pages of 100 tasks. We will also do a server-side filter if specified, and we are aware that this will initially lead to inconsistent page sizes.

This should fix:

• taskcluster/taskcluster-tools#271
• taskcluster/taskcluster-tools#353
• taskcluster/taskcluster-tools#285
• taskcluster/taskcluster-tools#284

This issue should also involve the GraphQL task subscription.