I think this is likely a bug.

T10940 should be resolved now, D15903 should resolve lock granularity.

I'm going to merge this into T9275, which will solve this automatically.

Tagging Wikimedia - This task would resolve a regression we experienced after having moved from Gerrit/Gitblit to Phabricator Diffusion as primary repo browser. Gitblit, similar to GitHub, rendered .md files as Markdown by default. (Remarkup would be fine, too.)

In T9195#132482, @chad wrote:

There is supposed to be a menu icon there, so there is a bug somewhere. Do you have no Conpherences at all, perhaps?

Moving this to "Paused" since we're waiting on feedback / deployment / bug reports / things to catch on fire.

• Patches from metamta.differential.inline-patches should be formatted more nicely in HTML mail at HEAD.
• metamta.differential.unified-comment-context has been removed and we now raise setup guidance about it.
• The View Revision button is functional locally, but waiting on design once @chad gets back from vacation next week, since my version of it looks a lot like I designed it (D15884).
• Swapping HTML mail to become the default is ready (D15885) but waiting on the button and maybe a few other designey tweaks we want to consider.
• There's an hour or so of time across all of that which I haven't tabulated yet, but I'll settle it up once those changes actually land.

We're prioritizing the research to estimate how much work this is so we can possibly eventually prioritize it, so this is going into the queue, but don't read too much into it.

In T10694#174693, @jcarrillo7 wrote:

@epriestley Thats good to know. Also, will this change include formatting the Change Details section of emails? That one is currently a blob of visually unparseable text even in HTML emails.

Please unassign me from this task (why can't I do it myself?). My patch was rejected.

I was unable to reproduce on secure.phabricator.com, so I'm going to investigate a little further.

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?

(I'm just getting this into the preflight column for communication purposes since there's a slot reserved, we won't start work on this until we have an explicit confirmation.)

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

Ignore my answer, I misunderstood your question. This is not expected. File a bug with reproduction instructions.

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

Thanks!

T10748 is moving into production, which is the last major new piece here. Remaining cleanup work I plan to do in this phase:

This SQL query will map all users that don't have an LDAP mapping, allowing them to log in using LDAP as long as their LDAP username matches their Phabricator username.

I think this is the current state of the world. I'm planning to tackle the three major issues noted below (observed repository versioning, repository lock granularity, device enrollment behavior) and then try to wind down this phase, move all this followup work to a new "make clustering more powerful" sort of task, and then plan where to go from there based on which goals are most important (scalability vs multi-region vs read-only vs hg/svn vs drydock vs whatever crops up as installs actually deploy this stuff).

OK so they have to make it at step 3, before his first session expires, otherwise I'd have to update it directly in DB.

If you hide urls, nothing changes at the other places:

• for example if I would disable https://secure.phabricator.com/diffusion/P/uri/view/48/
• https://secure.phabricator.com/diffusion/P/manage/uris/ would still show, that this URL is enabled, same at
• https://secure.phabricator.com/diffusion/P/ in that case.

Going any farther than this risks some inconsistency / data loss and we haven't managed to break this yet, so I'm going to consider this sufficiently robust until we see evidence otherwise.

They can link their accounts in Settings → External Accounts.

OK for the security feature, but in my case LDAP is the only auth provider (username/password is disabled), so my users can't link their accounts.

It's on an invisible page <_< >_>

This is expected. This is a security feature, not a bug. Just because you have a Phabricator user account named joe does not mean you have authority over the LDAP user account named joe, and vice versa. In many cases LDAP and Phabricator user account names differ. Users must prove they have control over external accounts by linking them before they can use those external accounts to access Phabricator.

I didn't see anything related in recent changelogs, so I didn't update out instance.
But if you could wait a couple of days, I could try to reproduce.

Is the issue reproducible with an updated version of Phabricator?

Callsigns have been optional for a while now so I'm going to close this. See T4245 for context and followups.

Callsigns have been optional for some time (roughly since D15305 in February 2016, although there were a trickle of bugs after that).

T10748 is wrapping up, and repositories now show cluster status in the new "Storage" panel of the new UI:

I think this is substantially complete now. There will probably still be a trickle of issues as this gets more use and T10923 has some stuff that didn't get fully addressed here, but everything I've been tracking is in reasonable shape as far as I'm aware.

@epriestley: Thanks for the tips. That field is actually a legacy thing at this point and probably should just be hidden everywhere.

Merci :)