Prevent users from changing entity data fundamentally

Question

Entities in a database represent things from the real world (for example products in an e-commerce system). A user should be able to

• add a new entity
• edit the entity to correct a mistake in the DB
• edit the entity because the thing in the real world changed, too

However, the user should not edit the entity so that it now represents something else from the real world. What is the best way to accomplish this?

Example: the e-commerce store doesn't sell apples anymore, but now wants to sell oranges. So the user should not edit the apple-entity to become the orange-entity (the user might be inclined to do this to be more efficient). Instead, they should delete the apple and create a new orange.

Reason: In a system with unversioned entities, we don't want to end up with past orders that look like they were for oranges even though they were for apples. Or, in a system with versioned entities, we don't want the orange entity to look like it's been around for a long time even though it was just entered.

I've considered not allowing the user to edit the name of the entity, but that would prevent them from correcting spelling mistakes.

I've also considered testing programmatically when the user hits the save button, and if the changes seem drastic, to bring up a modal panel and ask the user if they shouldn't rather create a new entity instead. But I worry that false-positives from that test could be annoying and that there's still a risk of false-negatives. I'd much rather proactively prevent this kind of user behavior if there's an elegant way to accomplish this.

Yet another option would be to have two save buttons below the form, one "Update product" and the other "Save as new product" and have the user decide which to click. But I fear this would be clunky, could result in mistakes, and make it difficult to support save-by-clicking-enter in the form.

Answer 1

Some options.

1. The most immediate, if the entity became obsolete, you can add a toast message with the clarification in the editing window:

   

2. The second option is adding different status to the entities and enabling/disabling possible editions for each depending on the hierarchy. For example:

   • Active entity : full edition

   • Obsolete entity : partial edition allowing some fields (info, price...) but disabling actions inherent to the entity itself, for example the SKU number. Most e-commerce applications (I don't know if all) DO NOT allow duplicate SKUs. This could allow setting editing options, avoiding certain types of actions.

3. The third option. I don't see anything wrong with what's described in the question about the Update product and Save as new product, but I don't think it's the most appropriate as buttons. In some applications for creating online stores, when creating, duplicating, or editing a product, before getting into the editing fields, a pop-up window appears with radio buttons, the possible options to choose and their explanation, something like:

     🔘  Create or edit a product independently

     🔘  Create a product associated with another

     🔘  Duplicate product

This window allows adding all the information regarding what the edition implies, leaving it up to the user to do it correctly or not. I don't know how your database works, but in the duplicate field, you can indicate the cases in which it is convenient to do so, such as replacing an obsolete product.

Answer 2

You have to find out why your user would do such a thing like overwrite an existing product.

Is it easier to change all the attributes of an existing item than enter them in a new product? Is there something in the process of adding a product that makes it difficult to the user (maybe a required attribute the user does not have)? etc.

It should be easier to the user to add a new product than overwrite an existing. So you have to figure out how to make it more easy for users. Not knowing your system just some random ideas

• Use an existing product as template
• provide templates by product types
• make the process of entering new products very fast and easy
• make sure the «create new product» is accessible very easy
• use very clear wording for the actions so it is clear the edit function should only be used to correct something that changed.
• to edit something you could have an edit function for each field (since usualy only very few attributes need to be edited. On the other hand in the add form all the fields should already be in edit mode.

All the things stated in previous answers might be necessary as well but you should bring your users to not want to overwrite products instead of tell them not to do so.

Answer 3

This is a rather interesting problem that you have to solve because it seems like there is a lot more built into the entities in your products than most e-commerce platforms that treat products more like abstract concepts that are defined by the sum of all its attributes rather than by specific attributes like its name. An example might be that you can have a type of apple (fruit) called an orange which is still an apple but it's just the name that it has been given or assigned by the user.

But if you are exposing such properties and attributes for the user to manipulate, then it does make sense that you put all the proper process around the editing or updating of these fields to ensure the integrity of the underlying data. There could be more user friendly ways to do so rather than having to pop up a modal and warn the user about it but I suspect part of this will also be reflected in the creation of new entities and products as well so they should match and be coherent.

Generally the best way to prevent users from making critical errors would be to create a series of checkpoints that require explicit confirmation to prevent accidental mistakes. You can also make sure that these actions are only available in the right context and at the point of need so it makes sense to the user what the intended consequences of the actions are. But if all else fails I would simply not allow the edits and enforce the destruction and creation of new entities.

Answer 4

Depending on what parts of the app you can change could be easy to fix. By the looks of the question I am not sure if you can change the database model or certain parts of the e-commerce.

Here is an example/possible solution:

The concept would be to have a "type" attribute that you can only set the first time you add the product, predefined and selectable from a list. So no user error involved; you can give a set of "supported" product types: orange, apple, helicopter. No matter how the content of the rest of the fields change, you can always check the immutable "type" field.

Now the visual design has to promote this "type" field so it plays on the psychology of your users, since seeing the product tagged/promoted as ORANGE would make them think twice changing the name or description to "Fresh Apples". Also, a user flow oriented towards adding entries to product types instead of directly adding a product in general, could help.

To sum it up: you have "system" fields and "user" fields. Now you can base the core backend/frontend logic on system fields that you control and not unpredictable crazy user fields. Same for the app design. Modeling system fields depends on your product domain.

You will never be able to control the user but you can control the options.

we don't want to end up with past orders that look like they were for oranges even though they were for apples

Why not make a copy of the entity involved when the transaction is executed. Mixing mutable and immutable entities here. The transaction should include all the data involved.