Prevent users from changing entity data fundamentally



  • 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.



  • Some options.

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

      This entity became obsolete, you can edit but not change it as a new entity    x

    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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2