It sounded like you were going to set the header on the server.

https://github.com/phacility/phabricator/issues/258

I am not aware of any way to "warn" about this.

Placing this back for triage, but I think this should probably be of a reasonably high priority on the Harbormaster roadmap, simply because of the impact it can have in migration and schema upgrade times.

I had to basically rename and recreate harbormaster_buildlogchunk for the utf8mb migration because this table was gigabytes in size.

Yeah, these files shouldn't shield.

This was also reported in T6107.

Let us know if I didn't fix this! Thanks for the report.

Closed by commit rP755c5186318b.

"Alt" and later with alt continuously pressed "9" "6" (on the keypad) will do the job if needed

@qgil it sounds like what you want with each roadmap item being maintained and documented by the item owner, is an application of the existing permission system not necessarily somewhere the Roadmap idea I'm suggesting would be going the wrong way for Wikimedia.

I feel that at least for Wikimedia this would be an overkill, or even a wrong direction. In our case, the roadmap is a declaration of intentions, but then each roadmap item is maintained/documented by their owners. There are no project admins that will be able to update the several pieces of the roadmap.

@qgil I did examine the phabricator roadmap page before I began trying to work out how hard it would be, what I feel is that while T4863 goes a long way to making the work board a very close equivalent. All of these are more a case of 'good enough'.

All the repository stuff lives in Diffusion now. There just used to be two ways to get to repositories (Diffusion and Repositories) which was silly/confusing. We moved (almost) everything into Diffusion but haven't finished cleaning up Repositories yet.

No, and we don't want to remove them. T5715 discusses rationale and building a repository sync workflow or something like that to mark them.

(Admittedly these may have been happening before storage adjustment as well)

Hmm, I don't think this is a race condition because none of the tasks are being executed. The queue stayed at ~200k tasks for a few hours.

I can't reproduce this (we've been running with the patch on this install since shortly after it was committed) and the logs don't make it clear what's wrong -- it looks like the foreground process might have raced with another process and lost?

@joshuaspence, is this still occurring?

I don't think this is worth pursuing currently, given work involved.

@epriestley, we have some code in MW, that parses the xml of the svg, to extract it's viewbox, which you can consider to be a 'original size' and use in the calculations for your target size.

Alright, clicking F228322 you go to a page where the SVG is rendered. This saves some clicks. Progress!

It looks like imagemagick can produce a passable thumbnail:

I partially fixed this by adding image/svg+xml to files.viewable-mime-types and files.image-mime-types. In particular:

Thanks for the quick reply!

We'll indirectly support this via T3980, which will let you bind a project's members to some LDAP query.

We don't plan to implement this.

fwiw in Trello boards you can drag tasks in workboards pressing a task and dragging it. I won't bet on the accessibility of this approach, but our Trello users seem to be very happy about it. Apparently it's a relatively frequent task on mobile, just like other non-typing-a-lot tasks.

I think we've got it worked out at our end, in https://phabricator.wikimedia.org/T798 so I'll close this task. Thank you :)

Thanks for trying. Some more details if it helps about our install :

1. I was in the homepage where everything looked fined
2. pressed the power button
3. logged in using Google ID
4. Filled the account creation fields and saved
5. Got this:

Could you try this :

We don't keep parity with every external library available to Phabricator, and instead update as there is a project need for it.

We don't plan to support this.

In this particular case it's not what happens.

This is probably expected behavior. If you access a page which you need to log in to view, we try to send you back to that page after you log in (or register). Specifically, the expected behavior is:

Sounds exactly what we are experiencing. I'll consider this as low priority on our side, and unfortunately, I cannot provide more help on how to reproduce the bug, since I just tried registering with multiple providers again and got no problem this time...

That png doesn't work?

I'm not able to reproduce this issue and don't see any other complaints.

Yeah, let's see where we end up.

Most search & find interfaces give a visual cue when they wrap around, however. Would a patch along those lines be accepted?

This feature works as I expect it. The behaviour is consistent with "Search & Find" interfaces on many applications like Chrome/Firefox and changing this default would likely generate a moderate level of outrage from other Phabricator users who expect it.

That was quick !

Thanks for the fix @chad!

Closed by commit rP13aa443e2d10.