Removing client doesn't remove all assets that are connected to that client about sentora-core

[Caffe1neAdd1ct]

Thanks for reporting, I remember this request from a while back on the forums.

I think we could do with a list of check boxes to decided what to remove when deleting a client...

[sosojni]

Yes, i'm sure that there are cases where host owner would like to keep logs some time after client is deleted etc.
I didn't dig deep inside panel so i'm wondering, would it be a problem to move "deleted" client into seperate table (visualy...not database table) under active clients where host owner would have list of deleted clients that still have some data on server which he (host admin) could later delete.

[MBlagui]

Same over records left in database

[Caffe1neAdd1ct]

Good idea, we'll have a review of how the client module works and looks for one of the next versions. I've primarily assigned this to 1.1 but may get moved back to 1.2.

Records in the DB aren't an issue for me, quite handy to see how many clients you've had overall, however files left around the system are a pain to clear up.

We'll review the core clients module 👍

[MBlagui]

DNS records don't get removed once deleted and if you try to add it back welcome to bugs bunny.

[TGates71]

Yes, I think this should be implemented. There is no reason to keep them in the DB after deletion. As I had suggested in the Staff forums, the accounts and their info should be moved to another DB table for reference (kind of like a backup log).

[MBlagui]

It could be dumped to an XML file if we want a backup.....No need to inflate db with this mess.

[allebb]

Just for reference these originally was flagged as deleted in the DB to
enable an easy method to 'restore' an account and all features in the event
that users accidentally deleted something (or the administrator an
account), it also mean't there was a way of keeping a record of what sites
was created and hosted by whom etc so in the event that authorities needed
to speak to someone about hosting a site you could easily identify whom on
the server had hosted it (even if they had since deleted it)....
realistically this data wouldn't take up more than a few megabytes and
saves the complexities of dumping out data to an XML file etc. etc. but do
what you want... lol! - The database was never designed originally for
users to inspect so the 'mess' you describe wasn't in my opinion a problem
;)

On 16 October 2014 10:02, MBlagui [email protected] wrote:

It could be dumped to an XML file if we want a backup.....No need to
inflate db with this mess.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[MBlagui]

The problem @bobsta63 that other modules miss checking that record stat is deleted when trying to add a new one. So we ended up with unable to add dns records/users if the record existed before.
From this point of view I agree but we need to ensure all modules DNS/web/FTP/email will check records state in case of adding another new one.

Alternative solution as I said is pushing them into an XML file for archiving.

I had been thinking about exporting users config ( all emails accounts/web config) so we can move them from a server to another. The same function would be used to archive/backup this data off the DB.

M B

[allebb]

Yeah I agree! - I'm sure that once upon a time they did though ;) - Maybe
over the last couple of years they've been stripped out without an
understanding of their actual use/design.

On 16 October 2014 11:21, MBlagui [email protected] wrote:

The problem @bobsta63 https://github.com/bobsta63 that other modules
miss checking that record stat is deleted when trying to add a new one. So
we ended up with unable to add dns records/users if the record existed
before.
From this point of view I agree but we need to ensure all modules
DNS/web/FTP/email will check records state in case of adding another new
one.

—
Reply to this email directly or view it on GitHub
#68 (comment).

[5050]

I propose myself to implement that : when a record is to be deleted in the database, at least 2 lines are added in a file "/etc/sentora/logs/deleted_records.log".

The first line wiil describe what was the deletion cause, like "2014-11-05 08:56 Delete user account Xxxx"
The next line(s) will be the sql command to retore the deleted info.
an empty line will separate blocs

[TGates71]

That's a great idea! But, it would include user info such as encrypted pass and password salt, user location and telephone, etc... This is why I suggested it be in a separate DB table. Also, if in a DB table, the admin can look through it easily via an admin module of some sort and decide what to do with it. Also, a hook could be created to delete or whatever entries older than XX amount of time/days/years.

[5050]

It is started, but as it involves many changes and is not imperatively required (not a locking bug), I'll not push it for the first release of Sentora : it would break too much the beta version and would require a new complete tests set.

Is there any "quick fix" for this? I need to re-register a customer account (which has been previously deleted and is not listed in clients) but when I try Sentora states the email address is in use by another account.
Thanks.

[allebb]

Yeah, the "quock fix" would be yo Open up the x_accounts table in the sentora_core database and delete the row from the table that has that email address... Then re-create the account and all should be fine :)

Cheers,
Bobby

Sent from my iPhone

On 17 Mar 2015, at 21:23, yusufn [email protected] wrote:

Is there any "quick fix" for this? I need to re-register a customer account (which has been previously deleted and is not listed in clients) but when I try Sentora states the email address is in use by another account.
Thanks.

—
Reply to this email directly or view it on GitHub.

Wow. I popped to the shop just after posting this, just arrived home and valid response already. Confirmed "quick fix".
Thanks Bobby.

[allebb]

No problem buddy :)

Sent from my iPhone

On 17 Mar 2015, at 21:49, yusufn [email protected] wrote:

Wow. I popped to the shop just after posting this, just arrived home and valid response already. Confirmed "quick fix".
Thanks Bobby.

—
Reply to this email directly or view it on GitHub.