Hi Evan,

Resolved by D17337.

The WMF downstream has some similar discussion here and in linked tasks:

T5701 describes a strategy for Pygments styles. I don't think we should tackle that as an accessibility issue, but I think building it as a user preference issue is reasonable.

If you configure your project so that arc unit runs your tests and then make your Buildkite build run arc unit --everything --target $HARBORMASTER_TARGET_PHID --conduit-token ..., you should get full reporting support. Then arc unit on its own will also work, arc diff will get the same integration, etc.

I've recently found myself wishing for couple kinds of functionality that would connect calendar and maniphest:

• "due date" for tasks,
• recurring tasks (just like events)
• age-based priority for tasks (dunno if calendar would be involved, but i've seen some instances of similar FRs popping up)

Any thoughts on deeper integration with Phabricator? Namely:

• Reporting back which tests passed/failed
• Reporting back code coverage (I guess right now it's part of reporting tests via the API, but I'd be happy even if it's merged under 1 dummy test case)

:/ colors are hard. From my end, I'm very happy with what I ended up doing in Stylish (and this conversation helped, thank you) so it's not as pressing for me anymore. But LMK if there's anything I can help test out.

Basically, can we support "Large Fonts" and "Colorblind Diffs" at the same time?

if td.new-full just used td.new's background color instead (#eaffea). I think it's because:

Based on http://enchroma.com/test/result/medium-protan/?completed=1&summary=moderate+protan&axis=3.11&exta=87.34&extb=4.85&lcs=5.69, I have protanomaly (TIL!)

So I took another look today. Given that the syntax colors are hard to change, looking only at the 4 bg colors I realized that the main change that would help is if td.new-full just used td.new's background color instead (#eaffea). I think it's because:

I see your point.

please no I am so young and have so much to live for

Please read and follow Contributing Feature Requests and Describing Root Problems. Unfortunately, we don't accept feature requests into the upstream without understanding the core reasons you need a feature and what problem you are having using Phabricator. A better way to think about this is, assume we won't build what you ask for, what is the real problem you are expecting this feature to solve.

hiding policy controls when creating panels in context of the Arrange Panels page seems like a good way to minimize this

I'm hoping to make panel creation dramatically simpler, so building a new dashboard from scratch is maybe a 1-2 minute task. Getting rid of copy and maybe also hiding policy controls when creating panels in context of the Arrange Panels page seems like a good way to minimize this.

No idea if realistic, but what if this "feature" is only enabled on installs of less than 6 months (or with the right db schema or something)?

Those seem to have been the magic words:

Panels can currently appear on multiple dashboards, so we can't use the dashboard's policy for them directly. If we could, you could always see any panel by creating a new dashboard you have permission to see, adding every panel to it, and looking at the panel you wanted.

Unless you can define a different default dashboard for logged in and logged out users, yeah.
The problem I see:

• I run a phabricator instance where the main part is only accesible for logged in users, but logged out users can still see some tasks.
• My problem: I want to inform my users about different upcoming events etc, for example per text panel
• The logged out users should not be able to see these messages, so I restricted some panels
• The whole problem would be easy to solve, if admins can define: logged in users get dashboard a), logged out users get dashboard b) in my situation

This is an essential feature for organizations running many, similarly structured projects. For us, each project is essentially a workflow of a predefined series of tasks that need to be tracked, assigned, and discussed individually for each project. Of course, each project will grow its own, custom additional tasks, too.

+1 to hide cover as an option on the board

Do we have a good reason for having separate polices for panels?

A possible workflow change might be to use "Edit Parent Tasks" instead of "Merge", to collect separate bugs under a single parent task but not actually close them.

The LocationsResource file is completely copy/pasted and wrong (still refers to "Instances").

I think the complexity of those rules exceeds their utility.

What are your thoughts on allowing valid HTML entities through to the
browser without further escaping (outside of code blocks)? There seems to
be no reason to have them in text, and they could allow escaping.

Base scenario should create the appropriate edge tables.

And phabricator.developer-mode and phabricator.developer-mode and phabricator.developer-mode and also phabricator.show-prototypes.

We should suggest configuring phabricator.developer-mode and phabricator.developer-mode (for UIExamples, to see icons).

I like. ♥. Thank you a lot!

💃

Yep, if you can update other people's diffs then this is fine. I'll just upgrade if needed. Thanks.

This is what I just did as a test:

I suppose that I'm being lazy, but the exact same argument exists for arc close-revision or arc upload.

@chad my understanding was that only the current owner of a revision can make changes. I guess I didn't read that thread through to completion, though I'm not sure that patch has made it to our install yet.

Can't they just arc patch Dxxxx and arc diff their changes back up?

I'm not trying to be facetious, but I'm not sure that there are two other ways. The scenario is that somebody is out and I'd like to continuing working on their feature whilst they're away. I've read through T10584 which mostly discusses why commandeer should be used in this case rather than updating somebody else's diff. In this case, if they say to me, "hey, can you take D123 whilst I'm out?", I'd prefer to just type arc commandeer D123 than have to go to the UI, find the diff and commandeer it. I suppose that I'm being lazy, but the exact same argument exists for arc close-revision or arc upload.