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)
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.
Disable the admin toggle and delete operations from the current user, to avoid accidents.
(cherry picked from commit b0f5ac6df5d31f612dc833a88cfca8936c4137d7)
DNSSEC requires changes to the parent domain, which in many cases requires special access to a registry or the like.
For that reason, especially the option to disable DNSSEC can be dangerous - if DNSSEC is disabled in PowerDNS but not in the registry, the domain stops working.
For this reason, adding an option to disable DNSSEC changes for non-admins seems reasonable.
(cherry picked from commit 5cdfc0263b07f4658d51cf7c038fea9a8911152a)
Added the possibility for assigning users to an account, providing access to all domains associated with that account automatically.
This makes management easier, especially in installations with lots of domains and lots of managing entities.
The old style per-domain permissions are still there and working as usual. The two methods work perfectly side-by-side and are analogous to "user" (per-domain) and "group" (account) permissions as we know them from Active Directory and such places.
(cherry picked from commit 34fbc634d2848a7f76dc89a03dd8c0604068cc17)
This adds initial support for accounts a concept meant to signify a customer, a department or any other entity that somehow owns or manages one or more domains.
The purpose is to be able to assign an account to any number of domains, making it easy to track who owns or manages a domain, significantly improving manageability in setups with a large number of domains.
An account consists of a mandatory, unique `name` and optional `description`, `contact` name and `mail` address. The account `name` is stripped of spaces and symbols, and lower cased before getting stored in the database and in PowerDNS, to help ensure some type of predictability and uniqueness in the database.
The term *account* is actually taken from the PowerDNS database, where the `domains.account` column is used to store the account relationship, in in the form of the account `name`.
The link to a domain in PowerDNS-Admin is done through the `domain.account_id` FOREIGN KEY, that is linked to the `account.id` PRIMARY KEY.
(cherry picked from commits 4e95f33dfb0676d1c401a033c28bca3be7d6ec26, da0d596bd019a339549e2c59630a8fdee65d0e22, 7f06e6aaf4fd8011c784f24b7bbbba5f52aef319, 1c624dad8749024033d1d15dd6242ca52b39f135)
The options for SOA-EDIT-API included was actually the options used for SOA-EDIT, which is a very different beast.
Those options have been swapped out for the options allowed in SOA-EDIT-API and SOA-EDIT-DNSUPDATE.
Previously this caused the newly added record to either appear at the
bottom, or not appear at all. Now it will always be added at the top,
and whatever search present is cleared.
Adds a new javascript parameter that holds the webroot of the app. This
allows the the javascript calls to properly identify that they're
running in a subfolder/different webroot and direct their queries there.
This commit adds a new table to store per-domain settings, so a database
migrate/upgrade will be required. The first use-case is to allow dyndns
updates to create a record if one doesn't yet exist but only if the
per-domain setting is set.
Direct binding only works for elements already in the DOM, delegated
binding works for all elements that match a filter even if created after
the DOM is fully loaded.
