# GDPR Subject Requests: Data Access & Erasure > A register for GDPR access, erasure and portability requests: statutory deadline chased, identity verified, and a response package that opens. - **What it is:** A register for GDPR access, erasure and portability requests: statutory deadline chased, identity verified, and a response package that opens. - **For:** Extra Tools - **Odoo versions:** 16.0, 17.0, 18.0, 19.0, 20.0 - Community and Enterprise - **Runs on:** Odoo.sh or Odoo you host yourself - not Odoo Online, which accepts no third-party apps - **Price:** 199 EUR, one-time, on the Odoo Apps Store - **Technical name:** bambooforge_gdpr - **Not for:** The scan covers models with an email field. Data tied to a person only through a link — a delivery address on an order, a name in a note — is not found automatically.; Erasure and anonymisation are recorded here; performing them is done on the records themselves, with Odoo's privacy lookup or by hand.; One controller per company. Joint controllership arrangements are not modelled. - **Manual:** https://docs.bambooforge.dev/bambooforge_gdpr/ - **Live demo:** https://demo20.bambooforge.dev/odoo/action-bambooforge_gdpr.action_bf_gdpr_request - **Store page:** https://apps.odoo.com/apps/modules/20.0/bambooforge_gdpr - **Manual last updated:** 2026-09-21 --- # GDPR Subject Requests: Data Access & Erasure ## What this is for Odoo's privacy lookup finds records. It does not record that somebody asked, what they asked for, when the answer is legally due, whether their identity was checked, or what was actually done — which is the whole content of the file a supervisory authority asks to see. ## The clock One month from **receipt** under Art. 12(3) — not from the day somebody notices the email. The deadline is computed and shown as days remaining, and a request past it is flagged in red. An extension adds two further months and needs a written reason, because the person has to be told why within the first month. A second extension is refused: the article allows two extra months, not four. A daily job does two things with the clock. A week before the deadline it puts one to-do on the handler's list — one, not one per morning; the reminder is not repeated while the first is still open. And it flags any request that went past its deadline overnight, so the red mark does not wait for somebody to open the record. ## Identity first A request cannot be answered until identity is confirmed **and how it was checked is written down**. Handing somebody else's data to an impostor is itself a breach, and "we assumed it was them" is not a defence. ## Finding the data **Find Their Data** searches every model in this database that carries an email field, skipping transient models, the mail queue and log tables — they either disappear on their own or hold copies of what is found elsewhere. The search is case-insensitive; a blank email finds nothing rather than everything. Each hit becomes a line that must be given a decision: exported, anonymised, erased, or kept. The request will not be marked answered while any line is still undecided. Keeping a record against an erasure request needs the obligation stated on the line. Erasure is not absolute — but the reason has to be written down. ## The response **Build Response Package** produces a zip: an index of every record found and what happened to it, one readable JSON per exported record, and a cover note. Art. 15 says provide a copy; a letter saying "we hold some data about you" is not one. Binary fields are left out on purpose. A data export is meant to be read by the person who asked, and base64 blobs are neither readable nor what they asked for. ## Refusing A refusal needs the exemption stated. A refusal with no ground is the single thing supervisory authorities pick up every time. ## Known limits - The scan covers models with an email field. Data tied to a person only through a link — a delivery address on an order, a name in a note — is not found automatically. - Erasure and anonymisation are recorded here; performing them is done on the records themselves, with Odoo's privacy lookup or by hand. - One controller per company. Joint controllership arrangements are not modelled. ## How we make sure it works Before every release, **28 automated checks** run against this app on Odoo 16, 17, 18, 19 and 20. Among them: - Identity cannot be confirmed without saying how. - A package cannot be built before scanning. - Scanning twice does not duplicate. - A request with no email finds nothing rather than everything. - A plain employee does not see the menu. The complete list is in the source you receive. ## Install 1. Copy `bambooforge_gdpr` into your addons path and update the app list, or install the ZIP from the Odoo Apps Store. 2. Install **GDPR Subject Requests: Data Access & Erasure**. 3. Open **Data Protection** - its menus are Subject Requests. ## Questions people ask ****Which Odoo versions does it run on?**** Odoo 16.0, 17.0, 18.0, 19.0, 20.0, on the series you buy it for; each series is its own listing. ****Community or Enterprise?**** Both. It needs no Enterprise app. ****What does it need?**** The standard Discuss, Settings apps. No extra Python package. ****Where does it show up?**** Under the **Data Protection** menu (Subject Requests). ****Does anything leave my server?**** No. It makes no call outside your Odoo server: no telemetry, no licence check, no third-party service. ****What happens if I uninstall it?**** Odoo drops the app's own tables and fields; the standard records it worked on (contacts, orders, products) stay as they are.