guest role; guide section ticking
This commit is contained in:
40
CHANGELOG.md
40
CHANGELOG.md
@@ -12,6 +12,46 @@ ADR-007 and ADR-002.
|
||||
|
||||
### Added
|
||||
|
||||
- **A guide's sections can be ticked off while you read it.** Only checklist
|
||||
items were tickable, which answered "what have I done" but not the question a
|
||||
long procedure actually raises - where was I. Somebody looks away to do the
|
||||
thing the guide asked for and looks back at a wall of text. Every step and
|
||||
every heading now carries a checkbox in the reader; ticking one strikes it
|
||||
through and fades it rather than hiding it, because scanning back up the page
|
||||
has to still show what was done. Headings count as well as steps: a guide
|
||||
converted from an HTML article often has fifty headings and no steps at all.
|
||||
Progress is per browser and per version, as it already was for checklists -
|
||||
shopfloor PCs share a login, so one technician's ticks must not greet the
|
||||
next person on that bay.
|
||||
|
||||
- **A guest is a role now, not a switch per feature.** Whether somebody with no
|
||||
account may see something was answered one feature at a time: a
|
||||
`securesend_allow_guests` setting, an enable flag per kiosk, and very nearly a
|
||||
third for guides - each with its own settings page and its own hand-written
|
||||
branch inside a route. It is a permissions question, and this app already
|
||||
administers permissions per role, so anyone not signed in now holds the
|
||||
seeded `guest` role. It starts with nothing, so an upgrade opens no door; a
|
||||
site opens one by ticking a box in the same role grid it uses for everybody
|
||||
else, and closes it the same way - taking effect on the next request, not the
|
||||
next restart. `require_permission` consults the role when there is no token,
|
||||
which is the whole mechanism.
|
||||
|
||||
What a guest may be granted is bounded: any `.view` or `.read` permission,
|
||||
plus writes a plugin has explicitly declared safe to perform without an
|
||||
account (`get_guest_grantable_permissions`, contract 0.21.0). Secure Send
|
||||
declares its create permission, because sending a password to a vendor is the
|
||||
one write the product means to offer somebody who never signs in. Everything
|
||||
else is refused by the API and greyed out in the grid rather than warned
|
||||
about. A guest write records no creator - the audit trail can say when and
|
||||
from where, never who - and that is the reason for the bar.
|
||||
|
||||
GE-Enforce and Slides gained read permissions (`geenforce.view`,
|
||||
`slides.view`) so they can be opened to guests without handing out the manage
|
||||
right; their read routes accept either, so nothing an existing manager could
|
||||
reach has moved. The navigation endpoint now returns only what the caller can
|
||||
actually reach, so a signed-out visitor sees the pages that were opened to
|
||||
them rather than a sidebar of links that bounce off a login page.
|
||||
|
||||
- **USB check-in / check-out audit report.** CMMC removable-media tracking is an
|
||||
audit obligation and there was no report for it - answering "who had this
|
||||
drive, and when" meant paging through the check-in/out list by hand. The
|
||||
|
||||
Reference in New Issue
Block a user