This issue has been mentioned on Specify Community Forum. There might be relevant details there:

https://discourse.specifysoftware.org/t/error-when-editing-taxon-tree-in-specify7/1359/5

Developer Notes

Following the Traceback provided in the crash report, the error is being raised as the direct result of the following line:

It makes sense we are receiving a database error here: Django QuerySets are lazy.

Due to the nature of the error: Table 'taxontreedef' was not locked with LOCK TABLES, I investigated which tables were locked at the time the error is being thrown.

+----------+--------------------------+--------+-------------+
| Database | Table                    | In_use | Name_locked |
+----------+--------------------------+--------+-------------+
| specify  | taxonattachment          |      1 |           0 |
| specify  | taxon                    |      2 |           0 |
| specify  | determination            |      1 |           0 |
| specify  | taxoncitation            |      1 |           0 |
| specify  | collectingeventattribute |      1 |           0 |
| specify  | commonnametx             |      1 |           0 |
+----------+--------------------------+--------+-------------+

To get a better idea of the SQL being performed, the query can be extracted from the QuerySet. Which equates to the following (truncated for brevity)

SELECT ... FROM `taxon` INNER JOIN `taxontreedef` ON (`taxon`.`TaxonTreeDefID` = `taxontreedef`.`taxontreedefid`) INNER JOIN `discipline` ON (`taxontreedef`.`taxontreedefid` = `discipline`.`TaxonTreeDefID`) WHERE (`taxon`.`text1` REGEXP BINARY ^(TAX)(\\-)([0-9]{3})$ AND `discipline`.`usergroupscopeid` = 3) ORDER BY `taxon`.`text1` DESC;

Thus the problem becomes apparent:
We are locking taxon and all tables which reference taxon as a Foreign Key, but trying to perform an INNER JOIN on Discipline and TaxonTreeDef.

Following the Stack Trace, we can see the autonumber QuerySet is being determined by the following:

In the case for Taxon, scope_info is None so it is using the default Collection QuerySet determined by the filter_by_collection(...) function.

Where the INNER JOINs is being inserted becomes apparent:

Furthermore, the locking of the tables is occuring in the following lines:

In this case, obj._meta.db_table is taxon, so we are running the following SQL to perform the table locks:
lock tables taxon write, which does exactly lock the tables as first mentioned.

The fix here would be to additionally lock the tables needed to determine the scoping for tree records.

⚠️
This is yet to be confirmed, but the same problem likely occurs with the other trees in Specify 7:

• Storage
• Geography
• Geologictimeperiod
• Lithostrat

The above comments seem to be all about tree tables, but I am having this bug with CollectionObject:

When trying to create a blank Collection Object, Specify crashes with "Table 'institution' was not locked with LOCK TABLES")" error.
Seems to happen during autonumbering according to stack trace

KU Fish Voucher Database

Not able to replicate in that database on the test panel - thus, maybe not a high priority issue, but opening this issue just in case
Able to replicate after restarting the local docker database container

Specify 7 Crash Report - 2024-02-14T03_35_21.881Z.txt

You may be experiencing #4430, which was fixed in #4431.
The cause of the issue was was a bug in running the second business rule migration (which applied the default uniqueness rules).
The erroneous migration (before #4431) was likely already applied when #4431 was merged and because the migration was already stored in the django_migrations table, the updated migration was never run.
#4431 was merged before v7.9.3 was released, so this issue should only occur for those use production in the time frame #4430 was introduced and #4431 was merged.

To resolve the issue locally, you can do the following in the database:

delete from django_migrations where app like "%business%";
drop table uniquenessrule_fields;
drop table uniquenessrule;

And then re-run migrations, either by restarting the backend container or manually via the following command (assuming your backend container is titled specify7-specify7-1):

docker exec -it specify7-specify7-1 bash -c "ve/bin/python3 manage.py migrate"

thanks for the detailed instructions - I will go ahead and nuke the database entirely as there have been several bugs recently that are not reproducible on the test panel

Can recreate in edge (7.9.6)