CE Phoenix Cart Forum

Covered in Phoenix Cart core:

1. Privacy Policy → Info pages.
3. Right to Access → Built-in customer data export.
4. Right to Rectification → Customers and admins can edit data.
5. Right to Erasure → Built-in deletion for compliance.
7. Right to Data Portability → Built-in structured export.
8. Right to Object → Newsletter unsubscribe.
13. Secure Data Handling → HTTPS, password hashing.

Not applicable (Phoenix core has essential cookies only):

2. Consent Management
15. Cookie Policy (only simple disclosure in Privacy Policy needed)

Partially covered:

12. Data Minimization & Retention Policy → Needs automated purge of old accounts/orders.

Not covered:

6. Right to Restrict Processing [ https://github.com/CE-PhoenixCart/Phoen ... b7e981d7d7 ]
9. Automated Decision-Making Transparency
10. Breach Notification Procedure
11. Data Processing Agreements
14. Age Verification / Parental Consent
16. Contact / DPO Information

More about 6

Right to Restrict Processing (GDPR Art. 18):

Definition: The user can ask you to stop using their data temporarily without full deletion. Their data stays stored but is not processed further.

For ecommerce, this usually means:

- Customer account stays in database.
- No marketing emails.
- No profiling.
- Account may be suspended from login until restriction lifted.
- Order data is retained (for tax/legal).

Triggers when:

- Customer contests accuracy of data (until verified).
- Processing is unlawful, but customer prefers restriction instead of deletion.
- You no longer need the data, but customer requires it for legal claims.
- Customer objects to processing and the balance test is unresolved.

In Phoenix Cart terms:

No built-in "suspend/freeze account" status.

Currently: either active customer or deleted customer.

What’s missing: a flag in customers table (e.g. processing_restricted = 1) and logic that:

- Blocks login and checkout.
- Blocks marketing sends.
- Keeps all past orders intact.
- Allows admin to lift restriction.

I'm thinking a customer red/green selector. This allows the admin to deactivate a customer.

If admin deactivates a customer;

1. nuke all product notifications that this customer signed up to
2. nuke all scheduled emails that this customer is due to receive
3. if this customer tries to login, immediately redirect to logout

Does anyone have any thoughts ?

Should we allow the customer to freeze themself ?

burt wrote: ↑Sun Sep 07, 2025 11:32 am Should we allow the customer to freeze themself ?

As described, that would let customers do something that they can't reverse. E.g. "Oops, I didn't mean to press that button. Why can't I log in anymore?"

I think that if customers can freeze themselves, then they also need to be able to unfreeze themselves. E.g. when they try to log in, the failure page says something like "Account frozen. Click the button to send an email so that you can unfreeze the account." It would only need to say that if the login would otherwise be successful.

Perhaps there would need to be more than one frozen status. E.g.

1. Account unfrozen and fully active.
2. Customer froze account.
3. Admin froze account but customer can unfreeze.
4. Admin froze account and customer can't unfreeze.

If 4, then the login failure page might suggest that the customer contact the store administrator (owner).

We don't need GPDR in Australia, but I still allow customers to delete their data etc. This is actually a requirement for things like Facebook Login, and some customers are grateful they can delete their data for peace of mind.

And I think it's useful to have customer staus enabled/disabled anyway.

For instance customers who use a dodgy email adress can be disabled and they can't login or reregister, or customers can be disabled if they haven't bought for a long time. I used to disable old customers so they wouldn't appear in lists and searches but if they logged in (even after years) they were reactivated.

The least needed to comply with Article 18 is a way for the customer to be frozen - the simplest option;

1. allow shopowner to freeze a customer (red/green selector)
2. show some text on the GDPR page that explains that if the customer wants to freeze themself per Art 18, they should contact the shopowner.
3. if the customer is frozen and tries to login, they get a message saying "your account is limited...contact us" (or words to that effect).

I'm not having time/effort to code up an interface that allows multiple states of `frozen-ness` - is anyone else up for that challenge?

burt wrote: ↑Fri Sep 12, 2025 11:02 am The least needed to comply with Article 18 is a way for the customer to be frozen - the simplest option;

1. allow shopowner to freeze a customer (red/green selector)
2. show some text on the GDPR page that explains that if the customer wants to freeze themself per Art 18, they should contact the shopowner.
3. if the customer is frozen and tries to login, they get a message saying "your account is limited...contact us" (or words to that effect).

I'm not having time/effort to code up an interface that allows multiple states of `frozen-ness` - is anyone else up for that challenge?

I can, is above what you need?

Only if others want it. I think it's overkill.

My only thought was if we allow them to freeze themselves, we should allow them to unfreeze themselves. Everything else was just a consequence of that. This does not seem like something where a decision needs made now. Admin freezes complies with the law. If it makes an unreasonable amount of work for the admin (i.e. if people use it with any frequency), we could revisit it and provide customer freezes to reduce the admin load.

Customer freezes are more difficult both because customers may do it accidentally and that malefactors may want to do it to customers on purpose. Therefore customers should be able to undo their own freezes (that they initiated). But we don't want customers to be able to unfreeze if admin did it for legal reasons (e.g. a customer who sued over a previous shipment). Now we need more statuses.

As Burt notes, it's a lot simpler to only allow admin freezes and not pick up the maintenance issues for the more complicated system.