Clean up email templates logistics

[dleehr]

We have a few issues related to email templates (#91, #180, and #87). Additionally, recent changes (#171) added a required cancel template to emailtemplates.json, but we don't have documentation on what's required or how to load them. For deployment time, we should load data automatically (as we do in bespin).

Currently, the fixture doesn't load in my dev environment. We're not using the owner field, but may need it for #87.

[johnbradley]

Current migration and loading of a DukeDSEndpoint is handled in a run script:

D4S2/run.sh

Lines 12 to 22 in 0d3c200

	# 1. Wait for postgres to be ready
	until pg_isready -h "$POSTGRES_HOST"; do
	>&2 echo "Postgres is unavailable - sleeping"
	sleep 5
	done
	# 2. Run a django migration
	python manage.py migrate --noinput
	# 3. Create/Update DukeDS configuration
	python manage.py createddsendpoint "Duke Data Service" $D4S2_DDSCLIENT_URL $D4S2_DDSCLIENT_PORTAL_ROOT $D4S2_DDSCLIENT_AGENT_KEY $D4S2_DDSCLIENT_OPENID_PROVIDER_ID

This script is baked into the Docker image:

D4S2/Dockerfile

Line 28 in 0d3c200

CMD /app/run.sh

[johnbradley]

I tested in a clean environment and was able to load the example emailtemplates.json after migrating/creating a superuser: step 4 and 5 in README.md.

[dleehr]

The issue I had is of fragile foreign keys vs natural keys again (Duke-GCB/bespin-api#110).

D4S2/emailtemplates.json

Lines 10 to 18 in 6fd5d55

	"fields": {
	"body": "Hello {{ recipient_name }},\r\n\r\n{{ sender_name }} has shared a data set with you via the Duke Data Service. Please click the link below to preview the data set.\r\n\r\nDescription: {{ project_name }}\r\nPreview URL: {{ project_url }}\r\n\r\nAfter you have reviewed the data set, contact {{ sender_email }} or reply to this message to request a finalized copy.\r\n\r\nRegards,\r\n\r\nComputational Solutions\r\nDuke Center for Genomic and Computational Biology\r\n[email protected]\r\nhttp://www.genome.duke.edu/cores-and-services/computational-solutions",
	"owner": 1,
	"subject": "Duke Data Service share for {{ project_name }}",
	"template_set": 1,
	"template_type": 1
	},
	"model": "d4s2_api.emailtemplate",
	"pk": 1

Here we load email templates and assume that the user with id=1 should be the owner. While that's likely to be a superuser in a clean database environment, it's not generally a safe assumption.

So 3 thoughts I have:

1. We do not have any code that uses this owner field, so I likely added it prematurely for a use case that, while coming, we don't have yet. We could remove it and revisit later when it is needed.
2. In bespin-api, for example fixtures don't depend on other keys in the database, and the rest of the required data is created by manage.py commands (especially when populating credentials or identifiers). That's worked pretty well for different environments.
3. If fixtures are the right solution to this problem, perhaps it's a good time to try using natural keys, if only for this model? But I'm not convinced that fixtures are the best fit.

[johnbradley]

Talked with @dleehr about this in a meeting today.
Decided to not use a default and instead have a check to see if a user has a template setup.
If a user has no template show them an message with contact info so we can set it up for them.
We can use the UserEmailTemplateSet table to determine if a user has templates specified.
This will be the case for both the website and the CLI.

Additionally we will remove the example emailtemplates.json since it isn't particularly useful and has the limitations outlined above.
The database will be the source of truth for what user's templates are.