So the daemon log is 17G so grep is a bit slow

In T6819#88767, @epriestley wrote:

1. In inbound mail to create tasks, there's currently no alternative to #project.

For me, at least, (1) doesn't feel good; I've never used (2), and putting projects in the "Projects:" field doesn't seem like a big deal; and I've never used (3)

It would be sort of cool if bugs+project@phabricator.com automatically worked, but I'm not sure if that is too much magic or conflicts with something else.

Debian Wheezy.

My initial reaction to the fancy scroll bars was to cry out in panic. It's possible there is nothing inherently wrong with the technique and that it's just that every other site I've seen that uses them is an unsightly, glitchy, inconsistent mess, but it's how those other sites have conditioned me to view it.

Its sounds like T6943 would cover most of this.

You can already template some things with url parameters. For example /maniphest/task/create/?projects=foo. I'm not sure that's documented anywhere or which php file to pull the full list of possibilities from.

Just swinging by as an interested observer, @remon it looks like you still need to sign the CLA.

I suppose I would consider toning down the language around deadlocks. They seem to be easy to induce with single threaded scripts (thanks mysql!) which is different from the use of the word deadlock in programing languages or VMs.

https://phabricator.wikimedia.org/T1284 sounds more like T5024

Yeah so about that customizing the logo for internal installs ticket

This would be cooler as a general remarkup feature instead of just Phriction.

Adjust has been run on our db and /config/database/ reports 'No Schema Issues'. However, if I try to create a ticket with a cute title like ? ? ? ? ? ? ? ? ? I get:

Well, I'm confused.

I've already done my production import so I'm not going to re-write all of my scripts to test, but I think the insert vs save trick look reasonable for IDs and creation dates.

rebase

In T3179#83850, @mattflaschen wrote:

In T3179#81309, @cburroughs wrote:

Building on the work from the Blender team (thanks!) we have been able to plan a migration of ~40,000 trac/trello tickets into phabricator.

Thanks!

Can you add license/copyright information for the pastes?

Well since I get to ignore implementation difficulty:

• A way to say 'only try to evaluate herald rules on commits in these branches' (sort of like the auto-closes configuration).
• Fancy constraint system only re-evaluates rules that possible could be affected by branch moves (so if you have no rules that reference a commits branches nothing happens).
• Use knowledge of history to only re-evaluate commits since the branch point in the "temp-devel-bufix" case.

After reload the '(Backlog)' part shows up.

It's not a planned every day part of a workflow. More like:

So I think making it more clear which one is default is good. However, even not-confused users find it annoying and error prone to have to drag dozens of tasks around to change the default via the rename dance.

Ideally something like: Workboard → Edit a column → Is default: boolean

I don't see a little prototype bomb next to Doorkeeper but there is no /doorkeeper to do anything with and it's not on phabricator.org. Is it something that people should use today?

Building on the work from the Blender team (thanks!) we have been able to plan a migration of ~40,000 trac/trello tickets into phabricator. Summary: (A) a lot of work (B) gross code (C) basically working (huzzah!). If you are considering doing something similar some examples from what we did might help. I'd only go down that path if you have significant expertise in the source system and phabricator (as in if you break your phabricator install you will need to fix it on your own).

(I wanted to capture this for posterity but I'll admit I'm not sure it's worth maintaining the added complexity unless imports are going to become a more common thing.)

It seems obvious to me that A to Z ordering by username excluding disabled users should be the default query (exactly like is done in Projects which excludes archived ones in the default query), and then you could allow sorting my creation date and others.

Are these disabled accounts receiving the email?

• new arc lint fixes

For summing things see T4427

Is Unverified different from 'Show only users who need approval'?

Passing along a trigger-like request: Have a commit message like ReadyForQuality T123 move a task to the 'Ready For QA' column in the appropriate (magical? configured?) boards.

It would also be be nice if one could map a field with S/M/L/XL into points for the purpose of the sum. Or at least if that was possible if you wrote your own custom field class.

maniphest.info from conduit will give you a bunch of json including

What I pasted is the 'raw' source of the message which I presume is what it needed to reproduce. In gui client land it looks something like

You could:

• Set up whichever projects in your instance that you want to map to

ldap with a policy such that people can not join or leave normally.

• Write out a conf file that maps these-projects<-->your-ldap-groups.

Or has a white/back list, or whatever it is that you need to do.

• Write some scripts that does something that is conceptually along the

lines of: get-members-from-ldap | set-phabricator-project-members.
There are some examples of such scripts in T5550.

• Use cron.
• Be on your own to support this.

P1266 is a similar POC script that takes a project name like Herculoids and will make the membership of all projects matching a prefix like Herculoids-Sprint the same. This might be useful for per sprint projects until T3670 to avoid the re-joining annoyance.

In case anyone else is using this setSuppressEvents is no longer a thing and an emptyness check is needed for projects like

Well that makes sense.

• slightly more consistent indentation

This "basically works" but needs a *a lot* of work and has a bunch of
issues to resolve.

Yes per board with that possibly being a thing that changed fairly often ( so I suppose something that acted like the sort/filter buttons in the top right would be idea).

Internal request has been to be able to control what the color on ticket means. For example, if we have a type field, to make the stories different from the bugs or maybe to make the 't-shirt-size:XXL' tickets different from 't-shirt-size:S'. This is mostly for planning purposes (like during a sprint planning meeting) and not something we would want to set globally for any context a ticket is viewed in.

To followup from IRC: If the single page view had the 'Batch Task Editor', I think between this and T5474 would cover > 90% of the internal feedback I've gotten.

Specific to search. If each ticket has 22 fields I don't want to display them all the time everywhere because that would be gross. But if I have searched and limited my results by field X, I would like to see how the values for Y break down. If there are 1000 results I don't want to have to click on all of them to do it. The trac ui does this by returning a row for each result and letting you select which columns are displayed with checkboxes. I like this but have no idea how it would fit into the card like search results that are used for display now.

it would be nice if projects could be moved in the hierarchy. For examples if I have 1,000,000 sprint projects now, it would be nice to tidy them up as subprojects some day. Also if someone goes and ties projects to their org chart (Engr → nodejs hipsters) they will probably want to change it when they learn how transient org charts are.

Happy to see this fixed as part of T4900 but note that it affected for a single user in a single tab which may or may not be different in a way that matters.