Understand access rights, record rules, user devices, and privacy tools

Every row grants a Group up to four permissions on a Model: Read Access, Write Access, Create Access, Delete Access. The list is inline-editable at the top, and the form warns you plainly: "Please note that modifications will be applied for all users of the specified group".

The semantics are the part worth memorising: access rights are purely additive. If any one of a user's groups has the permission, the user has it — there is no "deny" row, and a row with all four boxes unticked grants nothing but blocks nothing. A row with an empty Group column applies to everyone including portal users, which is why the list paints such rows warning-yellow. And the absence of any row for a model means nobody (except the superuser) can touch it — no rule means denied, not open.

A user who runs into the limit sees the standard refusal — "You are not allowed to access '…' records." followed by either the list of groups that would allow it or "No group currently allows this operation." — which tells you exactly which group to grant. Rows can be archived (Active off) to disable them without deleting; a deleted shipped row comes back on the next module upgrade.

Where access rights answer "may this user open sales orders at all", record rules answer "which sales orders". A rule attaches a domain filter to a model for one operation or more (Read, Write, Create, Delete — here ticked by default, and an unticked box means the rule simply does not apply to that operation). The form's sections say the rest: Rule Definition (Domain Filter) holds the filter, and Groups (no group = global) decides who it binds.

The combination algorithm is printed on the form itself, and it is the opposite of access rights: "Global rules (non group-specific) are restrictions, and cannot be bypassed. Group-specific rules grant additional permissions, but are constrained within the bounds of global ones." Concretely: all global rules are AND-ed together — every one must pass — while all group rules of the user's groups are OR-ed, so any one of them is enough within what the global rules allow. The form even shows the formula: GLOBAL_RULE_1 AND GLOBAL_RULE_2 AND ( (GROUP_A_RULE_1 OR GROUP_A_RULE_2) OR (GROUP_B_RULE_1 OR GROUP_B_RULE_2) ). A model with no rules at all is unrestricted — again the mirror image of access rights, where no row means no access.

A user filtered out by a rule gets the famous refusal starting "Uh-oh! Looks like you have stumbled upon some top-secret records." — with developer mode active it also names the offending records and lists "Blame the following rules:", which is the fastest way to debug a "record disappeared" report. Two guards while editing: a rule must keep at least one operation ticked ("Rule must have at least one checked access right!"), and a rule cannot target the Record Rules model itself.

Every authenticated session shows up here, one card per user, platform, browser and IP, with first and last activity, GeoIP country and city, and a green dot on your current device. The screen is read-only by construction — rows appear automatically and Last Activity refreshes at most hourly, so do not expect a to-the-minute view.

The one action is real: Log out (the list view labels it Revoke) first asks you to re-enter your own password in the Access Control dialog, then deletes that session on the server — the kicked user's very next request lands on the login page. This is the button for a lost laptop or a departed employee's forgotten browser. Users can do the same for their own sessions from the Security tab of their profile, where Log out from all devices ends everything except the session pressing the button; the same tab holds their password change, two-factor authentication and API keys.

The Privacy Logs menu is only the paper trail; the tool that writes it has no menu of its own. To act on a person's data, open their Contact or user form and pick Privacy Lookup from the ⚙ Actions menu. The wizard searches the whole database for the name and email — contacts, users, messages they authored, and every model that stores an email or points at the contact — and lists the hits as References, grouped by model. On each line a toggle archives or unarchives the record immediately, and a Delete button removes it for good after the warning "This operation is irreversible. Do you wish to proceed to the record deletion?".

A log row is written only when a lookup actually archives or deletes something — browsing alone records nothing, so an empty list is normal. The log deliberately stores the subject's identity masked (J*** D**, j***@d*****.com) with the acting user, the date, and one line per action taken. Rows cannot be created by hand.