Revert: Grant migrator privileges even when the user already exists

[CarolineDenis]

Fixes #8305

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add relevant issue to release milestone
• Add pr to documentation list
• Add automated tests
• Add a reverse migration if a migration is present in the PR
• Add migration function to

  specify7/specifyweb/specify/management/commands/run_key_migration_functions.py

  Line 50 in ea04665

  def fix_schema_config(stdout: WriteToStdOut | None = None):

Testing instructions

1. Check that you have a specify_migrator* and specify_user* already created in MySQL.

• *The users may not be of those names. They need to match the MIGRATOR_NAME and APP_USER_NAME in the .env file.

2. Edit the .env file so that the DATABASE_NAME is one that does not exist yet.
3. Build/rebuild your Docker containers.

• Check the specify7 container logs and make sure there are no migration errors.

4. Open the application in your browser.

• Make sure that it's opening the Specify 7 initial database setup screen.

5. Stop the containers.
6. Edit the .env file so that the DATABASE_NAME is one that does exist and was not previously opened in v7.12.

• You may run into migration errors while testing an old database.

7. Build/rebuild your Docker containers.

• Check the specify7 container logs and make sure there are no migration errors.

8. Open the application in your browser.

• Make sure that it's opening the Specify 7 login page.

Additional checks:

• See that changing the migrator name to master in .env prints the proper log message.
• See that changing the app user name to master in .env prints the proper log message.
• See that changing the app user name to the migrator in .env prints the proper log message.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e60ce1b7-5cb0-4211-a5ac-7d8b950bd335

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch issue-8305

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[combs-a]

I wrote these testing instructions, but they may need to be added onto if anyone spots any additional coverage needed!

---

New database:

• Check the specify7 container logs and make sure there are no migration errors.
• Make sure that it's opening the Specify 7 initial database setup screen.

Previously existing database (used pre v7.12):

• Check the specify7 container logs and make sure there are no migration errors.
• Make sure that it's opening the Specify 7 login page.

---

New database worked as expected.

Was able to create a new database with no issues, but ran into an issue with the Specify app user when attempting to open an old database. Used the same database as I did in the originally reported issue.

[combs-a]

Noting this here--the regex also needs to be checked; there is an issue with not forming the database names correctly. Had a DB with an underscore in it and so it attempted to grant permissions to test\_db rather than test_db.

Not quite in the scope of just this PR but should be fixed.

[g1rly-c0d3r]

New database:

• Check the specify7 container logs and make sure there are no migration errors.
• Make sure that it's opening the Specify 7 initial database setup screen.

Previously existing database (used pre v7.12):

• Check the specify7 container logs and make sure there are no migration errors.
• Make sure that it's opening the Specify 7 login page.

---

New database works as expected, and as long as I destroy the database volume when rebuilding the containers (docker compose down -v), using an existing database works as well.

If I don't destroy the volume, mariadb will not source the seed-database/*.sql files, and in this case I have to add

CREATE DATABASE IF NOT EXISTS `...`

to the start of the .sql file, So I'm not sure if that is the intended behavior. If I omit the -v, then I do have migration errors, because the existing database is not loaded by the mariadb container. If this is intended behavior I can approve.