delete record from db vs mark as deleted

[peteinlux]

just a thought, not sure if it was mentioned:

whenever an entity, say a contact is deleted, all of its associated data is also removed from the database. if accidental deletion takes place, we must rely on a backup. this could be problematic due to a number of other changes made to the database concurrently.

what if we added a 'deleted' field on each table and simply omitted those records in normal every day queries?

thus, if a need arose to recover a lost entity, the db administrator would simply have to uncheck the deleted state and on the records and all of its relations. there could be some type of a trash folder where all removed entities could be controlled and with a click "recovered". following on this thought, i would imagine that every class implemented some kind of a recover function which accepted only id as an argument

best

[mbach]

This is one of the best suggestions, I read here for the last months!!!

At the moment you just can restrict a user, whether to read or to write to an item like tasks or projects.
But there is no possibility to permit "deletion" of an object.
I think, especially because of legal requirements, it is absolutely necessary to keep old recors, tasks, emails and notes of a contact/company. Therefore an archinving function of deleted records is an urgently needed "must have"!
At the moment I do not see a possibility to solve that problem with the standard features we have in GO/GO Pro.

Maybe, as a further suggestion, there should be a "comment of deletion" and maybe a "type of deletion" (e.g. D01 - no client any more) for further search in archive and to make clear, why the user deleted an item (contact, company, task, project, bill etc.).
The archiving funcion should be sortable by type (contact, company, tasks, projects...), by user (who deleted), by date (when deleted) and by reason ("type of deletion"). Of course there should be an "unarchive function" to recover the deleted entry.

To keep the database small(er) there should be an export function to export complete archived information of a year to a file for backup purposes. And of course a reimport should be there, that works... , if you need that for legal purposes somewhere in the future.

You think now, that I am working in a legal company? Sorry for that - no! All companies in Europe do have those legal bindings for archiving business activity. The time for documentation varies between 3 and 10 years depending on the type of information and the country you live in.

Cheers, Markus

[mbach]

Has anyone a good idea/opinion to the mentioned feature???

Cheers, Markus

[Papageno]

Has anyone a good idea/opinion to the mentioned feature???

Yes, It could also be a function like Undo which may work on all modules and inputs
But I don't know if this is a good idea/opinion

Best Regards
Hans

[mbach]

Hi Hans,

IMHO every idea, which leads to a better product is a good idea!!!

But with your suggestion I think only an UNDO is a little bit too... hmm - not enough!
With an undo you normally "un do" a just made mistake. But with an archive function you can go back for - sometimes - several years.

But I think an UNDO-function would be a fast and easy integration for the daily use of a standard user.

BTW, thanks for sharing your idea!!!


Cheers, Markus

[gregoire]

I agree. Deleting should not lead to total deletion.
Maybe tombstoning (not being able to edit but still visible/greyed out) would be an idea too. You could then still do a search and add a parameter to include tombstones or not for instance.

[Papageno]

I think it could be made like in billing or tasks or procets. There it is possible to select the range of view. Then just one additional field is required. Total deletion should only be possible for specified administrators (in big installations).

Best Regards
Hans