> yes, you are right. This would be the easiest way. > But I'm not very happy with this, because every year 10,000 students are > leaving our university and all would produce empty entries. > I'm not very familiar with databases. Will we run into performance problems, > if there are so many new entries every year?
It's more of a function of how many tickets they generate, not how many users (the user table is tiny compared to the ticket transactions, and judicious addition of indexes for commonly used tables like "users" will help a lot). Overall performance will depend on how well your database servers are configured. If you want to be totally safe, make sure that the database server is not on the same host as the OTRS server, and that it is clustered (even if you start with only one database server; if you configure it that way, you can horizontally scale it if you need to w/o taking an outage). Cluster and/or replication for both MySQL/MariaDB and Postgres are very stable, and not terribly hard to configure. > > If you need to comply with a data privacy act, why not simply blank > > the fields with personal data but leave the record itself in place? >> [snip] > > If you blank or NULL the respective fields there would be no personal > > data left and legal aspects would be o.k. Blanking would work too. I like to replace it with Deleted User <user@host> to flag to an agent that this is an archival record that doesn't connect to a real user. Note that none of these solutions (including deleting the customer record) will catch references or names/personal info included in ticket transactions. If you have to scrub that hard, then you'll have to totally purge their tickets and CIs as well. At that point, you *could* delete the customer record, because there wouldn't be any dangling references. That will lose a lot of useful historical data, though. _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
