Closed Bug 239343 Opened 16 years ago Closed 16 years ago
no way to send bugmail from the shell
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040325 Build Identifier: Bugzilla 2.17.4 removed the "processmail" script, as its functionality was incorporated into the Bugzilla::BugMail perl module. However, the processmail script was useful in its own right as a mechanism for sending bugmail from the shell. This was useful for administrators making manual database changes, or fixing up a bugmail failure. It was also useful for third-party software which integrates with Bugzilla by directly touching the database. For instance, the P4DTI <http://www.ravenbrook.com/project/p4dti/>. Reproducible: Always Steps to Reproduce: 1. Try to send bugmail from the shell. You can't!
Here is my basic Perl script to invoke BugMail from the shell. Add it to a Bugzilla directory and invoke it as: ./bugmail.pl bug_id userid [cc_login cc_login ...] Very poor input validation at present, and probably all sorts of other problems.
A modified bugmail script which passes the user by email address instead of ID. This is the interface expected by BugMail::Send(). Also modified not to take cc addresses, as these aren't required by the P4DTI.
Attachment #145252 - Attachment is obsolete: true
Assignee: justdave → Nick.Barnes
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Bugzilla 2.18
Comment on attachment 149338 [details] Modified bugmail.pl script Can this go in the tree with this license? I was thinking this was worth throwing in the main tree, but I'm thinking it probably needs to be in contrib with this license.
The license is looser than the MPL, and so normal mozilla.org policy is that it would be allowed in a main tree (compare with, for example, libpng in the Mozilla tree.) However, it would be nicer to keep all of main Bugzilla under exactly the same license. Slippery slope, and all that. Nick: would you be willing to make this script available under the MPL? This would have the effect of putting file-level copyleft provision on it; I don't know if that's something you'd see as good or bad. Gerv
We have asked the copyright holder, Perforce Inc, for permission to change the license to the MPL. In my opinion, this script, as it stands, is (a) trivial to rewrite, and (b) not really good enough for production use. A Perl hacker needs to write some validation code for it, and maybe extend it to take additional arguments (such as -forcecc). Also (c): the current attachment is broken; I say "$changer = ..." and then "'changer' => $userid;". This dates from when I thought BugMail::Send took userIDs rather than email addresses and so I looked up the user ID. I took out that code but didn't fix the call to Send. Doh! I'll post a new version.
Here's a new version of the script, this time with argument validation. Still no -forcecc etc.
Attachment #150184 - Attachment is obsolete: true
Thinking about how this gets used... this is really a utility script, and Bugzilla itself doesn't actually use it. We should probably go ahead and stick this in contrib (there are other similar things in there already). For it to work from there, you'd need a "use lib qw(..);" stuck near the top.
Well, it does work from contrib with use lib qw(..); our test suite runs OK. I did have it as an executable script, with a change to checksetup in order to get the execute bit set. I've changed that so that the P4DTI invokes it as "perl contrib/bugmail.pl", rather than "./bugmail.pl". Then we don't need to patch checksetup (but we do need to make sure that perl is on the path of whoever invokes the P4DTI scripts).
checked in: Checking in README; /cvsroot/mozilla/webtools/bugzilla/contrib/README,v <-- README new revision: 1.10; previous revision: 1.9 done RCS file: /cvsroot/mozilla/webtools/bugzilla/contrib/sendbugmail.pl,v done Checking in sendbugmail.pl; /cvsroot/mozilla/webtools/bugzilla/contrib/sendbugmail.pl,v <-- sendbugmail.pl initial revision: 1.1 done I renamed the script to sendbugmail.pl to avoid confusion with "bug_email.pl" in the same directory, which accepts inbound email. I also updated the version requirements in the comments at the top to state version 2.17.4 or newer (to prevent people from being scared to use it in 2.18, since that's not 2.17.7 :) Those were my only changes.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.