Anonymization How does real customer data stay out of the test system's database?
A test system without orders is of little use for many tests. So the orders stay, and the plugin replaces whatever identifies a person while copying, before it arrives in the staging environment.
Replaced while copying, not afterwards.
There is one shared rule set for all staging environments, under Extensions › Staging Manager › Anonymization. Per table and column you set what it is replaced with.
In each staging environment you switch it on in the tab "Data" with "Anonymize using rules".
Rules for customers, addresses, orders, newsletter recipients, reviews and individual promotion codes are shipped.
Beyond names it clears comments in orders and state histories, shifts birthdays and sets stored IP addresses to 127.0.0.1.
Replacing is consistent: the same value gets the same replacement everywhere within a run. In different staging environments the replacement differs.
Changes to the rule set apply to new runs.
Per column, matching its data type.
Which replacements a column offers depends on its data type: text, JSON, date, date and time or number. At most 200 columns per table can be chosen.
Made-up names that fit the field.
Made-up parts of an address.
Formed from a made-up name and a hash, with the domain of a real provider. Whether a mail really goes out is decided by the setting "Mails" of the staging environment.
A made-up number.
An empty text, or no value where the column allows it.
A value from the original that cannot be reversed; equal originals give equal hashes within a run.
The same text everywhere, the one you enter.
By the days entered or, at 0, by a random span of up to a year that is the same for all dates of a run. Spans between two dates are kept.
Only the values at the paths entered in a JSON column, with one of the other replacements.
The value stays as it is. With "Keep password", whoever has a password in the live shop gets into the staging environment with it too.
You add tables of plugins yourself.
"Add table" shows the tables without rules; where the plugin suspects personal data, it names the columns. In the list every table is marked "Standard" (shipped) or "Custom table".
Keys, relations, generated columns and system timestamps cannot be chosen: they hold the data together and stay as they are.
Preview, preflight and record.
Shows up to five rows of the source with their replacement, using the inputs as they are right now. It is not saved.
Checks before every build whether every rule hits an existing column and every replacement can run, in JSON paths too. An error stops the build.
Every run with anonymization leaves a record in the plugin's private storage of which columns were replaced how. It stays for 90 days, adjustable under "Keep anonymization records for days".
The rule set replaces values in the database. Documents already generated, such as invoices, are PDF files and arrive in the copy with the real names. Admin users stay as they are, so you can log in to the copy.
Then the staging environment holds real customer data: whoever gets in sees names, addresses and orders. That only fits if everybody who sees it may see the same data in the live shop too.
What shop owners ask about it.
Is an anonymized copy enough for data protection?
The plugin replaces personal data before it arrives in the staging environment and leaves a record of every run with anonymization. Whether that is enough for your case is for your data protection officer to judge; the record shows which columns were replaced how.
Do orders still work after anonymizing?
Yes. Replacing is consistent: the same value gets the same replacement everywhere within a run, so links between customers, addresses and orders survive. Orders stay complete and testable.
How do I get into a customer account in the copy?
With the shipped rule set customers have no password in the staging environment. In the administration of the staging environment, "Log in as customer" opens the account. If you need the real passwords, the column can use "Keep password".
What about tables of other plugins?
The plugin ships rules for the tables of Shopware. Tables of plugins you add under "Anonymization" with "Add table"; tables with recognized personal data name their columns there.
More about the plugin
-
Setting up
The assistant in seven steps, the preflight and the first build.
-
What gets copied
Which files and tables come along, what stays empty and how rebuilding, refreshing and tearing down work.
-
Protection and access
Password page, IP addresses without a password, default user, credentials and maintenance mode.
-
Emails and calls
Four ways for emails, three for calls from apps and webhooks, plus scheduled tasks and analytics.
-
Services and plugins
Search, Redis, queue, reverse proxy and plugins: what the copy shares with the live shop.
-
Differences to the live shop
The comparison shows extensions, settings, content, files and database structure, each with its side.
-
Schedule and automation
Schedule, lifetime with reminder, Flow Builder and console commands.
-
Hosting and server
What gets written on the server, Apache, nginx, an address of its own, database privileges and SFTP.
-
Comparison with the standard
What Shopware does itself with system:setup:staging and what the plugin adds.
-
Pricing
What a staging environment costs, monthly or yearly, and what each plan includes.