The identity model

01 Person, user and author A person is the human and their contact details, a user is the login, and an author is an editorial byline. Keeping the three apart from the first day avoids data that is expensive to move later. What each holds, how a member and an editor are made of them, and the current user in a template.

02 Members and backend users A user's type decides whether they are a member of the website or a backend user of the admin and the API. The five types, what each may do, the checks that keep a member out of the admin and the API, and how to confirm the separation on a site you have inherited.

03 Groups and permissions Groups are named sets of people; permissions say what a user, a group or everyone may do with a module, an entity type or one record. How the layers combine when a member asks for a record, why groups suit access by role, and why access per record belongs in the data model instead.

04 Profile data: custom fields or a related record Custom fields on the person cover most member profile data; a related record is right when the data repeats or has a life of its own. The rule for choosing, a worked case for each, the profile route that lets members edit their own details, and what that means for anything that grants access.

05 Addresses and the address book A person keeps an address book: any number of addresses, each with an address type and one marked primary. The model, the address types, the screens a member manages it with, rendering it in the member area, and how orders and checkouts use a saved address without linking to it.

Objects ReferenceGenerated from the platform, so it is always current

API ReferenceEvery REST endpoint, in cURL, PHP, Python and JavaScript

In this unit