Commit Graph

14 Commits

Author SHA1 Message Date
Pea Tyczynska
5cf6e1cf72 Persist simple polygons in the db.
They are being sent over from admin, and persisted
in the db so we can send them on to the broadcast
provider later on.
2020-09-07 15:52:14 +01:00
Leo Hemsted
2e8a7c2444 move dao_create/dao_update fn to dao_utils
they're totally generic anyway
2020-08-14 17:41:44 +01:00
Leo Hemsted
bdf2253298 send broadcast events rather than messages
use the new endpoint from cbc proxy. create a new task that just
serializes the event and sends it across rather than sending a template
and the broadcast message.

some changes to serialize to make it json friendly etc. it also expects
sent_at and transmitted_finishes_at to always be set (we set them in the
code but don't enforce it n the DB right now), as they're required by
utils template. not sure whether we'll update db constraints to be more
strict or utils template to be more permissive just yet, wait until we
find out more about the requirements of the CBCs we integrate with.
2020-08-14 17:41:44 +01:00
Leo Hemsted
6fda3707a3 save broadcast events when sending a message, also send cancel messages 2020-08-14 10:47:28 +01:00
Leo Hemsted
05791f22a6 allow trial mode service users to approve their own broadcasts
we won't let trial mode services send real broadcasts, and it's helpful
for users to see the flow of messages without having to have a second
person with them
2020-08-06 11:15:49 +01:00
Leo Hemsted
fb2910fb08 replace abort with raise InvalidRequest
it's slightly clearer that it will immediately raise an exception and
back out of the current function
2020-07-27 15:54:31 +01:00
Leo Hemsted
483221df7d add broadcast message status transition map
be explicit about which transitions we allow. this is not necessarily an exhaustive list of everything we'll allow
2020-07-27 15:51:16 +01:00
Leo Hemsted
4043e8fa5e reject approvals from people outside your service
even if they're a platform admin
2020-07-27 15:51:16 +01:00
Leo Hemsted
b8e6689f62 allow platform admins to approve their own messages
makes development a lot easier. we should remove this when we go live
2020-07-27 15:51:16 +01:00
Leo Hemsted
8af112d885 refactor status updating into its own function
before it gets mega complex
2020-07-27 15:51:15 +01:00
Leo Hemsted
8dda1a5123 forbid editing after broadcast message goes live
only allow editing while in:

* draft
* pending-approval
* rejected (not too sure if/how this'll be used, so easier to include it
 for now)
2020-07-27 15:51:15 +01:00
Leo Hemsted
403885722e trigger send_broadcast_message task when user approves
lets leave the cancellation can of worms alone for now
2020-07-09 18:23:30 +01:00
Leo Hemsted
6b5e2af497 set finishes_at correctly
whoops
2020-07-09 15:36:08 +01:00
Leo Hemsted
67f6dcae45 add broadcast message crud
new blueprint `/service/<id>/broadcast-message` with the following
endpoints:

* GET / - get all broadcast messages for a service
* GET /<id> - get a single broadcast message
* POST / - create a new broadcast message
* POST /<id> - update an existing broadcast message's data
* POST /<id>/status - move a broadcast message to a new status

I've kept the regular data update (eg personalisation, start and end
times) separate from the status update, just to keep separation of
concerns a bit more rigid, especially around who can update.

I've included schemas for the three POSTs, they're pretty
straightforward.
2020-07-09 14:19:56 +01:00