Configuration and User editing broken
PolarianDev opened this issue · comments
Describe the bug
When attempting to change a user's settings, or when changing configuration settings such as templates, when submitting the changes there is "Unknown error", however this is not reflected within the logs.
It then follows up saying the configuration has been saved, but this is not reflected within the database or pufferpanel and a quick refresh will show the old information.
To Reproduce
Steps to reproduce the behavior:
- Go to user page
- Click on a user
- Attempt to edit the email, or any other setting
- See error
Expected behavior
Settings should be saved without any error
Desktop (please complete the following information):
- OS: Arch Linux
- Browser Firefox
- Version 111.0
Additional context
Install through the aur package.
Its due to a locked database, I believe it was an accident when running the pufferpanel cli tool while the application was running, this caused the sqlite database to become corrupted.
I wiped the database, I will see if this is the case.
If it is, a security measure to be implemented to prevent users from accidentally bricking their database.
I have reproduced this error myself, a developer now needs to do the same :)
Cannot replicate. Editing the DB with the CLI is permitted while the panel is running. This is done when using Docker as a good example. And, the install doesn't say to start the panel until the user is added anyways. So even if it wasn't going to work, our docs tell the correct steps.
If things are not saving, there will be a log. Either in /var/log/pufferpanel or in your browser.
The database was locked, something caused it to be corrupted... I managed to replicate it twice... maybe it is something else I was doing...
Then you'll have to figure out what you are doing that replicates it. The only time it should be "locked" is when something is being changed, and it should be released once it is done.
This is really weird, something caused the database to lock and not be unlockable, and both times were when I added a user while the service was running...
Maybe it could be an issue with the systemd service not stopping properly...
I can't reproduce this, I guess this was an isolated incident, I will close it unless I experience the same issue again.