Yeah, that would be nice. I hacked in a delivered closed state to our copy, but its not ideal.

Thinking out loud, maybe another solution is to add tags to tasks, and make them searchable. So I could tag a task as 'needs confirmation' or something.

More non-ideal solutions :) -- We have flags right now, so individual testers could flag things as "Need to verify" as they come in for them. This would have them show up on the homepage for the tester. They would clear the flag as they finish. This is only really helpful to the tester; no one else can tell what flags a user has other than the user.

Thanks. We had sort of experimented with that, but backwards. Having the tester flag a bug when they file it and only unflagging once it has been closed and confirmed might work pretty well.

A common workaround is to add a Project, "Confirmed Tasks", or something, and add that project for your "verified state". It's of course non-optimal, but i think the workflow is generally sane (same way bugzilla works for instance).

Or you could just use a message "Hey, this one is fixed now", and have the "confirmer" do the actual closing of the task.

requested again today -- https://secure.phabricator.com/chatlog/channel/6/?at=53939

Added @chad and @epriestley as I don't know if we've ever all discussed this particular customization ask. Its a doozy IMO as it enables Maniphest to get used for "workflow" of all kinds.

T690

Hey guys, Ryan Nordman from Rdio Engineering here. We are really enjoying using Phabricator as our bug/task tracking and patch review tool. Keep up the great work.

I think being able to have custom status would really help us, basically the concepts we're asking for are:

• A Maniphest Task Type field (“Task”, “Bug”, or “Feature”)
• A Severity field ("Crash", "User Blocked","Not Functional", "Wrong Data", "Missing Data", "Wrong UI")
• A Release field which tracks the date and version number of when the patch was deployed to production (Date and Text fields, respectively).
• A Status field: ("New", "In Progress", "Fixed", "Released", "Closed")
• Time Estimate and Time Actual fields (Datetime)

I realize some of these could just be project tags, although I think our desire is to make it more prominent in the UI so that people creating tasks fill them out correctly.

To describe our workflow:

1. Testers/engineers/designers create a task/bug/feature as a maniphest task.
2. Engineering team leads triage and assign priority.
3. Engineer claims task, creates diff for review.
4. Review accepted, patch committed to master.
5. Master rolled out to production on next cycle (daily on web, every 1-2 weeks for mobile apps)

I'll try and check back here if you need more info. You can reach me at ryan.nordman@rd.io would be happy to chat further.

You can add most of those with configuration, see here:

http://www.phabricator.com/docs/phabricator/article/Maniphest_User_Guide_Adding_Custom_Fields.html

Here's my local install, for example:

{F35853}

These fields don't hook everywhere they should yet (e.g., they aren't filterable and don't appear on lists) but maybe start there and let us know what the biggest pain points are? Some of the additional integrations should come online soon.

Whoops, meant to reference T390 which has some of our thoughts on 'tags'

Hi guys,

I also need this feature for my working process: at least a new status "verified" or "approved", or ability to add custom status.

Thansk!

+1

+1 for this.
In our workflow we need at least "Ready for testing", "Ready for merge" and "Ready for release" statuses..

+ 1 would be really really importamt to have. Custom fields are good but need capability to do filtering and querying. May be in the interim I will use project names for bucketizing since a task can belong to multiple projects

Custom fields support filtering and querying.

oh cool!!!

I could not see the custom fields while doing a query ? How do I get that to appear ?

Any pointers on the above pls ?

The issues here are:

• We need language which maps "Closes Y", "Fixes Z", etc., to custom statuses. D8261 and D8263 bring us reasonably close to that. This has some translation issues but I think we can pretend it doesn't.
• We need a special status marked as "duplicate", which is used when tasks are merged as duplicates. We can enforce this in configuration.
• We need a special status which is the default for newly created tasks (for example, tasks created via email, which do not get a chance to select a status). We could use the first status definition implicitly, or make this explicit.
• The "spite" status is special in that it isn't available for serious installs. This isn't too important and is easy to support.
• Statuses have custom transaction strings, like "closed this task out of spite". We can probably drop support for this.
• A bunch of code assumes "Open" is the only "Open" status.
• The reporting module does some really sketchy things with statuses right now. I'm not sure if we can fake that or not.
• Some of the query APIs don't easily accommodate multiple open statuses without changes.
• Generally, there are 74 references to a specific status constant in the codebase.
• We don't have a "typechecked complex blob" config type, but probably should adopt one (or something like it) for custom fields and this kind of stuff, as the specifications are complex.

◀ Merged tasks: T4560.

@epriestley, I'm not sure if this is covered in your issues above, but it would be helpful to be able to limit status actions given a particular status. You mention language above, but it's more than just the words.

For instance, if my task has status A, available next actions would be to change to status B, C or D. However, if my task has status B, I'm limited to update to status E or A.

Does this make sense? At the very least, you wouldn't be able to "change" a status to itself (but that could be a hardcoded constraint). Also, how were you thinking these would be administered - the same as priority with a JSON config?

We don't currently plan to implement complex workflows like that. They may happen some day, but they're probably at least a year or two away. You could (maybe) attempt to enforce them through events, but realistically even that is fairly far away from being practical.

If you have complex workflow requirements, we'd recommend you look at JIRA, which has good support for this stuff out of the box and is generally better aimed at that class of higher-process use case.

The first version of administration will likely be a JSON config with some safety rails.

Word. So I'd simply create task statuses A, B, C, D and could switch between any of them, correct? Teams could enforce the workflow socially.

Are you folks actively working on the list above? I was planning to just fork and customize, but if these features are imminent (weeks?), I might wait.

This stuff should be less-than-weeks away, there's some motivation here from Serious Enterprise Customers, some interest from other contributors, and no real substantive technical blockers (just a lot of janitorial stuff). I'm focused on T2222 right now and probably won't make much progress on anything else until that wraps up, but this is near the head of the queue afterward.

If you're okay with maintaining local patches, you could probably enforce all the A/B/C/D stuff pretty easily yourself, it's just a lot more work to make it configurable, make the UI communicate the workflows, raise sensible error messages in the general case, prevent users from creating invalid (cyclic / unreachable) workflows, never break the config in the future, etc.

Roughy, you'd just need to:

• Implement ManiphestTransactionEditor::validateTransaction().
• Look for a status change transaction in the pending transaction list.
• Examine the getOldValue() and getNewValue(), which will contain the present and desired task status values.
• If the transition isn't valid, raise an error (you could also look at getActor() to make transition rules user-dependent or whatever).

Then maybe a small patch somewhere to limit the options shown in the UI (or disable the unavailable states).

Thanks for the tips. The complicated workflows are not a requirement for my team. However, variable status for a task is. Really glad to hear it's at the top of the queue. Happy to test this out when there are some new code. Also, let me know if there is anything I can to do bump this in priority. Thanks again.