So I think I can lay the groundwork here. My plan is to:

Probably go with data driven. I don't think these need to be sprited, but should probably inline CSS (base64) with celerity? I don't think these will be large enough to need to be in an image sheet.

I'm not completely opposed to ever changing this, but I think there are pretty good reasons for the current behavior.

This report isn't actionable. Feel free to file a new one that is:

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Basic support to (hopefully) support svnsync is now deployed. The Herald stuff would be nice to have eventually, but we don't currently have any real use cases for it.

From T10610, this can reasonably occur in arc unit subprocesses.

Sites eventually got split out (T5702) so that's no longer an issue, but this still isn't really straightforward. We do a lot of object loads which need some real viewer (blog, post, other adjacent posts, author, subscribers, object references in remarkup).

This still hard?

Closing as Resolved in general. T6299 and T4936 are already in the system separately.

(I don't know if this is the exact same bug, but we'd fix them both in the same pass)

Nice! Thanks.

I don't know offhand, See T10978, we have a lot of cruft in Audit that just needs tossing out.

Never noticed that before? Is this specific for Audit?

This is our expected use of Flags. They already exist on most objects, and users can build/query/sort them as they like for whatever reason.

Yes, that totally makes sense to me (and, in fact, that's what I suggested by teammates do), but even an ability to use Herald to automatically flag an audit based on comment activity would go a long way here.

Some relevant discussion in T1112, although it's more Differential-oriented than Audit-oriented.
T5722 is also probably related.

Some more info I dug up:

• There are 2 commits that appear to have flipped comments, i.e. the comments that appear on audit1 actually apply to audit2 and vice versa.
• These commits are sequential and were pushed simultaneously (i.e. the author made multiple commits on master locally before git pushing them all)
• In both cases only comments made by the author appear out of place.

I was picturing this as more of a tool to help the author keep track of things that may require attention rather than an auditor to verify that something is done.

I was picturing this as more of a tool to help the author keep track of things that may require attention rather than an auditor to verify that something is done.
This also allows for a workflow where a comment is made after the audit is closed that is not worthy of reopening the audit (and potentially by a 3rd party). And it could be both "I'm late to the party and I have input" kind of scenario and "I'm an intern and I have a question about this change 3 years later"

That's my expectation if something is accepted. That the author is trustworthy enough to follow up if needed or ignore if it was just a suggestion.

That almost works. The problem is that as soon as the audit is accepted it fall off of everyone's radar and there is no visibility into the comments an auditor may have made.

This doesn't sound like a desirable solution to the problem. If something requires addressing, raising a concern is always the correct action. If it's not an urgent issue, but the author wants to address it, they can flag the audit for themselves as a reminder to follow up. Is there something about the core problem maybe I'm missing?

I think it starts out as a URL, and then replaced on the client-side with the name after some AJAX. Most of the time I don't have time to see the "before" text.

I don't understand why it's a tag. Does the JIRA link look like a URL or an actual name?

css is it's own world of magick.

I'm faking my way through it.

Here's Chrome's Style page for the element:

I'm just surprised to hear something is still overflowing after D16081.

DoorkeeperTagView is also used for DifferentialAsanaRepresentationField, which is probably easier to set up (?).

The value is rendered here: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/differential/customfield/DifferentialJIRAIssuesField.php;70463e8a16d4cbe0c83b23b9328c4a359072c506$53

I'd need to see it to fix it. These are tags?

Alright, thanks for clearing it up, and sorry for calling it a bug :) I am new to phabricator, trying to see if I can configure it for my needs where permissions have a big role. Maybe I should explain what I am trying to do, so my request maybe makes more sense. You are of course welcome to close this task as wontfix, I just, as a new user, found it confusing that the edit policy wasn't strictly enforced around the application, view policy seems more strict though, which is nice :)