we can back-fill data, however, between alembic running and the api
updating to the new code, it'll still try and create new users without
adding the auth_type, because that won't be referenced in the model yet.
Instead of using a python-level default, a postgres-level
server_default will make postgres set every row to sms_auth if it's not
defined in the application.
> So that we can default services to their appropriate text allowance,
> we need to find out what sector they're in. So let's start collecting
> that from teams as they create new services.
In order to work out what a team’s allowance should be, we need to know
what part of government they’re from. We’re going to do this logic in
the admin app and then `POST` the allowance to the API.
So all we need to do with the information that the users give us is
store it against the service, so we have a record. Doesn’t need any
logic doing as a result of it, doesn’t need foreign keying to the
organisations table, etc.
Added an extra name, 'org_banner', for branding types into branding_type table
Added org banner into user model in database
Added checks for new branding type to ensure that the correct data is passed into the dict
Tested new checks in html email options
Right now Notify restricts you to registering with a UK mobile number.
This is because when we built the user registration stuff we couldn’t
send to international mobiles.
However we can send to international mobile numbers, and it’s totally
reasonable to expect employees of the UK government to be working
abroad, and have a foreign mobile phone – we’ve heard from one such
user.
In order for users of Notify to register with an international phone
number, the Notify service needs to have the `international_sms`
permission set. Which this service does, as a data migration.
More migrations got merged in between me making 0114 and merging the PR
that contained 0114.
If we named the files as just 0114.py then this would get flagged as a
merge conflict…
Since letter jobs from the API aren't created by any single individual,
lets make created_by nullable. Note: We'll have to make sure that we
update the admin app to handle these jobs nicely
- The new task has not been added to the beat application yet.
- Added an updated_at column to the monthly billing table, we may want to only calculate from the last updated date rather than the entire month.
