In T1279#176531, @epriestley wrote:

"reviewer list" referred to an element which was removed in 2013, and replaced with this one, as part of this task:

I'm unclear on whether or not any of the recent changes are usable right now. Is there any way to actually limit access by project right now? It would be helpful if the task description was updated with a checklist of things that are (not) supported.

@chad it must be a misconfiguration somewhere on our end... i see both a "no cache" header and a past date for "expires":

@chad i tried before and couldn't...

@epriestley sorry it took a while to follow up on this, but it's still happening after the upgrade.

After upgrading to the latest version of code, I am still seeing the exact same behavior: when making an comment, the inline comment images are reloaded and are not cached:

I will update our local instance and see if the issue goes away. And FWIW, I'm not on dialup, but rather a 3G tether.

@epriestley that's from Chrome Devtools (Network pane). They are definitely network requests and not cache. There would be a (from cache) and color change on the line item if it was cached.

@epriestley perhaps it only reloads when there are multiple images on a mock? I was not able to reproduce with a mock that only has one image and no revisions. Commenting on a mock that has multiple images and multiple revisions resulted in this (using Chrome):

Okay, so T1895 is somewhat related, but not completely. I fail to see how this is strictly about Pholio though, as the exact same problematic behavior (refreshing inline comments) can be seen in Differential.

It's not just Philio, but also Differential.

As an alternative UI to what is currently implemented, why not do this?

This works as expected.

Works as expected.

I cannot destroy it, as shown in the paste above.

The recommendation of using bin/policy does not work:

Thanks!

That would be satisfactory.

That's what we are doing now, and it sucks because the Unassigned group comes first and is very large, which pushes some of the assignees off to later pages, which hurts the overall visibility.

Do you think this issue is so serious that it's the best use of your time or our time?

You might think that the other palettes are "close enough" [...] claiming that the "Red" should be "Brick", or the "Violet" should be "Lilac"?

So if the colors are "based" on ROYGBIV, where do "grey" and "checkered" fit into that spectrum? There's amusing things like "clowncopterize" and then there is completely childish stuff like saying "look my green shirt is red because i say it is". This is absolutely, without question, the latter.

s/Easter Eggs/lies/ ? this is just plain silly, c'mon...

@avivey in fact using --format=full is enough to show that:

See also T5580

+1 for this, and it is tangentially related to the Land to Github button as well, which should use the author's token (not mine).

It only breaks if Phabricator is able to resolve the wiki link to a wiki page.

@btrahan good catch on the title. :)

Looks right. Can't test locally because I don't have any users in queue ATM.

It worked:

Makes more sense now. Thanks. :)

+1 for "changes since last diff" link.

After reading T3820, I don't really see a fundamental difference between the intent of this issue.

Maybe this is caused by my custom time-of-day settings? For the record, I have it set to M jS, Y G:i a.

And when I get an email:

Nevermind, it looks like that is just crappy parsing of the date by the filter... If I use a more verbose date, it works properly:

Doh, forgot that adding dependencies to diffs automatically handles the diffs. Patch works fine now, but the filters don't appear to work:

Attempting to patch on top of D8595 gives me an empty commit error. Not sure what is going on there...

It appears as if I was not logged in while running the query, but I was definitely logged in (my instance does not allow anonymous access).

After patching this and attempting to run a query against my custom "due date" field, I got this error:

Okay. I'll try patching it in the next day or two, if it isn't landed by then.

Does this also implicitly enable sorting?

Maybe only expose this to admins? Or is it implicit that you cannot see this view unless you have the ability to make approvals?

@chad that mock definitely looks like it is headed in the right direction. redpen.io uses this same style of comment "pins" and it works well.

FWIW, I just noticed that Pholio seems to control image width via browser height, which seems to be the root of the problem. If I have a narrow-but-tall browser, it looks way better than a wide-but-short window.

Well this install is planning on using it heavily. Anything we can do to help?

+1 i just did a pholio review and it was painful to switch back and forth between fullsize and pholio to leave my comments.

Here are two potentially useful scripts, one for exporting Github issues to CSV, and one for importing tasks into Phabricator:

Again, I don't think there is any argument about the flaws of this approach. But the task at hand deals with consistency of UX, nothing else.

@epriestley The use case is not so much "working copy full of junk" but more often working on multiple things at once and have not yet added some (new) files to the repo.