Credit to @alxy.
If the default format mode is selected, there is no chance to configure the format options for delimiter, enclosure, escape and encoding. This considers a new config file item `defaultFormatOptions` and falls back to `null` if it is not specified.
To keep things consistent, the old default values remain untouched.
This fixes#4117
Currently, the color picker modal (palette) is appended to the body (default) which makes it unusable in Octobers modals, e.g. for related model forms. This fixes this issue by appending the spectrum div to the parent element.
Credit to @alxy
The response is returned directly to the route so this is not needed, it was likely added as an artefact of a previous implementation
Refs #3773
Refs #3746
There was a conflict between two repeaters that had the same fieldName (data) bound to the same controller. Example:
Controller: Events
Manages a ReportTemplate model with a custom popup Form widget that uses a grouped repeater with the field name data to define the available "fields" within a ReportTemplate
Also manages Report models through a relation controller that uses a Form widget with a regular repeater with the field name data that defines the values of the fields defined by the associated ReportTemplate.
Since both repeaters had the field name of "data", but one of them was grouped and the other wasn't, this would cause an issue in Repeater::processExistingItems() where the grouped repeater would attempt to process the ungrouped repeater's data which would then fail. This issue could easily cause many other vastly more confusing and difficult to detect issues in cases where multiple repeaters with the same field name AND the same mode (grouped vs regular) existed on the same page under different contexts. The simple solution is just to ensure that the indexInputName and groupInputName are both taking the repeater's alias into account when being generated to ensure that everything stays unique like it should.
If a website has a Service Worker installed it would load and register before a User tries to login to the backend causing a "Invalid security token" message. This PR unregisters any installed Service Worker when a User opens the backend Signin webpage.
I have also added the NEW Security Headers to add Protection to October's Cache and Cookies. This includes two new Middleware that first clears any bad cached data before a User tries to login and the second Middleware will clear all the sensitive User Data when a User signs out of the Backend.
For more info on the new Security Header 'Clear Site Data' you can see the spec found here: https://www.w3.org/TR/clear-site-data/Fixes#4076, fixes#3707.
