@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...

Pass with points and faces.

Some of the Pholio stuff is motivated by thinking about v2 sometime down the road. Like having a "workboard" view of my designs and their status could be handy (shipped, needs more work, planned).

Points look great.

Blocking is T5353
Mock is roughly T9520
Diff ... can't locate the task offhand.

I'd like to put off building customization for as long as possible. I think we'll want it eventually to give custom fields broader support, but we can call all of that part of T418.

@epriestley do you think we need to allow customization? My main thought is if we can keep it simple and clean, users won't likely ask for less options. Though it's easy to checkbox which items you'd want to display.

Oh, yeah we should add points in there too. Whether a task is blocked or has children has come up in other tasks floating around, though for all tasks, not just workboard cards.

FWIW, here's what WMF's customized cards (by the Sprint extension, I think?) currently look like:

My current thinking is just to expand the metadata on the cards for everyone, and not build anything "customizable" until we get a better sense of what the expanded metadata isn't conveying. Most of the viewpoints here seem to strictly be able wanting additional projects. I've take a design pass at adding the following information to cards:

But maybe my memory is poor and Workboard cards are more custom than I remember.

It shouldn't require any design, they should just work like they do in Maniphest normally, but without the board's main project. ie, if you're in Differential, and you had Differential and Mobile tagged, just show the mobile tag.

If possible: display both. if not possible - many ways:

I'm happy to send a diff over, but my design skills are quite lacking. How would.you think that the project tagd should be displayed? For example, suppose that a task is tagged with project X, Y and Z and is being viewed as a worknoard card for the board of project X. I'd say that we should show either Y or Z (as X is implied), but I'm not sure which should be preferred.

It should just be the default moving forward, I don't plan to introduce any special settings. Feel free to send a diff over if you like.

Projects displayed on workboard cards. We usually end up doing "[PROJECT] Title" as a workaround.

Probably not. What part do you need specifically, we're already building v3 projects.

Is this available for prioritization?

I think one of the issues was people making a public task, and then deciding they should change it to security, but not having the permissions to do so?

Awesome, glad to hear things sound promising. Thanks for the update!

@epriestley: We haven't pushed this to production but my initial impression from configuring forms on https://phab-01.wmflabs.org is that this should work pretty well. The only thing I haven't figured out is a way to easily transition a task between private & security sensitive and public. It seems that will require someone with adequate permissions to manually edit the task policies, which isn't the end of the world. We could possibly continue to use herald rules to make the transition easier, though I am more keen on the idea of totally killing off both the herald rules and the custom event listeners.

I think you could treat them equally by having the parent project members be those of all the subprojects in both cases. I think it would be a valid usecase to change members from one sprint to the next (retaining the information about old sprints members).

D12692 is nearly the correct patch for this (and will support mentions, file embeds, etc., although currently not Fixes http://example.com/T123, which is parsed somewhat separately -- but that is also fixable fairly easily), it just has some tricky regex/execution order stuff that hasn't quite been sorted out.

Regarding the two use cases Engineering -> Backend && TeamX -> Sprint2:
I think you could treat them equally by having the parent project members be those of all the subprojects in both cases. I think it would be a valid usecase to change members from one sprint to the next (retaining the information about old sprints members).
All that's needed would be some magic upon project creation that uses the members from another project as a template (the last sprint or maybe the parent project as default).

We should make sure to include mentions support too.

thx for deduping

Tentatively, projects get new fields:

In T8434#147963, @epriestley wrote:

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

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

This is still a bit rough in places and probably has some bugs, but I think the big picture stuff is working reasonably well and mostly usable.

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

This hasn't hit HEAD yet, but will be resolved indirectly as part of changes in connection with T9132 shortly as that rolls out.

Aaah! That makes sense.

@epriestley: The main motivation was that we had been maintaining these as cherry-picked patches on top of phabricator core, which required constant rebasing. It was ridiculous and not even necessary. Eventually I figured out that phabricator doesn't care if the auth providers live in an external library. I sure wish I'd figured that out in the beginning, it would have made things a lot easier ;)

This is now published as part of our wikimedia/phabricator-extensions repository. There isn't much demand (or need) for it to be in the upstream.

This is now published as part of our wikimedia/phabricator-extensions repository. There isn't much demand (or need) for it to be in the upstream.

Some feedback from our Phabricator instance. At the moment, the way we have been testing usage of Spaces is:

• S 1: Public (Default). Our open-source projects go there.
• S 2: Internal. Visible only to employees. For this, we would really, really like some way to batch assign/add users to a Policy/Space, as discussed in T9780 and T4103#145539. Handling this manually quickly becomes impractical with large numbers of employees.
• S 3+: Long-running special interest projects. They do exist, and they tend to value their privacy.

See Contributing Bug Reports. Mainly, contributing comments to an unrelated task will not likely get a bug verified or fixed.

In T5908#145115, @KK wrote:

Hi, when I export data from Phabricator to Excel it doesn't show all data from the the field "Description".
It shows only partial information and than it ends with tree dots.
Can I change that somehow?
Thanks

Hi, when I export data from Phabricator to Excel it doesn't show all data from the the field "Description".
It shows only partial information and than it ends with tree dots.
Can I change that somehow?
Thanks

Ah OK, good to know.

You should be able to batch edit infinite tasks.

In T3670#144082, @epriestley wrote:

This is currently difficult to do because it involves bulk editing our entire workboard

What's difficult about this? Can't you just use the bulk editor to "Remove project X" and "Add project Y"?

This is currently difficult to do because it involves bulk editing our entire workboard

I have a use case which is maybe suited for subprojects, but I don't exactly know how you are planning on implementing this...

See T5051#137287. This ticket is not a general support place for questions about other existing 3rd party extensions.

I am also facing same problem but there is no errors shown in my installation.

Please see https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ .

D14390 introduces "ApplicationEditor", which includes more race-resistant controls for editing things like projects and subscribers. In effect, this should merge edits of these fields correctly in all cases where there are no conflicts. Here's an example:

See T5096.

Per T5096, let's keep this out of the upstream until we see more interest from other installs. We're hesitant to bring features upstream if they'll be used by only one install.

I am really attached to git workflow as well, so I wrote my own tool to integrate git and phabricator together:
https://phabricator.freedesktop.org/diffusion/GITPHAB/

In general, see Planning / Paid Prioritization / Roadmap / Starmap.

We would like to have this too. Is there any timeline for this?

@Krinkle: I can't come up with a reasonable way to fix the height=300 comment preview case unless we render the element entirely on the client or relax the WMF constraints. I think the WMF constraints are excessively paranoid, but it's moot since you're the only person complaining about this and you're on the WMF install, so adding a "[X] Use less paranoid caching that doesn't flicker all the time." option wouldn't fix the problem for you.

Ah OK... I can't rememberif I had set a height when I observed this behavior.

• With height=300, yeah, it's going to be a flickery mess.
  • Without height=300, it's a flickery mess in Safari only, in the last few weeks, as far as I can tell.

I'm fairly sure that I've observed that behavior in Chrome.

I'm pretty sure the preview case is recent (last couple weeks) and I don't think we changed anything, but I haven't hunted down what actually did change. My theory was that it was a change in Safari behavior, since I don't see this behavior in Chrome and I first observed it after applying an OSX update. Are you using Safari in OSX?

This also affects task editing and comment preview.