When matching which entry in the `Accept` header should be used for
a given media type, the specificity matters. However once those are
resolved, only the quality matters when selecting preference.
Regression in c075508b4de8edf9db553b409f8a8ed2f26ecead.
Thank you to Anders Kaseorg for the report.
Refactored GIS-related JavaScript initialization to eliminate inline
scripts from templates. Added support for specifying a base layer using
the new `base_layer_name` attribute on `BaseGeometryWidget`, allowing
custom map tile providers via user-defined JavaScript.
As a result, the `gis/openlayers-osm.html` template was removed.
Thanks Sarah Boyce for reviews.
Co-authored-by: Natalia <124304+nessita@users.noreply.github.com>
HttpRequest.get_preferred_type() did not account for parameters in
Accept header media types (e.g., "text/vcard; version=3.0"). This caused
incorrect content negotiation when multiple types differed only by
parameters, reducing specificity as per RFC 7231 section 5.3.2
(https://datatracker.ietf.org/doc/html/rfc7231.html#section-5.3.2).
This fix updates get_preferred_type() to treat media types with
parameters as distinct, allowing more precise and standards-compliant
matching.
Thanks to magicfelix for the report, and to David Sanders and Sarah
Boyce for the reviews.
Thanks Simon Charette for the guidance and review. Thanks Tim Schilling for the
documentation review. Thanks David Wobrock for investigation and solution proposals.
Previously, the ADMINS and MANAGERS settings were lists of (name, address)
tuples (where the name had been unused). Deprecated use of tuples.
Updated settings value sanity checks, and changed from ValueError to
ImproperlyConfigured.
Raising DatabaseError directly made it harder than it should to
differentiate between IntegrityError when a forced update resulted in no
affected rows.
Introducing a specialized exception allows for callers to more easily
silence, log, or turn them update failures into user facing exceptions
(e.g. 404s).
Thanks Mariusz for the review.
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Co-authored-by: Adam Johnson <me@adamj.eu>
Co-authored-by: Sarah Boyce <42296566+sarahboyce@users.noreply.github.com>
This moves the behaviors of `order_by` used in Postgres aggregates into
the `Aggregate` class. This allows for creating aggregate functions that
support this behavior across all database engines. This is shown by
moving the `StringAgg` class into the shared `aggregates` module and
adding support for all databases. The Postgres `StringAgg` class is now
a thin wrapper on the new shared `StringAgg` class.
Thank you Simon Charette for the review.