Security model
What Customer Payment Reminders can read and write, what it stores, and what leaves your instance.
Two groups
Settings → Users & Companies → Users → (user) → Payment Reminders.
| Group | Can |
|---|---|
| Credit Controller | See who is overdue, read the levels, send reminders, pause a customer with a reason, add to the history |
| Credit Manager | Everything above, plus edit and create reminder levels, tick Never Chase, and delete history |
Credit Manager implies Credit Controller. A user with neither sees nothing this module adds — no menu, no tab on the customer form, no history.
The split is the point. Sending a reminder is an everyday job. Changing the escalation changes what every customer receives, and permanently excluding an account means somebody stops being chased and nobody notices. Those are different decisions and different people.
Access rights
| Model | Controller | Manager |
|---|---|---|
| account.reminder.level | read | read, write, create, delete |
| account.reminder.log | read, write, create | read, write, create, delete |
| account.reminder.send (wizard) | full | full |
A controller cannot delete history. Being able to send a reminder and then erase the record of having sent it defeats the purpose of keeping one.
Record rules
Two global rules scope both levels and history by company:
['|', ('company_id', '=', False), ('company_id', 'in', company_ids)]A user sees records belonging to their active companies, plus the shared ones that have no company. Global rules apply to every group including managers, and they are enforced by the ORM, so they hold for the interface, exports and the external API alike.
What the module writes
To your data, almost nothing:
| Record | What is written |
|---|---|
| res.partner | The pause, exclusion, responsible user, and — after a send — the last level and date |
| account.move | Nothing on the invoice row. The link between a reminder and the invoices it chased is stored on the reminder's side; the three other fields added to the invoice are computed and unstored |
| mail.activity | An ordinary Odoo activity, when a level asks for one |
| mail.mail | The reminder itself, through your own mail server |
Invoices are never modified. Not their state, not their payment state, not their due date. The module reads them.
The two fields it writes to the customer after a send — the level and the date — are the module's own bookkeeping, and are written with elevated rights. That is deliberate: a Credit Controller must be able to record that they sent a reminder without also holding the right to edit contact records. What the user is actually doing stays under their own rights; only the bookkeeping is elevated.
What is sent outside
One thing: the reminder email, to the customer's invoicing contact, through the mail server you configured. There is no external service, no telemetry, no activation key and no outbound connection of any other kind.
If a level attaches invoices, it attaches the PDF Odoo has already generated for that invoice. Nothing new is rendered and nothing is uploaded anywhere.
Personal data
The module stores, per reminder: which customer, which level, the date, the recipient contact, the invoices chased, the amount at the time, and which user sent it. That is the minimum needed to answer "what did we tell them, and when" — which is the question a payment dispute turns on.
History is pruned automatically after three years. To keep it for a different period, change the Prune History scheduled action.
For a subject access or erasure request, a customer's history is on their Payment Reminders tab and a Credit Manager can delete it. Deleting history does not touch the invoices, and does not un-send anything.
Reporting a vulnerability
Email info@technovision.dev. Please include the Odoo version, the module version, and enough detail to reproduce it. Security reports are answered before feature requests.