Hi, I am trying to set up todo.sr.ht instance, I already
have git, paste and lists all working well. However, I have
a problem with todo. I can create trackers fine, but individual
tickets do not get created. I write the ticket, and click on Submit,
the page just reloads and ends up with 400. I then checked the log.
First, I got an error about a missing contraint
```
2024/10/04 23:05:15 pq: constraint "subscription_ticket_participant_uq" for table "ticket_subscription" does not exist
```
which is strange, since the migrations all ran.
I've decided to try adding the constraints myself, but then I ended up
with (again on ticket creation): "Unexpected error in recover: <nil>"
Regards,
Rutherther
> ```> 2024/10/04 23:05:15 pq: constraint "subscription_ticket_participant_uq" for table "ticket_subscription" does not exist> ```
I ran into this issue when setting up my own instance using `todosrht-initdb`.
If you don't have anything to lose in the db I recommend rebuilding the
database for todo off of the schema.sql in the master branch [1].
[1]: https://git.sr.ht/~sircmpwn/todo.sr.ht/tree/master/item/schema.sql
Respectfully,
Lexie Malina
alex@t-ch.net
Lexie Malina <alex@t-ch.net> writes:
>> ```>> 2024/10/04 23:05:15 pq: constraint "subscription_ticket_participant_uq" for table "ticket_subscription" does not exist>> ```>> I ran into this issue when setting up my own instance using `todosrht-initdb`.> If you don't have anything to lose in the db I recommend rebuilding the> database for todo off of the schema.sql in the master branch [1].>> [1]: https://git.sr.ht/~sircmpwn/todo.sr.ht/tree/master/item/schema.sql>> Respectfully,> Lexie Malina> alex@t-ch.net
Hi Lexie,
thank you. I already tried that as well, twice, as I don't have anything to
lose, but no luck. I tried once more now and still the same error with
unexpected error in recover. The problem is that I don't know how
to get more information about this error, when it says only <nil>.
So, after some time the error message got better.
I get "Invalid mail configuration.", which is much
better as I can grep the source for that.
Turns out, smtp-user is required. I did not have
that set as I have a localhost smtp server just
for sr.ht instances that doesn't need authorization.
And it sounded like smtp-user is only used for auth.
Could this maybe be documented, or the message be rewritten
to be more clear? There are three cases for 'Invalid mail configuration'.
And does it even make sense to always use smtp-user for the sender's
address? I can imagine there are cases where user would like to set that
to something else.
Regards,
Rutherther
"Drew DeVault" <drew@ddevault.org> writes:
> I would welcome patches to make the mail server configuration a bit more> flexible.
Okay, so I wanted to get into that today. But I am facing a problem,
because I seem to not understand the reason for usage
of this Sender field. I checked how lists.sr.ht solves this and see
that it uses the list address as Sender field. But if lists does that
and not put in the smtp user, why would todo.sr.ht have to put in
the smtp user / something else and not just use what is in From?
(and at that point no Sender header is necessary if it becomes the
same as From as far as I know)
So it seems to me that either
1. lists.sr.ht handles this wrongly, and should support a way to
set the sender so that the sending e-mail server doesn't think
it's a forgery it cannot send (for those who need it)
2. todo.sr.ht should be fine with no Sender header.
Am I missing something here?
If I am not missing anything, I personally think this path is the best:
- Add smtp-sender option under mail in the config.ini.
- If smtp-sender is set, set Sender header to that (both todo and lists)
- If it is not set, in lists set sender to the list address, in
todo, do not set sender at all
Which will allow users that need this Sender header so that
their sending e-mail server doesn't think it's a forgery
that cannot be sent from their e-mail address.
And I think most users will not use Sender header in todo as
if their e-mail server can send the lists in their
current state, it should also be fine to send todo
e-mails without sender being set to the smtp user.
I submitted a patch for better messages for the time being.
I don't remember off the top of my head why the email configuration is
designed the way that it is. I'd recommend doing a quick survey of how
SourceHut uses these configuration options in practice, and then based
on that plus your best judgement coming up with a more coherent
approach. Email-related code in *.sr.ht has undergone a number of
incremental changes over the years but it might be due for a more
holistic re-evaluation by now.
On Tue Mar 11, 2025 at 4:11 PM CET, Rutherther wrote:
> If I am not missing anything, I personally think this path is the best:> - Add smtp-sender option under mail in the config.ini.> - If smtp-sender is set, set Sender header to that (both todo and lists)> - If it is not set, in lists set sender to the list address, in> todo, do not set sender at all
To specifically address the case of the Sender header, I think the
scenario most conformant to conventions/expectations is that, because
todo.sr.ht sends emails on behalf of users submitting tickets or
comments, we do something like the following:
Sender: sourcehut todo <noreply@sr.ht>
From: ~jdoe <noreply@sr.ht>
todo.sr.ht also needs a Reply-To header so that replies are directed to
the tracker/ticket in question rather than noreply@sr.ht.
Emails from e.g. meta.sr.ht, by contrast, don't need a Sender header
because the sender (meta.sr.ht) is sending emails on its own behalf.
For lists.sr.ht, it should add Sender when forwarding emails from users
to mailing list subscribers, and for its automated emails for
subscribe/unsubscribe and such it should set From to itself and omit
Sender. None of these emails should include Reply-To.
The config file should have whatever fields are most appropriate to
support all of these behaviors. Could have smtp-sender option, or could
assemble a sender header from somewhere else.
The set of headers that should be included for a given email is not a
policy question, so shouldn't be driven by the config -- i.e. the
presence or absence of a Sender header should not be configurable, but
the value of that header should be.
What you are saying makes sense to me. But it is not the case from would be set to user in this case where I got the error. The From is set to todo.sr.ht::notify-from. That is why I am so confused by the need of Sender header in this case. Yes there seem to be other instances that are like you say and there Sender header makes sense to me.
What I am talking about specifically is what is in api/graph/events.go in function SendEmails that doesn't send e-mails 'on behalf' of someone, but from the notify-from.
In my opinion the Sender should be set to the notify-from option rather than the smtp user by default, and be overridable by a separate option. Because as I reasoned, if the mail server accepts Senders used in lists.sr.ht (being the emails of the lists, not the smtp user), why would it not receive Sender of todo's notify-from?
What I described is not what the code is currently doing -- again, I am
not immediately familiar with it off the top of my head -- but my
understanding of the ideal/most correct approach. If reality does not
align with what I described, reality should be modified accordingly, via
your patch. If there are things that set Sender today but shouldn't,
then drop it; if there are things that ought to but don't, add it.
I see. I just misunderstood. Thanks for the clarification. I will try to get to that soon. I agree with everything in the ideal case you described, I see it the same way.