To clarify, you are using HTTP for Phabricator but HTTPS for the notification server? If so, why have you made this (unusual) configuration choice?

Yeah, I came to approximately the same conclusion. Save + restore on the scroll position appears to be a complete fix as far as I can tell.

Invalidating the cache is trivial, but I think <code> is used to style code blocks and has a bunch of different rules (e.g., block formatting) already associated with it.

Yeah, either closing other open menus or allowing menus to be stacked on top of each other.

Does this cause any concrete problems in any user agent?

Although I guess that sort of doesn't really solve many/any problems. But we could embrace that by allowing a blog to be "unlisted" or something, maybe.

A possible workaround is to create two blogs (review, production), and use "Move Post" as a "Super Publish".

Thanks, I'll see if I can figure out what's going on in Chrome.

On OSX, I can't reproduce this in Safari or Firefox, but it does reproduce in Chrome. Are you also using Chrome?

The expectation is that you create a "Bot" account, and add keys to that account.

Presuming resolved, but yell if I missed anything.

Caches should be purged, let me know if you're still seeing issues? D15311 will fix the underlying problem, and should promote and deploy in the next 24 hours.

I'll clear the caches on your install and disassociate the {icon} rule from the Macro app. I think the original idea was that {icon} is silly nonsense like Macro, but {icon} has proven to be both silly nonsense and a super serious useful business tool.

This is via discussion on IRC, but the request captures it pretty well.

I think this issue was fixed by 58c2141 (Feb 16) which hasn't promoted to stable yet. You can either upgrade to master now, or it should promote to stable in about 24 hours. If you want, you can subscribe to the Changelog to keep track of when we promote.

Just to confirm, this is a Mercurial repository, right? (I'm assuming it is because of default instead of master, but just want to make sure.)

In T10349#160305, @cburroughs wrote:

A task tagged with a sub-project, is still in the parent project, right? So it hasn't been "removed" from Dashboards

There's no space to show that columns in cards, but would it be possible to show them in a tooltip?

I think it's vanishingly unlikely that we'll write a visual DAG editor.

In general, we can't possibly create buttons for everything -- there are way too many rules, and some of the rules don't lend themselves easily to clicking a button. The icon already links to the full documentation, which explains everything (and this document is huge, because there are ton of rules).

It sounds like no one can reproduce this problem anymore. If anyone runs into this again and can figure out reproduction steps, feel free to file a new task with details.

There's some context and discussion in T4207. Briefly, task dependencies are currently a directed acyclic graph, not a tree, and DAGs don't lend themselves well to visualization or drag-and-drop editing.

It has been greatly improved.

Oh, never mind, I figured it out. :3

I think this issue was fixed by 58c2141 (Feb 16), which is a little ahead of where you are. You can update to master to pick it up right away, or it should be available in stable in about 24 hours (if you want, you can subscribe to the Changelog page to keep an eye on when we promote to stable).

Can you either confirm that you're running HEAD of master, or tell me what version of Phabricator are you currently running?

Yes, I'd expect to do this:

Sorry -- I'm happy to walk you through the technical details in greater depth at consulting rates (see Consulting) but want to draw a hard line that "not supported" really means "not supported" on this.

@chad Was that just testing something, or a vote for this as a substantial problem?

@thuffir, I can't come up with an easy fix for that.

No problem, and thanks for including all the relevant version information in your report! Let us know if that doesn't fix the issue for you.

This was fixed by 329d036 (Feb 13) which should be available in stable in about 48 hours (or you can update to master before then).

A custom dashboard panel (that checks if the user has JIRA linked, gives them a big annoying flashing GIF "LINK YOUR JIRA ACCOUNT!!" button if they don't, and renders nothing if they do) on a custom homepage dashboard might be a similar achievable approach without an unreasonable amount of effort, given the technology of today.

@dpatou Does reverting both 5e375482 and 8269fd6e fix the issue for you?

(That's admittedly not communicated very clearly by my screenshot.)

Old behavior was this:

Given the system appears to mandate that I select from the list

D15302 was the change I was most worried about here, and it seems to have been entirely straightforward. I now expect to move forward like this:

For repositories with a short name like "codebase", I imagine users would prefer /diffusion/codebase/ over /diffusion/123/ as the canonical URI.

We should maybe hide the tags for archived projects on worboard cards, I notice WMF has a lot of this:

See also:

Doing this blindly would let clients spoof remote addresses on installs that are not behind load balancers. The current recommendation is to replace REMOTE_ADDR in preamble.php if you trust the connecting device. Here's what we do in the Phacility cluster (although we're in SiteConfig here, not preamble):

My planned pathway forward here is:

I will report you to the workboard police on T10215 if you keep it up! You better check yourself before you wreck the project roadmap for weeks by derailing it into abuse cleanup tools.

I have replaced your dumb 1x1 transparent GIF with a fearsome tyrannosaur.

I really like the look of the inverse tag, although I haven't personally felt too much confusion about milestones vs nonmilestones on project pages.

In T10349#159831, @cmmata wrote:

So is there any official/recommended way to work with global milestones?