d14be2067c
revoking an api key the service it associated with was of course added to db.session.dirty. That resulted in an updated version of service being added to the service history table that showed no visible difference from that record immediately precending it as the change was to another table, namely the api_key table. A new api key or revoked api key was correctly added to api_key and api_key_history tables. However I think an 'unchanged' service history record may be a bit confusing as you'd need to correlate with api_keys to work out what the change was. I think it's best to just record the new/revoked api_key and not create another version of the service. This pr wraps the exisiting versioned decorator with one that take a class which you are interested in versioning. Using the new decorator you only get a new version and history record for the class you pass to outer decorator. If the exising behaviour is acceptable to the powers that be then by all means ignore/close this pr.
notifications-api
Notifications api Application for the notification api.
Read and write notifications/status queue. Get and update notification status.
Setting Up
mkvirtualenv -p /usr/local/bin/python3 notifications-api
Creating the environment.sh file. Replace [unique-to-environment] with your something unique to the environment. The local development environments are using the AWS on preview.
Create a local environment.sh file containing the following:
echo "
export NOTIFY_API_ENVIRONMENT='config.Development'
export ADMIN_BASE_URL='http://localhost:6012'
export ADMIN_CLIENT_SECRET='dev-notify-secret-key'
export ADMIN_CLIENT_USER_NAME='dev-notify-admin'
export AWS_REGION='eu-west-1'
export DANGEROUS_SALT='dev-notify-salt'
export FIRETEXT_API_KEY=[contact team member for api key]
export FIRETEXT_NUMBER="Firetext"
export INVITATION_EMAIL_FROM='invites@notifications.service.gov.uk'
export INVITATION_EXPIRATION_DAYS=2
export NOTIFY_EMAIL_DOMAIN='notify.works'
export NOTIFY_JOB_QUEUE='[unique-to-environment]-notify-jobs-queue' # NOTE unique prefix
export NOTIFICATION_QUEUE_PREFIX='[unique-to-environment]-notification_development' # NOTE unique prefix
export SECRET_KEY='dev-notify-secret-key'
export SQLALCHEMY_DATABASE_URI = 'postgresql://localhost/notification_api'
export TWILIO_ACCOUNT_SID=[contact team member for account sid]
export TWILIO_AUTH_TOKEN=[contact team member for auth token]
export VERIFY_CODE_FROM_EMAIL_ADDRESS='no-reply@notify.works'
export MMG_API_KEY=mmg=secret-key
export MMG_FROM_NUMBER="MMG
"> environment.sh
NOTE: the DELIVERY_CLIENT_USER_NAME, DELIVERY_CLIENT_SECRET, NOTIFY_JOB_QUEUE and NOTIFICATION_QUEUE_PREFIX must be the same as the ones in the notifications-delivery app. The SECRET_KEY and DANGEROUS_SALT are the same in notifications-delivery and notifications-admin app.
NOTE: Also note the unique prefix for the queue names. This prevents clashing with others queues in shared amazon environment and using a prefix enables filtering by queue name in the SQS interface.
To run the application
You need to run the api application and a local celery instance.
There are two run scripts for running all the necessary parts.
scripts/run_app.sh
scripts/run_celery.sh
scripts/run_celery_beat.sh