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)
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)
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.
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.
