I think I'll have time for this this week/weekend.

Shield icon is if a task is blocked. The number is story points.

@dserafin - For something in the meanwhile, this is what I do to get reports:

1. Added custom field(s) to Maniphest Tasks to classify task type - see Configuring Custom Fields
2. Install extension for exporting Maniphest Task search results to Excel spreadsheet
   • This requires PHPexcel to be installed on the machine, and for your php.ini to be configured to load that library.
   • The extension can be downloaded here (use at your own risk) - this adds some columns to the output to include some custom fields -- not all field types have been tested/implemented. If the task is on a project workboard, it will also list the workboard columns it's on. The code is fairly straightforward so you should be able to modify as-needed.
     • https://github.com/neandrake/phab-utils/tree/master/extensions
3. From web interface do a search query for tasks, then at bottom select Export to Excel, then select the 'Default with Custom Fields' option.

As cspeckmim, I'm working in a company where all code is safety related and must be certified. We'd like to have a report on the code review activity. At present we have to submit a lot of screenshots to demonstrate we performed code review using Phabricator...

(And, obviously, all of this could be way more clear in the UI.)

Sorry, this actually is expected, if the resource pool is totally empty to begin with. Here's why:

Yeah, use phid.lookup.

See Planning.

Are there any plans already for implementing this feature some time soon?

We've run into a situation where this would be useful in my organization. One person's name has changed recently, but our only option to reflect that in Phabricator is to update their username and thereby disassociate all their past activity. Being able to update the username but add the old username as an alias would solve the issue.

@epriestley Yeah, I understand. If you cannot reproduce it you can't fix it. ;)

I was able to reproduce the error message with the obvious, invalid input:

Very strange. I solved it temporarily by removing the group from the list of reviewers. That way I could at least update the diff. We've had similar issues in the past. The issue appears to mostly happen when you try to update a diff that was created before the upgrade (and not necessarily new update).

I'm going to close this out since I think there's no way for the upstream to move it forward for now, but file another issue if you hit a second wave of stuff or reopen this later if, e.g. all the fixes were terrible no-good garbage.

I'll upstream regex changes if they include unit tests.

After the above, I ran arc diff origin/master --trace to update the revision. Got approximately the same screen (with "Differential Revision" now populated), saved and exited, got a clean update (see D15002).

Oh, you're reporting that updating causes the error, sorry. Let me try that.

Oh, it sounded like the path forward was T3967, so I was unsure what people were complaining about given that things seemed fine to me, but that task was still open.

I can't reproduce this. Here's what I did:

Upgrade Phabricator to rP5592e59 or newer, then try again.

https://secure.phabricator.com/book/phabricator/article/forms/

Different (albeit related) bugs:

Those two entries are called "Forms" and you can create forms in your Phabricator instance by going to:

can confirm...

Are the shield icon and the numbee badge respectively a task in space and the number of comments?

@joncalhoun: That's not related to this ticket, and also not supported. You can add projects to Revisions, but not Diffs. There will be an API for projects on Revisions eventually, see T5873.

This is a pretty old ticket, but if possible I'd like to add a use case:

D15000 will make capturing no text mean "the whole file", and documents the behavior. You can either change your regexp to not capture "0":

Well, maybe that's overkill.

I believe D14307 changed the behavior from "fatal horribly" to "work". It's possible that capturing 0 meant "whole file" at some point (although I'm confused by T6303 if it did) but I think that was accidental and don't believe we suggested/recommended/documented that anywhere.

Hmm. I thought I had seen that somewhere. Oh I see what I did. I followed the filename linter code and noticed that it called:

Instead of the line being 0 (meaning whole file)

This is very similar to T6303.

(Although another benefit of T6139 is being able to surface build logs in emails that are sent out, so developers don't have to dig for the answer)

I don't really mind how it's implemented; it's mainly that if another task is required to set the reason for failure, then what happens when *that* fails or is otherwise not run (because the error is too fatal for the script or application that's being run to continue). Harbormaster right now doesn't have build steps that run on failure, so there's no post-build steps that can be guaranteed to run to assess the failure result.

I think this ticket is much more modest than T6139; I'm thinking this is front-end part (Store and display), and T6139 is more back-endish (Find root cause in log). This is more similar to T9124.

While I'm at it, I'll add that the lack of this feature is a significant cause for developers ignoring build failures. Recently we had builds failing for at least over a week without anyone paying attention because there was no distinguishment between "failed to clone because of some network issue" and "the database scripts are broken and someone needs to really fix this now". It's now at the point where developers just ignore builds because it doesn't tell them what's wrong, and nothing happens about broken builds until a build engineer realizes and emails the rest of the development floor.

T6139 is also a request for this (I'll leave it up to @epriestley to decide which way to merge it).

See T5920#131011 for prior discussion.