We currently have the inventory_log table that provides data on what changed and who changed it in the inventory. See below:
|
DROP TABLE IF EXISTS `inventory_log`; |
|
CREATE TABLE `inventory_log` ( |
|
`uuid` BINARY(16) NOT NULL, |
|
`inventory_uuid` BINARY(16) NOT NULL, |
|
`log_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, |
|
`text` JSON, |
|
`user_id` SMALLINT(5) UNSIGNED NOT NULL, |
|
PRIMARY KEY (`uuid`), |
|
KEY `inventory_uuid` (`inventory_uuid`), |
|
KEY `user_id` (`user_id`), |
|
CONSTRAINT `inventory_log__user` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) |
|
) ENGINE=InnoDB DEFAULT CHARACTER SET = utf8mb4 DEFAULT COLLATE = utf8mb4_unicode_ci; |
We also have the debtor_group_history table that does a similar thing for the debtor group history.
Similarly, the stock_adjustments table has a similar _log table. We also have a transaction_history table that stores the history of a transaction editing.
We clearly have some issues with data quality (see #8634) and users editing values after they are used. I propose we design a new history table that unifies these operations into a single edit log table. Let's call it modification_history in this issue. In it, we would store:
- The table name of the table being updated (e.g.
posting_journal, inventory, patient).
- The primary key column name of the table in question (e.g.
record_uuid, id, etc).
- The primary key itself (the value of the
id or record_uuid or whatever).
- The user who updated it (
user_id)
- The
action (either UPDATE or DELETE).
- The timestamp of the update (
created_at).
- The
old_values of each item updated.
- The
new_values of each item updated.
If we had this information, we could recreate any history we wanted. For example, we could write custom history parsers for each that read the data out of the modification_history where table_name = "XXY" and produce a table of modifications such as:
| user |
action |
description |
timestamp |
| jniles |
DELETE |
Deleted account (15): "DIVERS INCOMES" |
3/11/26 09:54 |
| lomamech |
UPDATE |
Updated inventory (8dd5ad26-1d27-11f1-8b3c-6b83394eee19): Display name ("Amoxy" -> "Amoxyciline"). |
3/11/26 09:54 |
| lomamech |
UPDATE |
Updated inventory (8dd5ad26-1d27-11f1-8b3c-6b83394eee19): Price (5 USD -> 3.5 USD) |
3/11/26 09:54 |
| jmcameron |
UPDATE |
Updated posting_journal (d2380dba-1d27-11f1-94e6-83ee50786666): Description ("Sold the farm" -> "Sold part of the farm"). |
3/11/26 09:54 |
This would allow us to store a standardized description of the history in any language we choose.
We currently have the
inventory_logtable that provides data on what changed and who changed it in the inventory. See below:bhima/server/models/01-schema.sql
Lines 2543 to 2554 in 221699d
We also have the
debtor_group_historytable that does a similar thing for the debtor group history.Similarly, the stock_adjustments table has a similar
_logtable. We also have atransaction_historytable that stores the history of a transaction editing.We clearly have some issues with data quality (see #8634) and users editing values after they are used. I propose we design a new history table that unifies these operations into a single edit log table. Let's call it
modification_historyin this issue. In it, we would store:posting_journal,inventory,patient).record_uuid,id, etc).idorrecord_uuidor whatever).user_id)action(eitherUPDATEorDELETE).created_at).old_valuesof each item updated.new_valuesof each item updated.If we had this information, we could recreate any history we wanted. For example, we could write custom history parsers for each that read the data out of the
modification_historywheretable_name = "XXY"and produce a table of modifications such as:This would allow us to store a standardized description of the history in any language we choose.