Facilitate visual comparison with the 'reference impl' (slack).
The service backends do heavy copy/pasting, good to keep the beast
in check by at least limiting the changes to the bits that actually
diverge
W.r.t. the user-contributed version, this:
* removes commented-out code
* removes channels (not supported at the UI level)
* removes all other things
Said differently: the mattermost Alert Service Backend is simply the Slack version
with edits to make it mattermost-specific (and nothing else).
(In a few places I've edited the slack backend to make comparing easier).
Fix#277
See #253
we now have handling for them, no need to keep seeing them as stacktraces.
also: in the EAGER setup, raising means the transaciton is rolled back,
and nothing is stored in the DB at all.
if we ever want to 'get more info' something like capture_or_log_exception
would be more apt
Like e45c61d6f0, but for .project.
I originally thought `SET_NULL` would be a good way to "do stuff later", but
that's only so the degree that [1] updates are cheaper than deletes and [2]
2nd-order effects (further deletes in the dep-tree) are avoided.
Now that we have explicit Project-deletion (deps-first, delayed, properly batched)
the SET_NULL behavior is always a no-op (but with cost in queries).
As a result, in the test for project deletion (which has deletes for many
of the altered models), the following 12 queries are no longer done:
```
SELECT "projects_project"."id", [..many fields..] FROM "projects_project" WHERE "projects_project"."id" = 1
DELETE FROM "projects_projectmembership" WHERE "projects_projectmembership"."project_id" IN (1)
DELETE FROM "alerts_messagingserviceconfig" WHERE "alerts_messagingserviceconfig"."project_id" IN (1)
UPDATE "releases_release" SET "project_id" = NULL WHERE "releases_release"."project_id" IN (1)
UPDATE "issues_issue" SET "project_id" = NULL WHERE "issues_issue"."project_id" IN (1)
UPDATE "issues_grouping" SET "project_id" = NULL WHERE "issues_grouping"."project_id" IN (1)
UPDATE "events_event" SET "project_id" = NULL WHERE "events_event"."project_id" IN (1)
UPDATE "tags_tagkey" SET "project_id" = NULL WHERE "tags_tagkey"."project_id" IN (1)
UPDATE "tags_tagvalue" SET "project_id" = NULL WHERE "tags_tagvalue"."project_id" IN (1)
UPDATE "tags_eventtag" SET "project_id" = NULL WHERE "tags_eventtag"."project_id" IN (1)
UPDATE "tags_issuetag" SET "project_id" = NULL WHERE "tags_issuetag"."project_id" IN (1)
```
most important change: 'New issue' from start of the subject to its end.
This was prompted by getting flooded with 'New issue' emails, but you
want to know _what_ first.
The cost/benefit says "this is simply not worth it".
It's yet another thing that could break. In ways that are not obvious to me.
(html) email sending is hard enough as it stands.
