migrations/versions/0362_broadcast_msg_event.py

"""

Revision ID: 0362_broadcast_msg_event
Revises: 0361_new_user_bcast_permissions
Create Date: 2020-12-04 15:06:22.544803

"""
import sqlalchemy as sa
from alembic import op
from sqlalchemy.dialects import postgresql

revision = "0362_broadcast_msg_event"
down_revision = "0361_new_user_bcast_permissions"


def upgrade():
    op.add_column(
        "broadcast_message",
        sa.Column("cap_event", sa.String(length=255), nullable=True),
    )


def downgrade():
    op.drop_column("broadcast_message", "cap_event")
Store the `event` field from CAP XML broadcasts We don’t store everything that comes in the CAP XML when someone creates a broadcast via the API. One thing we do store is `<identifier>` (in a column called `reference`) which is a unique (to the external system) identifier for the broadcast. We show this in the front end instead of the template name, because broadcasts created from the API don’t use templates. However this ID isn’t very friendly – the Environment Agency just supply a UUID. The Environment Agency also populate the `<event>` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an area code which will be meaningful to the Flood Warning Service team) We should show this in the UI instead of the reference. The first step towards this is storing it in the database and returning it in the REST endpoints. Later we can have the admin app prefer `cap_event` over `reference`, where `cap_event` is present. We can’t backfill this data because we don’t keep a copy of the original XML. Seems like `<event>` is a mandatory property of `<info>`, so we don’t need to worry about the field being missing (`<info>` is optional in CAP but we require it because it contains stuff like the areas which we need in order to send out the broadcast`). *** https://www.pivotaltracker.com/story/show/176927060 2021-10-18 11:42:18 +01:00			`"""`

			`Revision ID: 0362_broadcast_msg_event`
			`Revises: 0361_new_user_bcast_permissions`
			`Create Date: 2020-12-04 15:06:22.544803`

			`"""`
			`import sqlalchemy as sa`
black, isort, flake8 Signed-off-by: Cliff Hill <Clifford.hill@gsa.gov> 2023-12-08 21:43:52 -05:00			`from alembic import op`
Store the `event` field from CAP XML broadcasts We don’t store everything that comes in the CAP XML when someone creates a broadcast via the API. One thing we do store is `<identifier>` (in a column called `reference`) which is a unique (to the external system) identifier for the broadcast. We show this in the front end instead of the template name, because broadcasts created from the API don’t use templates. However this ID isn’t very friendly – the Environment Agency just supply a UUID. The Environment Agency also populate the `<event>` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an area code which will be meaningful to the Flood Warning Service team) We should show this in the UI instead of the reference. The first step towards this is storing it in the database and returning it in the REST endpoints. Later we can have the admin app prefer `cap_event` over `reference`, where `cap_event` is present. We can’t backfill this data because we don’t keep a copy of the original XML. Seems like `<event>` is a mandatory property of `<info>`, so we don’t need to worry about the field being missing (`<info>` is optional in CAP but we require it because it contains stuff like the areas which we need in order to send out the broadcast`). *** https://www.pivotaltracker.com/story/show/176927060 2021-10-18 11:42:18 +01:00			`from sqlalchemy.dialects import postgresql`

reformat 2023-08-29 14:54:30 -07:00			`revision = "0362_broadcast_msg_event"`
			`down_revision = "0361_new_user_bcast_permissions"`
Store the `event` field from CAP XML broadcasts We don’t store everything that comes in the CAP XML when someone creates a broadcast via the API. One thing we do store is `<identifier>` (in a column called `reference`) which is a unique (to the external system) identifier for the broadcast. We show this in the front end instead of the template name, because broadcasts created from the API don’t use templates. However this ID isn’t very friendly – the Environment Agency just supply a UUID. The Environment Agency also populate the `<event>` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an area code which will be meaningful to the Flood Warning Service team) We should show this in the UI instead of the reference. The first step towards this is storing it in the database and returning it in the REST endpoints. Later we can have the admin app prefer `cap_event` over `reference`, where `cap_event` is present. We can’t backfill this data because we don’t keep a copy of the original XML. Seems like `<event>` is a mandatory property of `<info>`, so we don’t need to worry about the field being missing (`<info>` is optional in CAP but we require it because it contains stuff like the areas which we need in order to send out the broadcast`). *** https://www.pivotaltracker.com/story/show/176927060 2021-10-18 11:42:18 +01:00

			`def upgrade():`
reformat 2023-08-29 14:54:30 -07:00			`op.add_column(`
			`"broadcast_message",`
			`sa.Column("cap_event", sa.String(length=255), nullable=True),`
			`)`
Store the `event` field from CAP XML broadcasts We don’t store everything that comes in the CAP XML when someone creates a broadcast via the API. One thing we do store is `<identifier>` (in a column called `reference`) which is a unique (to the external system) identifier for the broadcast. We show this in the front end instead of the template name, because broadcasts created from the API don’t use templates. However this ID isn’t very friendly – the Environment Agency just supply a UUID. The Environment Agency also populate the `<event>` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an area code which will be meaningful to the Flood Warning Service team) We should show this in the UI instead of the reference. The first step towards this is storing it in the database and returning it in the REST endpoints. Later we can have the admin app prefer `cap_event` over `reference`, where `cap_event` is present. We can’t backfill this data because we don’t keep a copy of the original XML. Seems like `<event>` is a mandatory property of `<info>`, so we don’t need to worry about the field being missing (`<info>` is optional in CAP but we require it because it contains stuff like the areas which we need in order to send out the broadcast`). *** https://www.pivotaltracker.com/story/show/176927060 2021-10-18 11:42:18 +01:00

			`def downgrade():`
reformat 2023-08-29 14:54:30 -07:00			`op.drop_column("broadcast_message", "cap_event")`