Skip to content

New Admin UI

Jump to bottom
Arlen Beiler edited this page May 3, 2025 · 4 revisions

Trying to think through a better layout for the admin UI. Also need to consider whether I should have it be under an /admin route and consider a path-based recipe layout.

I'm visualizing the WordPress UI as I'm writing this.

  • Content
    • Recipes
    • Bags
    • Pages
  • Users
    • Users
    • Roles
    • Profile
  • Settings
    • MWS Config
    • Secrets management
    • Plugins

Settings

Main site settings

  • Home page: Admin UI or a specific wiki.
  • Attachment System - Save large text fields to the file system or an object store service like S3.
  • Request compression and caching - The server calculates a hash and can use it to return 304 Not Modified.

Security settings

  • Anon (not logged in) permissions: Allow read or write.
  • Whether admin's have automatic read & write permissions or must add themselves to the ACL first, owned vs un-owned.
  • Whether a user is given access to a recipe if they don't have permission on the bags of that recipe (depends on which one results in more end-user confusion, and is going to vary on case-by-case basis).

More settings groups

  • Revision History (enable + settings) (coming eventually, hopefully)
  • Authentication module (password min length, configure third-party connections, SSO)

Things we can't put in settings.

  • Not listeners. Certainly not SSL Certs. That has to stay on the command line.
  • Not the wiki path. You can't store the path to the database in the database itself.
  • Private keys: The password master key and SSL certs and keys have to be controlled by the server owner.
  • URL path prefix: Generally you won't be changing this unless you're already doing advanced JavaScript stuff. And it's guaranteed to break web access if you make a mistake, requiring a CLI intervention to reverse it, so it might as well just stay in the CLI.
Clone this wiki locally