Issue #5660 open

Add a repository specific email header so that you can filter on it (BB-6925)

Kevin Hunter
created an issue

A quick < 3 minutes of perusing didn't see anything fruitful so in the bugs, but perhaps my search terms were wonky ...

I'd like to request that you add a header to project-generated emails. Maybe for comments it's something like:

List-Id: <project_name>+comment

Or for pull-requests, it's something like:

List-Id: <project_name>+pull_request

The bit after the '+' is not perhaps necessary, just nice. The important thing for my uses would be the ability to sort messages on something less crude than the content of the subject field.

Comments (7)

  1. Kevin Hunter reporter

    Hi Dylan,

    I recognize that you include that snippet in the subject field. The content of this request is very specifically an addition to the subject field: "... the ability to sort messages on something less crude than the content of the subject field."

    "Most people" may use this to filter, but there are cases where the subject field is inadequate. The most recent case, and why I submitted this bug report, was because sometimes repository messages spawn tangentially related email discussions with non-bitbucket crowds. If I sort on the Subject field, then as the replies go back and forth, I need to manually move those messages.

    This is not a matter of bitbucket doing anything wrong, per se, but a request for a very useful addition, and that allows for a more specific and clean workflow.



  2. Martin Geisler

    When I comment on a commit, Bitbucket creates a mail with

    Subject: Re: owner/repo the commit message (commit d213152)

    Having to filter out "Re:" is a little annoying — what else might Bitbucket use to prefix the subject lines in the future?

    Not filtering it out would mean matching on owner/repo which can be pretty generic, especially when the owner and repository names and equal and also used in paths (we often write our commit messags in the form package/module: what I did and here package is often equal to the owner and repository).

    So a dedicated header line would make much more sense — we're programmers and we know how to filter on arbitrary headers.

  3. Kevin Ballard

    I would very much like this feature. I use it extensively with GitHub for filtering my emails and I'm surprised Bitbucket doesn't have anything equivalent.

    It turns out the Message-ID of the email is almost sufficient. For a new PR it looks like Message-ID: <pr-organization/repo/>. I can use this to filter out new PRs for various organizations/repos. Unfortunately, for new comments on a PR it looks like Message-ID: <> which is rather useless for filtering.

    I also expect that there are other repository-related emails that may or may not have usable Message IDs, but I've only looked at PRs and PR comments for now.

    The best solution here is for Bitbucket to add various headers to provide proper filtering. GitHub has the precedent of using List-ID to indicate the organization/repo (e.g. List-ID: mozilla/rust <>). It also has a few X-GitHub-* headers to indicate various things (such as X-GitHub-Recipient to indicate the github user that's being emailed, and X-GitHub-Reason with a string that indicates why the email was sent). It would be great if Bitbucket could do something similar.

    But in the meantime, a workable solution would be to adjust the Message-IDs of Bitbucket's emails to provide the organization/repo information in them. PRs already look fine. PR comments could be something like Message-ID: <prcomment-organization/repo/>. Or to be slightly more useful it could be <prcomment-organization/repo/123/> (where 123 is the PR # and 456789 is the comment ID). Other repo-related emails would have to have a similarly useful Message-ID. Given a few known formats such as these I can write the filter I want.

    That said, the GitHub approach is better. Not only is it more obvious what's going on, but it's also more powerful. For example, I have an email filter that lets PRs into my inbox but files PR comments away into a folder, unless I've CC'd myself on the PR directly, at which point the comments go back into my inbox (this uses X-GitHub-Reason, which has no equivalent in the Message-ID workaround).

  4. Log in to comment