> If I'm correct, yours is in addition to the +1s in comment #3, comment #6, comment #19, and comment #23 here, and the duplicate sr #107431.

You are entirely correct; please record me as +1 for this request and thanks for pointing out that the phrasing was unclear.

Hi!

+1 from me.  It's the least comfortable bug tracker I have to deal with, as I get new comments by email, but then I have to log in to reply.

And I like the idea of using PGP signatures to authenticate the sender (while possibly allowing unsigned email as anonymous senders) very much.

Dave and I were discussing about it here:
<https://lists.gnu.org/archive/html/bug-groff/2024-03/msg00054.html>

Have a lovely day!
Alex

Reopening; as Karl has pointed out there is neither history nor comments explaining when/why this was closed.  At a minimum the rationale for closing should be documented and a final status set.  In fact, I think we not only need to do this but that's it is a fairly high priority (for a wish-list item), so I've made that change also.

May I add my voice to those desiring such a feature? It's much easier to reply by writing an email than to use the Savannah web interface.

Forgot to add: My personal impression is that dropping the Savane trackers should be completely out of the question, and it was never considered, IIRC.  Sylvain can tell for sure.

Some projects (e.g. GNUstep) actually like them.

Implementing this feature requires someone with sufficient PHP skills and willingness to dive into Savannah's internals.  Integration with external bug trackers might be even more difficult, I suspect, although it's worth considering since it would be a very nice feature.

there is a dupe for this: sr #107431
any chance this will be implemented?
actually, it would seen that dropping the integrated savanna bug tracker in favor of a specially designed external tool (bugzilla or debbugs) which would allow both web forms and email seems to be the best approach.
why reinvent the wheel? just outsource!

> Do you think that the instant handling of messages is a mandatory feature?

I think every few minutes would be ok, though not ideal.

At any rate, I'm afraid I have no clue how to implement anything like this in php.  So if we can't separate the mail receiving from the savannah injection, I guess it just remains on the wishlist.

Thanks,
Karl

I realized last night that savannah doesn't handle incoming mail locally, as far as I know.  So I don't see how the mail handling and web application can run on the same host?

If we can do the separation, we could make an alias on fencepost, where mail does get processed.  Handle the mail there and invoke a cgi on savannah with the info.

I can write the mail handling script, but not in php ...

Thomas -- I don't see a problem with requiring logged-in users to post or follow up.  In fact, I think that should be the default.

There is no requirement in GNU that projects use a tracker at all, and lots don't.  OTOH, there is a requirement that projects accept bugs through email (although not everyone follows it, sadly enough).  So if a user wants to submit a report without registering anywhere, they can (should be able to).

Allowing all anonymous posts would be like allowing unfiltered email.  Not feasible ...

I have no objection to the idea of allowing anonymous posts if they are filtered as rigorously as we do with email, but I also don't think it's necessary, or especially beneficial, actually.
Anyone who wants to post through a tracker is going to expect to create an account.

For the the server-side part i believe that one possible implementation could be the following:
1.- Set up a cronjob, following the structure of the ones currently running, that connects to the receiving email account using a regular perl's/php's (depending on the language used for the cronjob) pop3 library.
For each message found there:
2.- Retrieve the message and delete it from the account
3.- Check if it is correctly composed (including authentication)
4.- If it passes the previous test, check some kind of antispam rules
5.- If it passes the previous test, insert the information in the database
After processing all the messages maybe write a log.

For point 5, and trying to reuse the current scripts without repeating code, i think that the most straight path is to create a http post request equivalent to the one created by the form and feed it to "/task/index.php" (the 'action' of the tracker's form). In my opinion, other option could be to factorize the controller and model layer code at "frontend/php/include/trackers/index.php" and "frontend/php/include/trackers_run/index.php" to be used by both the script code of the cronjob (in this case perhaps the cronjob could be written in php instead of perl) and by "frontend/php/task/index.php" (that is actually using it).

In order to allow a stronger spam control, the inserted data could be somehow marked, so that it could be easily retrieved and managed.

What do you think?

To the best of my knowledge, it is possible to configure trackers such that only logged-in users can post or follow-up.   At least I sure remember doing this for my projects.  I hope that is even the default now.

Perhaps an X-Savane-User: karl
header would be enough authentication :).

It's the "inject it somehow" that stymies me, I'm afraid ...

I second this wishlist request -- the web-based trackers is something I dislike in Savannah.  I have the feeling that the implementation would be far from trivial.

FTR, debbugs has no authentication.  Everyone can send messages and can manipulate the control bot.  Although scary at first glance, this has worked well for many years.  There is spam, of course, and spam mesages are manually deleted from the database when users report them.  Bugs are archived in 28 days after they are fixed, and then all mail to the bug is rejected (everyone can "unarchive" a bug with a control message, though).

If doable, GPG-signed messages would be less of a nuisance than filling the web forms.  I guess that it won't be automatically usable for most of the users (as they'll have to register their GPG key), but that's OK.

Hi,

I have always found this very interesting (sending a mail with instructions to one machine), but probably i don't have the required skills to accomplish it either ;)

Anyway we could think about the requirements of the application. For the mail message to be understood, i think that it must have a well defined, and therefore recognizable, structure. That is, only well-formed messages could be parsed and understood. In my opinion this leads to the rejection of most kinds of spam, if the rules avoid tokens like 'viagra' or 'enlarge' :). But has the side effect of make more dificult the creation of messages: the sender has to be aware of the rules, and must compose the message following them. I don't know if it could be possible to develop a kind of mode in emacs for this to be done.

This reminds me of the debian's 'reportbug' utility, i'm not very familiar with it but as far as i know it asks you some questions about the request and finally sends a well-formed mail message with the required structure to be understood by the receiving system, please correct me if i'm wrong.

What do you think?

Cheers,
Federico