The analysis you made is correct and it's clear the constraint is referencing the wrong table. One option is to recreate the constraint in each table of the new site. Now, bear in mind that if you delete a user from a site, it will cascade to all other sites.
Regarding the "it is not enough just to set QA_MYSQL_USERS_PREFIX in config to share users", that is correct: you need to take actions in the database, such as renaming the tables, for that feature to work. However, that applies to QA_MYSQL_TABLE_PREFIX as well: you need to take actions in the database, such as renaming the tables, for that feature to work. So it is up to you to keep in sync the table names and the prefixes.
The best way, IMO, to mange these scenarios is:
Site 1:
- QA_MYSQL_TABLE_PREFIX = qa_site1_
- QA_MYSQL_USERS_PREFIX = qa_users_
...
Site N:
- QA_MYSQL_TABLE_PREFIX = qa_siteN_
- QA_MYSQL_USERS_PREFIX = qa_users_
Note the users table is not related to any site. Based on the naming on your tables and references it seems your structure is actually:
Site 1:
- QA_MYSQL_TABLE_PREFIX = qa_site1_
- QA_MYSQL_USERS_PREFIX = qa_site1_users_
...
Site N:
- QA_MYSQL_TABLE_PREFIX = qa_siteN_
- QA_MYSQL_USERS_PREFIX = qa_site1_users_
I can almost confirm this by your comment about the table having old data. There is also another thing that confirms this which is when you rename a table, constraints are renamed as well. Your constraints were not renamed.
So in the likely case you are in the second scenario (the one with the qa_site1_users_ table), if you already have the Site 1 live then, before setting up Site N, you will have to:
- Rename the users table in Site 1 to use a generic name (this will rename all constraints as well)
- Setup the right QA_MYSQL_USERS_PREFIX in Site N
- Install Q2A in Site N