Member settings and folders

Per-member settings

MemberSetting is a store of preferences that belong to one member. A setting has a type and a default, and its value is kept per member, so a site can offer each member their own choices without every module inventing its own preferences table. As with the identity data on the Identity and verification page, values are added rather than overwritten, so the latest entry for a given setting is its current value and the earlier ones are its history.

Declaring settings

A site does not get a fixed list of settings; each module registers the settings it owns through the module's configuration class. A setting is declared with its identity (the module, a category and a name), its type, a default and a label, so the module knows how to store and display it. Grouping settings into categories lets a member's preferences screen show one section per category. This is the usual configuration-class split: MemberSettingConfig is where a site declares what settings exist, and the runtime side reads and writes their values. See Config classes. The MemberSettingAdmin submodule adds the operator view of members' settings, following Building an admin system.

The member folder tree

MemberFolder gives each member a tree of folders. It owns only the folder structure: a folder has a name, a single parent, a position among its siblings, and belongs to one member. Folders nest by pointing at their parent, with a member's top-level folders sitting under a notional root; there is no separate nesting table, just the parent link, which keeps the tree simple to reason about and to move around. Ownership is re-checked on every operation, a folder can never become its own ancestor, and deleting a folder soft-deletes its whole sub-tree.

What goes in the folders

Crucially, MemberFolder does not store what is inside a folder. It owns the tree; the things filed into it stay in whichever module owns them. A module that wants its rows to be filable declares a folder type and gives MemberFolder the callbacks to count and render its own content, then keeps a folder reference on its own rows. That way one folder tree can hold several different kinds of thing, each still owned and rendered by its home module, which is the loose-coupling and no-cross-module-joins approach from Loose coupling and extension applied to a shared structure. The full model, including how a folder type is declared and how content callbacks work, is set out on the MemberFolder module reference.

Browsing and editing folders

The MemberFolder module renders the folder pages a member browses, showing a folder's sub-folders and its filed contents a page at a time. Two submodules sit beside it: MemberFolderAdmin gives operators a view across every member's folders, and MemberFolderApi exposes the tree operations (list children, walk the path, create, rename, move and delete) as a member-scoped JSON API for interactive front ends. The API takes the acting member from the session rather than the request, so a member can only ever touch their own tree; the The Api layer page covers how such endpoints are declared.

Next: Payments and subscriptions.