Menu structure

This page governs the menu in the header of the shell, the cards on each area page, and the breadcrumb of every screen. A card on Home is a shortcut to a screen and is not a second home for it.

The Entity screen specification and the Record screen standard already say that a breadcrumb is Home, the area, the list, then the subject, and that the menu offers an entry by the narrowest read the screen needs. This page names the areas and says which screen belongs to which.

A card is like an entry in a file manager.

• A folder card opens a page of cards. The areas are folders. A folder card has the name of its area and a line about what is in it.
• An area may hold a folder card of its own when a topic inside it has several screens that belong together: Synthetic, in Market data. Its page follows the rule of an area page, and its name is the topic, never one kind of record. A folder holds screens, not other folders. Synthetic is the only folder inside an area today; another is added here first, with the topic it holds.
• A file card opens one screen. Its title is the title of the screen, word for word, in English, French and Portuguese. Its line is a short form of the screen's own lead. It has the glyph of the screen.

A screen has one definition of its card (shell/cards.ts). The area page and Home both draw from it, so a screen has the same name, line and glyph wherever it is offered. A screen that has no header of its own, such as a journey, takes its title, its line and its trail from its file card (CardScreen). A test holds the card title and the screen title equal in every language.

Home's Active modules tab shows one folder card for each area the person is offered, in the order of the menu, and then the cards of their own account. It does not repeat the file cards of the areas. A person opens a folder to reach its screens.

• The menu is one list, in one order. It has no version for a mode, a role or a kind of user.
• An area is drawn when the person holds the read that any one of its screens needs. If the person holds none, the area is not drawn. It is not disabled.
• An area page shows the same cards to everyone. A card is drawn when the person holds the read of its screen. If they do not, the card is not drawn.
• No area, card or screen is named for a role. A role is a set of permissions that changes. The screen names the read it needs, and the read decides.
• A new screen is added to the area it belongs to. It then appears for every person who holds its read, with no change to the menu.
• The breadcrumb of a screen is Home, then its area, then the screen. A screen in a folder of the area has the folder between the area and the screen. A record page adds the list and the subject, as the entity specification says.
• A screen has one area. A card on Home or in another area leads to it, and the screen still shows the trail of its own area.

The menu had seven entries, and they were of three different kinds.

• Some were a kind of record: Parties.
• Some were a body of data: Reference data.
• Some were a question the person asks: Requests, Operations.

A person cannot guess where a screen is when the entries answer different questions. Parties was drawn beside Reference data, but the party journeys are reference data: a party is made of identifiers, contacts, countries, currencies and business centres, all of which are reference data. So a person who looked in Reference data for a party did not find it.

Four other faults made it worse.

• The same screen had two addresses, such as /classifications and /refdata/classifications, and /hierarchy and /reporting-lines.
• Home repeated the screens as cards with other names, so one screen had two labels.
• A person's own pages (/access, /where-i-work, /profile, /security) were mixed with the pages about other people.
• Some areas were named for a record kind and others for a topic, so the menu had no one rule for what an entry is.

An area is a topic that a person goes to, and its name is the journey group that User Journeys uses for it. It is never one kind of record. A kind of record is a card inside the area whose topic it belongs to.

The test for a screen is one question: which topic would a person look in?

Home   Reference data   Organisation   Market data   Trades   Requests   Operations   Reporting   Development   Tenants

Requests is the one entry that is not a topic. It is an inbox: the work that waits for a person, with the notification bell beside it. It is not in Operations, which says how the system is running, and not in Organisation, because four-eyes approval will cover reference data as well as access. Every person has their own requests, so the entry is drawn for everyone.

Tenants is last because it serves only the installation, and it is drawn only for a person who holds the read of the deployment (see The deployment read).

The account menu stands in the header with the notification bell. It holds My profile, My access, Where I work, Security and signing out. These are not areas. A person reaches each in one place, as the entity specification says. Each has a breadcrumb of Home, then the page, because it belongs to no area.

Every screen has a breadcrumb. Home is the one page without one, because it is the first step of every trail.

A screen is under the address of its area, so the address and the breadcrumb say the same thing. A screen has one address.

The earlier addresses (/parties, /people, /hierarchy, /staff, /roles, /rescue, /audit, /classifications, /reporting-lines) redirect to the new ones, so a saved link still works.

Some screens read the installation as a whole, across every tenant: Tenants, and the Running services, Compute grid, Message bus and Telemetry logs cards of Operations. They are drawn, and the server serves them, for a person who holds installation::deployment:read. The session mode is not consulted.

• The code is in the installation component. The wildcard * does not cover an installation code, because a tenant's administrator holds * and would then see the installation. Only the code itself, or installation::*, grants one. The rule is stated once for the services (grants in ores.security) and once for the browser and the BFF (permissionCovers in @ores/contracts).
• The super administrator role holds the code by name. Another role is given it the same way, and a person asks for that role through a request.
• The BFF reads the caller's roles for each call and refuses a caller who does not hold the code. A grant the caller lost stops the next read.

The menu, the cards, the addresses and the breadcrumbs follow this page. Synthetic is one screen with a Dashboard and a Feed tree at the addresses above. A feed's page has the trail Home, Market data, Synthetic, Feed tree, the folders down to the feed, then the feed.

The Trades area has its first screen: the trade list at /trades, read through the BFF's trading route and the trade summary read model. It is drawn for a person who holds the reads it needs. Structures and packages, the trade page and Book a trade follow, and the area becomes a page of cards when the second screen exists, as every other area is.

Market data has no screen for curve surfaces or for feeds of other kinds yet. They are added to the Market data area when they have screens; a feed of a new kind joins the Feed tree.

The Synthetic screen, with its Dashboard and its Feed tree, is designed in the Synthetic feeds prototype and built by the tasks of Organise feeds by provider and scope.

Work in this order. Each step ends in something to check.

1. Name the screen and the narrowest read it needs.
2. Choose its one area by asking which topic a person would look in. If none fits, add the topic here first. Never add an area for one kind of record.
3. Add the screen to the area page as a card, drawn only for a person who holds the read.
4. Give the screen a breadcrumb of Home, the area and the screen, with the folder between when the screen is in a folder of the area.
5. Run the walk, shell/walk.test.tsx. It opens every screen of the cards, every area page and each page of a person themselves, and checks the address is under its area and the trail is Home, the area, the screen. A route the walk does not know fails it.
6. Check it with a person who holds the read and a person who does not. The first sees the card. The second sees neither the card nor, when it was the only one, the area.