Third-Culture-Software / bhima

A hospital information management application for rural Congolese hospitals
https://docs.bhi.ma/
GNU General Public License v2.0
218 stars 104 forks source link

Unify the `locked` column types across all schemas. #7756

Open jniles opened 1 week ago

jniles commented 1 week ago

In BHIMA, we use locked columns quite a bit to signal records that should not be used for some reason or another. It may be that an account is not longer useful, or an employee left the organization, or that a patient's account should be frozen. Despite its ubiquity, we actually have multiple different definitions of the the column. For example:

For the account table: https://github.com/IMA-WorldHealth/bhima/blob/7359bb7cf3b096edfed4acee0124e0b1f5dec6ac/server/models/01-schema.sql#L17

For the budget table: https://github.com/IMA-WorldHealth/bhima/blob/7359bb7cf3b096edfed4acee0124e0b1f5dec6ac/server/models/01-schema.sql#L117

For the debtor_group table: https://github.com/IMA-WorldHealth/bhima/blob/7359bb7cf3b096edfed4acee0124e0b1f5dec6ac/server/models/01-schema.sql#L380

We treat them all the same, functionally in Javascript. They are most often converted to a binary 0/1 and filtered on with locked <> 1 or locked =1 in SQL. Given this, we should standardize the column definitions. I propose the following:

`locked` TINYINT(1) NOT NULL DEFAULT 0

This way, we set the rules that (1) it must be defined and (2) it defaults to 0 on creation. Also, we remove the confusion around BOOLEAN types between SQL and Javascript.

To complete this issue, the developer should:

  1. Find/replace all the lcoked columns in the schema.sql with the new type definition.
  2. Ensure tests pass.
  3. Write migration scripts in migrate/next.sql to ensure that old databases are updated.