Managing record deletion policies

Managing record deletion policies

What happens when you delete something from agileBase?

Well, the content of all the fields in the record to delete will be logged, so that an administrator can find the data later if necessary, and the delete will go ahead. That’s assuming the combination of options on the table and your privileges allow it of course.

But what if there are related items? For example, you may be deleting a company record which has contacts and maybe other things linked to it. In this case, the system will present a hard-to-miss warning, telling you all the things that will vanish if you carry on:

Only people with ‘manage’ privileges can carry on to do a cascading delete including linked items, and only of course if they have the necessary privileges on all the data to delete too.

That’s all fine and dandy but sometimes administrators may want more control over the details of deleting linked records.

For example, there may be cases where a user, even with full privileges, should never be allowed to delete linked ‘child’ data. For example, say there’s an event management system that you run. Each event has a venue, chosen from your global ‘companies and addresses’ list.

Now deleting an address will also prompt for the deletion of any linked events, but that doesn’t necessarily make sense. You may not want to delete an event just because it’s venue is removed – perhaps it’s just moving to another venue.

What’s the alternative?

There are three options for what can happen to ‘child’ records once a ‘parent’ is deleted:

• cascade the delete
  This is the default option described above
  
• prevent deletion
  The user won’t be able to delete the parent record at all, until all children have been manually removed or un-linked
  
• make children ‘orphans’
  In other words, the children will be un-linked automatically. In the events example, events will have their venue set to a blank value if a related venue is deleted
  

Different options will make sense for different data and you can set each relation in the system separately to use the one best suited for the data.

In the events example, you may wish to ‘blank’ or un-set venues when a site is removed. However, if you have invoices for customers, you may want to disallow entirely the deletion of a customer who has linked invoices.

How is this set up?

Quite simply. In the field options for each relation field, there’s a new option controlling the deletion policy. A dropdown will let an administrator choose the most relevant behaviour.

It’s set from the ‘child’ table, letting you specify different options for each type of ‘child’ of a record.