"Waste bin" functionality in UnityBase


There is “safe delete” functionality in UnityBase. “Safely deleted” records remains in database but are marked as deleted. In some cases it is required to completely remove such records from database after some time or by request from privileged user, like administrator. In case of privileged user there could be more comprehensive behavior: administrator should be able to recover some records and completely delete another. How to implement such “waste bin” functionality in UnityBase?


This topic leads me to the following suggestion to UB team:

  • have 2 more methods added by mStorage mixin:
    – undelete. This would undelete a safely deleted record
    – purge. This would permanently delete record. I think it should permanently delete it if record was delete safely and also if record was not deleted at all.
  • The 2 methods above should be added for entities with “safeDelete: true” settings ONLY.
    – Though, it is also possible to add methods for all entities, and if entity does not allow “safeDelete”, purge would do the delete, and undelete would do nothing. But IMO cleaner design would be to implement it for entities with safe delete only.

Advantage of separate methods and not some flags, like _"_permanentDelete": true, is ability to control access with ELS to these methods.

I think, it may also be useful, to control possibility to undelete or purge on per-entity basis, by introducing 2 options of mStorage mixin entity configuration:

  • allowPurge, default is true
  • allowUndelete, default is true


Good proposition. We add it to the roadmap and implement just after we move an mStorage mixin implementation from native code to JavaScritp.
Just now I suggest to completely delete/restore such records manually using direct SQL (using knowledge of your domain).


As a temp workaround, yes, it is possible to do the permanent deletion as direct SQL. This will be a extra repetitive work and would require some work to do at client side too.

But in long term, this could become a useful platform feature, it it will be supported at both - server side, by easily allowing the function with the mixin, and client-side, by adding appropriate menu items, if user has appropriate permissions.

As for restoring, I got that with the very current state of code, being in the middle of migration mixins from pascal to javascript, it might be not suitable to change functionality. But technically, is it a really great deal to let other mixings know about record restoring? FTS could handle it as a record creation, so could other plugins do, I guess.

So, what I am suggesting is just let not abandon this feature request.