In T12240#211112, @epriestley wrote:

To jump back further, the root-ier cause is that you're using mailing lists?

If we implemented T3980, could you create projects for mailing lists instead of "Mailing List" users, then do one-mail-per-recipient + private-replies and be generally OK?

T11050 describes a way you could work around this issue in some cases in the future, by resigning from the review (basically, saying "I'm not going to review this on behalf of Project 1 because user B is on top of it, so get it out of my queue"). That doesn't help if you want it in your queue but just not in the "Must Review" bucket.

Thanks for the report, and for including detailed reproduction steps. The were very helpful in reproducing and fixing this issue.

If you want to implement the rest of it with a ( trigger I can counter-diff you for a (( trigger.

the trigger was the main thing preventing me from implementing phurl

(D17331 should fix the outdated discussion of the option in Config.)

In the specific case of Phurl autocompletion, I'd be happy to review a change if someone wants to tackle it. The recent emoji autocompletion is probably a pretty good example to start from.

(It's still not possible to name a link X | Y, but I think we're no longer aware of any reasonable cases where this is important.)

I belive this was effectively resolved by changes connected to T7691. Specifically, if you had a page titled "A" at location "x", you previously needed to type [[ x | A ]] to get it to render the right link text. If you omitted the ... | A ... part, the link would just be named x.

In T5301#210596, @DemiMarie wrote:

What about triple backticks in code blocks? Code blocks can contain
anything, so I consider not being able to put three consecutive backticks
in them a bug.

Commentary on this is welcome, even just to say no it won't fly.

I think this is the same as T11543 but I'm going to merge that here since this one is a little cleaner. My current thinking:

haha good 🐱 👍

I imagine that the rest of the process will work like this:

AWS got back to me with essentially a form response that didn't address any of the particulars of our case.

In exchange, here is a cat on a mat trying to do some yoga. Not my cat, but she was at an airbnb I stayed at and my decision to not steal her came down to a coin toss

that's a great pup. 10/10

@pmatos, Have you seen the Providing Reproduction Steps page? What kind of instructions can we add to it to make it better?

@epriestley I understand it's upsetting for someone to report a bug like I did. The problem here is that having no experience with Phabricator internals or webapps, I have no clue how to even give you the slightest hint of how to reproduce. For example, in my case, I got as I mentioned a problem with the daemons. I needed some further help from your side to actually create a bug report that actually helps you.

Going to pass on this functionality as I think with the new configurable sidebar we're in a much better position. I'd rather keep adding features to it.

You're correct, using brackets makes the regex work, thanks.

For starters, this regex fails to work

In T5301#149071, @epriestley wrote:

T5397 is another copy of the pipes-in-tables issue.

You can use remarkup.ignored-object-names to prevent S3 from being marked up: S1 S2 S3 S4

This would be helpful; post-T4900: Workboards updating in real time this would let the workboard be a broadcast mechanism of progress on an office screen, for instance.

Sometimes people will "Reply All" and everyone will get two mails, one from the user and one from Phabricator turning their mail into a comment.

To jump back further, the root-ier cause is that you're using mailing lists?

In T12240#211108, @epriestley wrote:

Oh, I didn't even realize that was a thing. I assumed SMTP went like "okay here is a message: <message body>".

I don't think we have control over the SMTP envelope for at least some of of the APIs we implement, although perhaps I'm mistaken. In some cases I chose the non-SMTP version of things (e.g., POST some JSON) when an SMTP version was available since I mostly know how JSON works but do not mostly know how SMTP works. It's possible we could revisit those decisions and do more SMTP to get greater access to envelopes, although I'd guess not all adapters provide us envelope access.

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user.

We already attempt to do this -- are you seeing it not work in practice? Rough pathway is:

Oh, I didn't even realize that was a thing. I assumed SMTP went like "okay here is a message: <message body>".

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user. Of course, given the above, this is spoofable.

Unless I'm missing something, I think the instructions here cause X to receive two mails (they are on "To" for both).

Why is it important to see all the duplicates at a glance?

Here is a picture from this morning but she was a little confused that we were wasting time taking pictures (boring) instead of going straight to daycare.

Or, more generally, if we send two mails:

I think you don't need to rebuild the search index for that to take full effect. Although rebuilding it will change the content in the index in some cases, the new, more-tailored queries should match either version.

We transform x y into +"x" +"y" in the general case, but currently apply stemming to "a_b" and "c.d". This is because it's generally correct to stem "x-y", which is usually a hyphenated English phrase rather than a "constant" or "token", and correct to stem "z.", which is usually something copy-pasted with a stray period, not an intent to search for a token ending with a period, and the cases of "_" and "." got lumped in with those.

Interestingly, phabricator_maniphest maniphest_transaction gives zero results but "phabricator_maniphest" "maniphest_transaction" works. Seems like the underscores are a problem as much as the period.

Maybe phabricator should automatically try adding quotes to a search if the initial query returns zero results?

• We no longer send normal mail to unverified addresses. Consequently, mail sent between creating an account and that user verifying their address (for example, assigning them tasks) is now dropped.
• We no longer send "sorry, we ignored your mail because we don't recognize the address" replies if we don't recognize the sender, unless phabricator.allow-email-users is set.
  • I would like to eventually (post-Nuance?) remove this option, stop allowing "email users", and move away from "grey users".
• We no longer send a misleading error about "no default user" if an application address is not configured with a default user.
• This install now delivers outbound mail through Mailgun instead of SES.
• The queued backlog appears to have flushed.

Unfortunately, this is so far afield from our roadmap that we don't have room for this year, even under paid prioritization.

• I think this sends the recipients many copies of the email, particularly if they are on mailing lists? Why do you believe that users will receive only one copy of the mail if we send ten messages with their address in "To"?
• Are you sure "Reply-To" overrides "Reply All" in all major clients? I haven't tested this personally, but I can't immediately find any references to this behavior on Google. I believe we already use "Reply-To", so I would expect "Reply All" to already be a non-problem if "Reply-To" overrode it. My pre-existing belief was that "Reply-To" replaced only "From", not the entire recipient list, under "Reply All".

@epriestley I was just jumping on here to provide some simple examples and reasoning from my experience on our internal bug tracker (we don't use Maniphest). Note this isn't my bug. Just trying to help out someone by giving an example for reasons they could want this. I'm sure your response was well intentioned but does come off a bit user hostile. For instance, nowhere did anyone mention wasting time by having a constructive conversation about this. It gives the impression that you guys consider having to deal with the community is a waste of your time. And no one is arguing against the root problem concept.

Hello! Thanks for writing in. Please read and follow the instructions on Contributing Feature Requests and Describing Root Problems. We require these guidelines be followed for every task, this saves the upstream time and resources.

A sub-issue here is that we're bouncing a lot of email like this, for an exciting product called "Penisole" from reputable domain "bloggay.com":

Add some kind of notification to user accounts like "some email you would have been sent was dropped because you haven't verified your address yet"?

My plan here is:

My guess is that this is just something dumb and mostly out of our control, and we fell through the cracks because the email volume we send from this install is tiny. We sent 41,877 messages in January at a cost of $0.00 -- this is too few messages to even qualify for charges, which start once you send 2,000 messages in a single day.

🤔

The changelog from Mailchimp (opt-in only) is from noreply@phacility.com, but I can't think of anything else off the top of my head

Yeah: if it's important to identify duplicates because you use duplicates as a priority signal, making it easier to see a list of duplicates on the task detail isn't a very powerful approach.

Future instances of recurring events aren't visible in panels when an item limit is set:

In T12237#211025, @epriestley wrote:

Although I'm somewhat confused by this because it came to the address for my personal AWS account.

Related to paid prioritization, how much would it cost to terminate this task and also the ability to edit the time entries after validation (man does mistakes).

I appealed this, but the FAQ says "Due to the way spamtrap sending is reported, it will take a minimum of three weeks before we can confirm that a fix you have put in place has succeeded.".

@chad, just to make sure my ducks are in a row, you aren't using noreply@phabricator.com in association with any marketing mail, right? I don't want to claim "we only send transactional mail" if that isn't true.

SES is definitely rejecting mail, though:

Although I'm somewhat confused by this because it came to the address for my personal AWS account.

Anyways, I don't know what the root problem of this task is, like @epriestley mentioned above. Knowing the problem this information solves is what we're most interested in. It might be Facts, it might be something else. Basically, what do you do with this information? Why is it important? How often do you need it? What decisions do you make differently with it? Can subscribers be a better proxy for this information because it includes both hard duplicates and people who proactively found and followed the task?

I was referring to "A task with a lot of dupes might end up getting higher priority because of the number of dupes.". This kind of data should be pulled by facts.

Wouldn't that split up important data? A project manager will normally always be looking at the project board and moving tasks around there. Would it be cumbersome to have to go to some other application in order to do a query to figure out the relations on this one object? Not sure how you guys are thinking about Facts but going somewhere else for that info might be too cumbersome to do often. Especially if I'm jumping around a group of tasks in projects already. I would want that information presented there as well.

I'd rather solve that problem with Facts.

As to why it's important I think dependes on the style of project management being employed. Some places keep track of the dupe count as a way to gauge how often an issue is being seen or how many separate requests for a feature have shown up. A task with a lot of dupes might end up getting higher priority because of the number of dupes.

Maybe a more useful form of this would be some form of being able to view "how all related objects are related to this one". You can currently see related objects but you cannot easily tell the nature of that relationship for some of them. The task graph solves part of this for dependencies but not for other relation types.