Dear Grant,
Thank you so much for setting me on track for fixing this issue. After close investigation I definitely pulled specify7 images from edge tag around end of 2023, for I was trying out the Weblate process for French language.
Backing up and deleting the three aforementioned table (spmerging, uniquenessrule, uniquenessrule_fields) did not seemed to work in my case, maybe the DB was cluttered with other issues? … (kept getting error like unknow column spmerging.mergingstatus in the backend logs when attempting django migrations).
I decided to start afresh and got rid of every SP7 tables (as if I were just migrating from SP6 to SP7 with current content).
It might sound like an extreme option, but we have only been using SP7 in production for a few weeks here in CAY herbarium, so we still have a very “young” system that do not rely yet heavily on SP7-only features.
First I did a full backup of my DB. Then I backed up the tables one by one to make it easier to insert them back to the DB one by one later on if needed:
TABLES=("attachmentdataset" "auth_group" "auth_group_permissions" "auth_permission" "continentcodes" "countryinfo" "django_content_type" "django_migrations" "django_session" "geoname" "notifications_message" "spdataset" "splibraryrole" "splibraryrolepolicy" "spmerging" "sprole" "sprolepolicy" "spuserexternalid" "spuserpolicy" "spuserrole" "uniquenessrule" "uniquenessrule_fields")
FOLDER="sp7-tables_$(date '+%Y%m%d')"
DBNAME=aublet3
mkdir $FOLDER
for table in "${TABLES[@]}"; do
echo $table;
mariadb-dump -u root -p $(DBNAME) $table > $FOLDER/$table.sql
done
Then I deleted them all but the ones from GEO plugins (continentcodes, countryinfo, geoname do not seem to be added by django migrations)
SET foreign_key_checks = 0;
DROP TABLE IF EXISTS attachmentdataset, auth_group, auth_group_permissions, auth_permission, django_content_type, django_migrations, django_session, notifications_message, spdataset, splibraryrole, splibraryrolepolicy, spmerging, sprole, sprolepolicy, spuserexternalid, spuserpolicy, spuserrole, uniquenessrule, uniquenessrule_fields
SET foreign_key_checks = 1;
Then restarted the system (docker compose up -d). Migrations went smoothly:
specify7-1 | Operations to perform:
specify7-1 | Apply all migrations: accounts, attachment_gw, auth, businessrules, contenttypes, notifications, permissions, sessions, workbench
specify7-1 | Running migrations:
specify7-1 | Applying accounts.0001_initial... OK
specify7-1 | Applying accounts.0002_auto_20211223_1206... OK
specify7-1 | Applying accounts.0003_auto_20220621_1541... OK
specify7-1 | Applying attachment_gw.0001_initial... OK
specify7-1 | Applying contenttypes.0001_initial... OK
specify7-1 | Applying contenttypes.0002_remove_content_type_name... OK
specify7-1 | Applying auth.0001_initial... OK
specify7-1 | Applying auth.0002_alter_permission_name_max_length... OK
specify7-1 | Applying auth.0003_alter_user_email_max_length... OK
specify7-1 | Applying auth.0004_alter_user_username_opts... OK
specify7-1 | Applying auth.0005_alter_user_last_login_null... OK
specify7-1 | Applying auth.0006_require_contenttypes_0002... OK
specify7-1 | Applying auth.0007_alter_validators_add_error_messages... OK
specify7-1 | Applying auth.0008_alter_user_username_max_length... OK
specify7-1 | Applying auth.0009_alter_user_last_name_max_length... OK
specify7-1 | Applying auth.0010_alter_group_name_max_length... OK
specify7-1 | Applying auth.0011_update_proxy_permissions... OK
specify7-1 | Applying auth.0012_alter_user_first_name_max_length... OK
specify7-1 | Applying businessrules.0001_initial... OK
specify7-1 | Applying businessrules.0002_default_unique_rules... OK
specify7-1 | Applying permissions.0001_initial... OK
specify7-1 | Applying permissions.0002_role_rolepolicy_userrole... OK
specify7-1 | Applying permissions.0003_auto_20220321_1445... OK
specify7-1 | Applying permissions.0004_intialize_defaults... OK
specify7-1 | Applying permissions.0004_auto_20220407_1927... OK
specify7-1 | Applying permissions.0005_merge_20220414_1451... OK
specify7-1 | Applying notifications.0001_initial... OK
specify7-1 | Applying notifications.0002_message_read... OK
specify7-1 | Applying notifications.0003_spmerging... OK
specify7-1 | Applying notifications.0004_rename_merge_policy... OK
specify7-1 | Applying notifications.0005_auto_20240530_1512... OK
specify7-1 | Applying notifications.0006_localityupdate_localityupdaterowresult... OK
specify7-1 | Applying permissions.0006_add_dataset_create_recordset_permission... OK
specify7-1 | Applying permissions.0007_add_stats_edit_permission... OK
specify7-1 | Applying permissions.0008_attachment_import_role... OK
specify7-1 | Applying sessions.0001_initial... OK
specify7-1 | Applying workbench.0001_initial... OK
specify7-1 | Applying workbench.0002_spdataset_visualorder... OK
specify7-1 | Applying workbench.0003_auto_20210218_1256... OK
specify7-1 | Applying workbench.0004_auto_20210219_1131... OK
specify7-1 | Applying workbench.0005_auto_20210428_1634... OK
Copied back the spdataset table:
mariadb -u root -p $(DBNAME) < sp7-tables_20241003/spdataset.sql
Et voilĂ !
Again I’m certainly not recommending what I did. I’m just mentioning it for the record in the knowledge base. @Grant please issue a red card 
if this is too much of a dangerous option, for later readers.
Thanks again for your help, and thanks to @markp for backing up this issue 
Cheers,
Philippe V.
/s