Even though it is rarely used, the full format of the Message-ID header
is (grossly simplified): "Comment to be ignored <actual@message.id>",
similar to an address. Parsing this as address will still be a bit too
lax (it would accept quoted string literals on the left-id side), but
it's at least much better than the current approach.
In commit 8a3c9b63b9 ("Include an
In-Reply-To: <Message-ID of triggering e-mail>, if any,
in the new_ticket notification") on 2020-07-17,
I made it so the return mail for a ticket submission
is a reply to the submission.
commit dee9e75762 ("todosrht-lmtp:
Use GraphQL for ticket submission") on 2022-04-05 deletes this.
Why? Unclear. The patch submission in
https://lists.sr.ht/~sircmpwn/sr.ht-dev/%3C20220405161354.11100-1-me%40adnano.co%3E
says this is the case but doesn't try to justify or rectify it.
Why? Unclear. Add it back because this is basic functionality.
Assigning user that is already assigned causes unhandled GraphQLError.
This commit adds validation that the user is not assigned.
References: https://todo.sr.ht/~sircmpwn/todo.sr.ht/275
Currently the JSON export does not set the `from_ticket` field for
events of type TICKET_MENTIONED. This commit implements writing out the
data as described in the legacy API docs:
https://man.sr.ht/todo.sr.ht/api.md#event-resource
Note that currently these events are not imported anyways (never have
been).
it's possible to create a tracker with an empty description, but not
edit a tracker to have an empty description.
the rewrite lambda turns empty strings into None, resulting in
descriptions being never updated if it's empty.
We were checking the owner when updating the import_in_progress
column, but we were starting off the import even if the tracker
didn't exist or didn't belong to the user.
There are currently two cases that cause the export function to panic.
The first one happens, when the authenticated user does not have the
permissions to access the tracker. In that case the TrackersByID loader
returns nil, so we have to check for that.
The second one can happen for tickets that got mentioned by other
tickets. In that case event.Participant is nil. That is caused here in
tickets.py [1] where participant is only filled for user and
not for ticket mention events.
[1]: c2a87f590d/item/todosrht/tickets.py (L283)
Fixes the following error:
panic: pq: null value in column "id" of relation "user" violates not-null constraint
user.id is not a serial, it's an integer not null. Thus we always
need to specify it when inserting to the table.
Unify all sending of notification emails in the newly added meta.sr.ht
`sendEmail` mutation, which works for both registered users and email
paritcipants.
valid.Error should only be used for form field errors which might be
shown to the user on the frontend. Since there is no userId field, the
error will not be surfaced, so use errors.New instead.
This commit implements the sending of event notification emails via the
meta.sr.ht GraphQL API, which will cause the emails to be properly
signed and potentially encrypted (according to the recipients privacy
settings).
Almost the entire SendEmail function had to be modified (though much of
it only moved). While doing so, a few minor issues were discovered and
also fixed:
* The check `if len(name) == 0 || len(address) == 0` was used to filter
out "external" participants, but it also filtered out "email"
participants that happened to not use a name in their From-header;
fixed by checking the participant type as stored in the DB instead
* In the query for the event participants, the name of "email"
participants was `Scan()`ned into a `string`, but it can be `NULL`;
fixed by coalescing with empty string
* Removed the last usage of Squirrel in this file
This moves handling of (potentially) encrypted emails into the
meta.sr.ht API. Emails to external addresses are still sent
(unencrypted) via the core.sr.ht Pyhon module.