Describe the bug
When attempting to create a new database locally, it fails because the user specify_migrator does not have migration privileges. This is because the privilege grant updates only occur if the migrator user is a new user in specifically the v7_12_0_7 branches.
This additionally affects opening databases that were not opened in v7.12, so if a user was to upgrade from an earlier version straight to v7.12.0.7, they'd be met with an error.
This issue does not exist on v7_12_0_6 and the part of the code that causes it is not present in main either. It is this specific conditional statement that is causing it from what I can tell.
It does not appear in test panel due to test panel's unique configuration.
To Reproduce
Steps to reproduce the behavior:
- Adjust your .env file so that the database name is one that doesn't exist, or one that was not used locally in v7.12.0.6.
- Restart the docker containers with the updated .env file.
- See the error message in the logs of the
specify7 container.
You will not be able to access the application unless you've accessed the database in v7.12.0.6.
Expected behavior
There should not be any errors preventing database setup.
Currently, the code change reflects concerns regarding granting privilege to the Specify 7 user. I believe that the current solution would work in the case where the institution is just coming to Specify 7, meaning that the migrator user hasn't been created yet. This would create a user that only has permissions on their single Specify 7 databases.
However, while I agree with this approach for safety, we also need to consider usability. If you have another Specify 7 database, this prevents creating a new one or opening an older one once you've set up Specify 7 once.
We should be sure to inform the user of the SQL user being created in this process in documentation and ideally in the actual setup stages (as a shell Y/N confirmation of some kind).
Screenshots
Here's an image of the logs (with potentially sensitive information removed). The blue is the database that I'm attempting to run on v7.12.0.7, but it was created and used previously. It was not opened on v7.12.0.6. All of the red are databases that I accessed while on v7.12.0.6.
While this isn't an example of attempting to create a new database, the message was much of the same when doing so, except for the 'database already exists' message.
- OS: Windows 10
- Browser: N/A
- Specify 7 Version:
v7_12_0_6_base
- Database Name: In private channels.
- Collection name: N/A
- User Name: N/A
- URL: N/A
Describe the bug
When attempting to create a new database locally, it fails because the user
specify_migratordoes not have migration privileges. This is because the privilege grant updates only occur if the migrator user is a new user in specifically thev7_12_0_7branches.This additionally affects opening databases that were not opened in v7.12, so if a user was to upgrade from an earlier version straight to v7.12.0.7, they'd be met with an error.
This issue does not exist on
v7_12_0_6and the part of the code that causes it is not present inmaineither. It is this specific conditional statement that is causing it from what I can tell.It does not appear in test panel due to test panel's unique configuration.
To Reproduce
Steps to reproduce the behavior:
specify7container.You will not be able to access the application unless you've accessed the database in v7.12.0.6.
Expected behavior
There should not be any errors preventing database setup.
Currently, the code change reflects concerns regarding granting privilege to the Specify 7 user. I believe that the current solution would work in the case where the institution is just coming to Specify 7, meaning that the migrator user hasn't been created yet. This would create a user that only has permissions on their single Specify 7 databases.
However, while I agree with this approach for safety, we also need to consider usability. If you have another Specify 7 database, this prevents creating a new one or opening an older one once you've set up Specify 7 once.
We should be sure to inform the user of the SQL user being created in this process in documentation and ideally in the actual setup stages (as a shell Y/N confirmation of some kind).
Screenshots
Here's an image of the logs (with potentially sensitive information removed). The blue is the database that I'm attempting to run on v7.12.0.7, but it was created and used previously. It was not opened on v7.12.0.6. All of the red are databases that I accessed while on v7.12.0.6.
While this isn't an example of attempting to create a new database, the message was much of the same when doing so, except for the 'database already exists' message.
v7_12_0_6_base