1. If the setting isn't in the database, then the specified default is
returned.
2. If the setting IS in the database, then the 'value' field, from the
database, is returned; Unless, the value is null in the database, then
the defined default is returned.
* Take case 1. If the default=None then an AttributeError is raised
* Thus, by setting default='', in case 1. We don't get an AttributeError
because '' will be returned.
* Also note that we don't allow_null=True because then the database
entry could be None. Accessing the setting would raise an AttributeError
in this case. Further, since we set default='' it doesn't matter if null
is in the database.
TL;DR set default=<something_other_than_None>
The JSON serializer for our API uses ``json.loads``, which permits *any*
valid JSON (including bare integers, boolean values, etc). Lots of our
code, however, assumes that inbound JSON content will be a dict.
see: #4756
* stable: (275 commits)
Install correct rpm-sign package in RPM builder
Updating changelog for 3.1 release
Switch job_type to check from sync when detecting delete_on_update
use Unicode apostrophes - not single quotes - for French i18n strings
pin appdirs==1.4.2
only cancel deps if we can cancel the inv update
fixing module_name check and adding support for the debug module
cancel jobs dependent on inv update
update tests
CSS tweaks to workflow results panels
like inventory updates, check if project update deps already processed
Revert "Merge pull request #5553 from chrismeyersfsu/fix-waiting_blocked"
Add awx/ui/client/languages to .gitignore
Delete awx/ui/client/languages/*.json
refactor based on review
Add missing permission check.
Make current_groups a set to easily avoid duplicates, update asgi-amqp requirement
avoid duplicated related search fields
Fix workflow audit items
fixing module name, json blob, and stdout-for-yum-module on host event
...
There's a race between our `ws_connect` and `ws_receive` methods;
it's possible to fall into a scenario where we're handling a legitimate
message *before* django-channels is able to persist the `user_id` into
the channel session. This results in a scenario where a user can open
a browser tab and never receive new websocket messages. In this
scenario, we should just toss the message back into the queue and try
again later (up to a reasonable limit of retries).
