MammothWP Acceptance Logs

No, and the distinction drives the whole design. Accepting Terms & Conditions is an access-control and contractual-compliance mechanism resting on Art. 6(1)(b) and 6(1)(f) GDPR, not consent under Art. 6(1)(a). Practically: acceptance is not withdrawable in the Art. 7(3) sense, and records are not deleted on request. If you need cookie consent, you need a different plugin — run both.

Until you choose, every role. The plugin does not guess a safe subset, and picking the roles is step 3 of the setup for that reason. Settings → Terms & Conditions lists every role on the site.

No. The popup has a "skip for now" button, and a user who clicks it keeps working. Skipping is not recorded as an acceptance or a decline: it only hides the popup for that user for 12 hours (filterable with mmwp_terms_skip_duration) and fires the mmwp_terms_skipped action; nothing is written to the acceptance log or audit events. What persists is a non-dismissable notice on every wp-admin screen, shown only to logged-in users in scope who have not accepted the current version, until they accept. It is a prompt with no exit, not a wall — a hard lockout risks stranding an administrator who needs the backend to fix the terms.

Editing and publishing creates a new version with the next sequential number, archives the full text permanently, and re-prompts everyone in scope. Previous versions are never deleted, and republishing earlier text is a new publication with a new number rather than a silent return to an old one — so "revert the text and everyone counts as accepted again" cannot happen. Changing the text without publishing changes nothing. The daily cron only picks up changes made through a content source that bypasses the settings screen.

No. The record is evidence that a particular version was accepted at a particular moment; that fact does not stop being true. A user who does not want to accept can only skip the popup for now; that is not recorded (see above), and the acceptance prompt returns until they accept.

Through WordPress's own Tools → Erase Personal Data — the plugin registers an eraser. It returns the acceptance records as retained, with the reasoning shown to the requester rather than applied silently, and erases the context (IP, User-Agent) of any record already past its retention period. Art. 17(3)(b) and (e) disapply the right to erasure where processing is necessary for legal claims, which is what proof of acceptance is. See the retention policy document in the plugin repository.

Records live while the account exists, plus a dispute period defaulting to five years, after which the IP address, IP source and User-Agent are erased and the record is retained in anonymised form. Records are anonymised, never deleted. Published versions of the terms are never deleted at all — an acceptance whose text cannot be reproduced proves almost nothing.

Access is an explicit list of user accounts, not a capability. That is deliberate: manage_options gets handed out liberally by role plugins and during onboarding, and the log is evidence about other people. Whoever activated the plugin is the first manager and can appoint others; the last manager cannot be removed.

No, by design. There is no update or delete path in the code and no edit or delete affordance in the admin. If a record is wrong, the answer is a new record plus an audit event. Their absence is the control, not an oversight.

Yes, but configure the trusted proxies first or the audit log records the proxy's address instead of the visitor's. Return your proxy's address or CIDR range from the mmwp_terms_trusted_proxies filter. Forwarded IP headers are ignored by default because trusting them unconditionally would let any client write its own address into the log.

Each site gets its own tables and settings, so activate it per site. Network activation is not supported: the tables are created for the site the activation runs on, not for every site in the network.

Users → Terms acceptance log, which shows every record with its integrity and delivery status, filterable, with CSV export and an on-demand integrity check. the evidence-handling document in the plugin repository covers the procedure, what the evidence actually shows, and the limitations you should disclose alongside it.

Per acceptance: user ID, login and e-mail as they were at the time, the version accepted, UTC and local timestamps with timezone, the site identifier, IP address (and how it was determined), User-Agent and cryptographic signatures. Three user-meta markers record the version each user accepted. No fingerprinting, MAC address or geolocation is collected.

Yes. It registers a personal-data exporter and eraser (wp_privacy_personal_data_exporters, wp_privacy_personal_data_erasers) and adds suggested text to the Privacy Policy guide with wp_add_privacy_policy_content().

No. There are no remote calls, no CDN assets, no update checks and no telemetry. The bundled Support screen (Mammoth WP > Support) sends one e-mail through wp_mail() to info@mammothwp.com, only when an administrator presses Send. A site report is attached only if they tick "Include site report" after previewing exactly what it contains.

By default the acceptance evidence is kept. When you click Delete on the Plugins screen, a dialog asks whether to keep the acceptance evidence (recommended) or delete it permanently; deleting requires typing the plugin name. Either way the plugin's settings, scheduled tasks and options are removed. If you keep the evidence, the log, the version archive, the audit events, the per-user acceptance markers and the signing key stay in your database, so they can still be verified later. You can change the choice at any time under Settings > Terms & Conditions, or purge the evidence immediately with wp mmwp terms purge (it only reports what exists; add --force to delete, --dry-run to never delete). Developers can override the choice with the mmwp_terms_drop_data_on_uninstall filter.

Yes: REST (mmwp/v1/terms/...), WP-CLI (wp mmwp terms ...) and the Abilities API, all declared once. Reading the acceptance log over any of them requires being a plugin manager and returns a redacted shape (no IP address, User-Agent or e-mail).