This install now exposes two separate actions in a new submenu, although the backend is only sort of halfway converted. My plan is:

I'd like to have a clearer sense of how we're planning to resolve T10034 before moving forward here, even if we don't actually build any of it yet. Briefly, I think some of the problems here are:

Here are the interactions I can come up with which we'll potentially get wrong by implementing this naively:

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

Bookkeeping; there's no longer an external driver for this.

Ref T11085

In T3670#178894, @bhush9 wrote:

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

I suspect it isn't going to get very far because we lose our ability to optimize lookups (I wrote this in the general case as "regexp", but mean "regexp/wildcard" -- wildcards aren't as complex but I think the general case still holds).

This is in master and live on this install. Let me know if you hit issues with it, especially on mobile. Seems fine on my iPhone 4 but I don't have a ton of devices on hand for testing.

quick note: even on systems with 'normal' windowing systems many users
dislike or can't use drag-and-drop workflows. I'm mostly mentioning this so
that the non-D&D workflow isn't entirely treated as a second class citizen.

D15953 played out more or less as described above. I'm not going to land it before cutting stable this week since it touches Workflow in a couple of ways that might have unforseen consequences, but I expect it to be available in master some time later tonight or tomorrow.

After D12066, we have an upload workflow which gracefully accommodates very large files (progress bars, resumable uploads, no server host needs to handle more than 4MB of data on disk or in memory at once). This flow is activated when you drag-and-drop, and we've successfully used it to transfer reasonably-sized cluster import/export files (1-2GB) for the better part of a year now.

In T5187#175015, @epriestley wrote:

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

See Paid Prioritization and L34 Phacility Prioritization Service Agreement for specifics, if you haven't run across them yet.

You're behind T10917 and T10939 in the queue (see the Prioritized workboard) and some other things which are wrapping up, so it will probably be about a week before we can pursue this. If that sounds reasonable, we can get this into the queue now and confirm with you before starting work.

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

@epriestley I'm happy to try to pay you to review the patch if that'll help.

(If that answer isn't particularly satisfying, maybe see discussion starting here: T7820#172877.)

We haven't seen much interest in this from outside WMF, so there are probably several hundred tasks ahead of it on our natural roadmap.

This is still a big problem for Wikimedia's Phabricator installation, making it unnecessarily difficult to file or amend bug reports about mobile issues.

@epriestley thanks for the extra context. Makes sense now haha. Sad to see this get deprioritized though.

This was moved into the prioritization queue by a particular customer that was interested in defining Owners via Projects via external sync.

@epriestley can you explain how this was building up toward T10939? That one deals with automatically adding reviewers while this enables project membership (and hence policies) to be based on a predefined source of truth at most companies (LDAP).

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

Well now I feel silly for not noticing that. I searched for the line number of the error ><

Thank you very much, that worked as expected!

You can update the phabricator_user.user table and remove the isMailingList flag from the account, something like this:

Are there any plans on allowing changing account roles, say from mailing list account to regular user account?

I plan to separate this configuration and make these options all explicit, see T10697.

Per conversation in T10589, I would like to echo @jhurwitz's request. In reality, both search for open & closed and open-only are use cases that exist. But in day-to-day work, even for QA, the very significant majority of use cases is for open only. In addition, w.r.t. the "closed tasks also" use case, the user behavior in response to "I didn't find what I looked for" is "refine my query" which is a natural human behavior that will cause these users to discover "oh, closed isn't checked". In addition, there is a visual cue when they see closed tasks that closed tasks look different, so the anticipated concern of "maybe the person searching will give up not seeing their closed item in the list" I believe is negligible (especially in face of the much more abundant concern of "omg there is so much closed stuff here...oh yeah, I need to ensure "open" is checked and "closed" is unchecked).

Is the outcome of this task likely to be select a source for a given project where source might be manual, or ldap, or something custom?

Is the outcome of this task likely to be select a source for a given project where source might be manual, or ldap, or something custom?
Would it be possible for the source to not only serve as an adapter but also create/remove projects on-demand?

This is a highly valuable feature for my use case as well