When toggling Two Factor Authentication, it often takes a few tries to get it to work.
The toggle function ends up reloading the page in two different places, effectively creating a race condition.
This fixes that problem
(cherry picked from commit 6b9fc897bc02ff857a968e76ed49f1b0f2108bb5)
Update user management feature to allow editing user details directly in the admin user interface.
Also added an option to reset the two factor authentication data of a user, for when that's needed (lost device, technical issues etc).
(cherry picked from commit 3139616282a18c11463c6ecf78888417b2ac1c35)
PowerDNS 3.x API does not support setting or getting account info.
This patch lets PowerDNS 3.x users use the rest of the interface without problems.
Account stuff still does not work.
A message is logged in debug mode, to help with troubleshooting on newer versions
of PowerDNS.
Adds an `allow_quick_edit` setting, using the improved setting handling logic from PR #287 to toggle whether records are editable by simply clicking the row or not.
Aims to fix#288
For a setting to be useful, the code has to be able to make sense of it anyway. For this reason it makes sense, that the available settings are defined within the code, rather than in the database, where a missing row has previously caused problems. Instead, settings are now written to the database, when they are changed.
So instead of relying on the database initialization process to create all available settings for us in the database, the supported settings and their defaults are now in a `defaults` dict in the Setting class. With this in place, we can stop populating the `setting` table as a part of database initialization and it will be much easier to support new settings in the future (we no longer need to do anything to the database, to achieve that).
Another benefit is that any changes to default values will take effect automatically, unless the admin has already modified that setting to his/her liking.
To make it easier to get the value of a setting, falling back to defaults etc, a new function `get` has been added to the Setting class. Call it as `Setting().get('setting_name'), and it will take care of returning a setting from the database or return the default value for that setting, if nothing was found.
The `get` function returns `None`, if the setting passed to the function, does not exist in the `Setting.defaults` dict - Indicating that we don't know of a setting by that name.
To avoid problems with inactive DB connections, SQLAlchemy provides a `pool_pre_ping` option, that described in more detail here:
http://docs.sqlalchemy.org/en/latest/core/pooling.html#disconnect-handling-pessimistic
In flask environments, it's enabled by subclassing SQLAlchemy, which is what I've done here.
Fixes errors like:
sqlalchemy.exc.OperationalError: (_mysql_exceptions.OperationalError) (2006, 'MySQL server has gone away') which results in an Error 500 in the UI.
