Yeah OK. I think this falls into T5568 then, which should cover pas song flags to the underlying tools.

What are build properties exactly? Is this just passing command line flags to the underlying binary?

I'm happy to take a crack at this, but I'm not sure what the desired behavior is... Silently drop notifications to users that don't have the correct permissions? Filter the list of users to notify before triggering notifications?

I'd actually like this functionality in other places such as Maniphest. That is, I'd like a stronger notification if I am mentioned on an object that I am subscribed to rather than just a plain comment which doesn't contain a mention.

Is this going to include the ability to build (i.e. lint and test) diffs as well, or is that part of v3?

I would like to take this one step further and consider dependencies recursively. If task X blocks task Y, which itself blocks task Z, then I would like to be able to search for "tasks blocking Z" which should include both X and Y.

I guess this is related to / a duplicate of T4345.

Oh I'm not fussed about not being able to prioritize tasks on this install, I just was confused and initially thought I had stumbled across a bug.

Actually, it seems that the "Can Prioritize Tasks" policy on this install has changed. I think that the option to change priority should probably still be visible though, even if it is not allowed by policies. Generally I thought that this was the preferred approach (showing as disabled rather than hiding).

Ah that's true, I wasn't considering historical stories. But yes, "from X to Y" definitely reads better IMO.

Yeah that's seem fair. The "changed title" use case seems different to others (such as "changed subscribers") because the {T123} includes the title anyway.

I don't quite understand the use case here... I imagine that importing repositories is something that happens very infrequently and so I think that such a change would have no effect most of the time. Am I misunderstanding?

In T9192#132389, @avivey wrote:

Maybe rename the edit page "advanced" or something, and let anyone with "can view" see it?

I'm not familiar with Mercurial, but are these feature branches which are eventually merged into a master branch? If so, I've had a thought about this previously... What if you could just put the Ref T5 message in the merge commit and have that associate all commits from the merge with the task? I'm not sure if this is easy to do technically because a branch could be merged into multiple other branches.

Lol nice.

From memory, that just gets the /badges/ part of the URL? I'm talking about this (I'm on the train so excuse the pseudo-code):

I've seen a bunch of cases where dead URLs have persisted for a while before being caught... Have you given any thought to improving the way that we handle URLs? I feel like there should be some getUrl() method for most (all?) objects.

I've often been frustrated by this. It's possible to associate differential revisions with a task from the task itself, but not for commits.

I want to work on this eventually but I haven't had the time.

Comparing the mappings before and after (with curl 'http://localhost:9200/phabricator/_mappings?pretty=true'):

I've made some small progress here.

In T9161#131941, @chad wrote:

My 'useful' bar for email is "would I want to reply to this".

I can sorta fix with using PhutilFileLock, but it feels a bit gross. Here is something I threw together real quick: https://secure.phabricator.com/differential/diff/33545/

The configuration-driven unit test engine isn't yet ready for general consumption.

T8612 is related.

I guess that we should return a 404 (or even 410)

Why would it reproduce consistently for certain diffs but not for others though?

Interesting... this happens consistently for certain diffs (for my own reference, D22362) but works fine for others.

Isn't Phragment the right application for this purpose?

Yeah. I will probably end up just writing my own NodeJS script to parse and interpret the CSS documentation.

Ah yeah, I'm not really talking about HTML within the comments themselves (although I'm sure we will have to deal with that as well). Specifically, this is the tool that has I have been referred to: https://github.com/kss-node/kss-node

Yeah, agreed on avoiding it if possible. I just got asked about CSS documentation which I have no idea about but there are existing tools which spit out HTML. I will look into what would be involved to parse the HTML.

What about the ability to publish arbitrary HTML into Diviner? This is not ideal, but it means that any documentation system can be integrated.

If you did this, wouldn't users just remove the blocking task relationship so that they could close the task?