Closed tbar0970 closed 3 months ago
Really the right solution is to introduce a person_status table. That's plenty of work though.
Yes, a person_status
could basically just copy person_group_membership_status
:
MariaDB [je_demo]> desc person_group_membership_status;
+------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| label | varchar(255) | NO | UNI | NULL | |
| rank | int(11) | NO | | 0 | |
| is_default | tinyint(1) unsigned | YES | | 0 | |
+------------+---------------------+------+-----+---------+----------------+
4 rows in set (0.001 sec)
Then we could have referential integrity for _person.status
.
Made good progress on the full solution. Todo: interface for editing the options. Todo: Make sure they are ordered by rank in report results and report groups.
Todo: foreign key in the upgrade script and init sql.
todo: search the code for references to 'archived' and 'contact'.
This is complete, but it's quite a wide-ranging change, so we should be on the lookout for side effects.
In system config page you can edit person status options. They are shown as just a bunch of textboxes, no ID numbers or anything. I wanted to re-order the options so I copied and pasted various values. But this had the effect of changing people's status, because it's indexed by number.
So in the short term we should add numbers so it's more clear that renaming options will affect people who already have that status selected. And as a FR we should make it possible to re-order existing statuses.
Really the right solution is to introduce a person_status table. That's plenty of work though.