DRF will try to resolve potential candidates into the OPTIONS endpoint.
This is mainly to support their POST field in the browseable API. We
don't need this and it can yield some expensive queries so we bypass
generating choices for any RelatedField fields
Previously this would only be visible if survey is enabled. It should
be possible to define and view a survey even if this is disabled. The
enablement flag controls whether the survey prompt is shown and required.
* notifications_work: (23 commits)
Updates to notification unit tests after @wwitzel3's feedback
Fix some notifications issues and write some tests
Add notification system documentation
Clean up flake8 related issues
Fixing up some unicode issues
Implement tower ui view url on models
Sanity check and force proper types in admin check
Proper type for in check
Adding migration and base notification type
Add a periodic administrative notification
Refactor message generator
Support notification password field encryption
Notification configuration type checking
Refactor NotificationTemplate to Notifier
Implement irc notification backend
Add webhook notification backend
Pagerduty and Hipchat backends plus some cleanup
Notification serializers, views, and tasks
Implement notification serializer and validations
Notification endpoints and url expositions
...
* awx.main.models Fact added
* view host fact and timeline updated to use new Postgres Fact model instead of Mongo
* Removed license set start Mongo logic
* added View tests
* added Model tests
* Removed mongo fact unit tests
* point at modified jsonbfield that supports sqlite storage driver
* postgresify fact cache receiver
* test OPTIONS endpoint
* Note: single fact view not implemented yet.
* Job object can now control the output and generate K:V output for
notification types that can support it
* Notifications store the body as json/dict now to encode more
information
* Notification Type can further compose the message based on what is
sensible for the notification type
* This will also allow customizing the message template in the future
* All notification types use sane defaults for the level of detail now
* Remove fields from browsable API raw data that are set implicitly based on URL / parent object.
* Fix issue where a group/host could be assigned to a different inventory.
* Update validation to load values from existing instance if not present in new data; allows PATCH requests to succeed.
* Remove job_args, job_cwd, job_env, result_stdout and result_traceback fields from job listings.
* Implement concrete Notification model for notification runs
* Implement NotificationTemplate and Notification serializers and views
* Implement ancillary views
* Implement NotificationTemplate trigger m2m fields on all job templates
via a fields mixin
* Link NotificationTemplates with an org
* Link notifications with the activity stream
* Implement Notification celery tasks
* Extend Backend field parameters to identify sender and receiver as
parameters needed by the message and not the backend itself
* Updates to backends to better fit the django email backend model as it
relates to Messages
* Implement success job chain task + notifications
* Implement notifications in error job chain task