Maybe I'm misunderstanding what you mean by "attributes"? What's an example of what you mean in some other search engine?

Presuming resolved; you can already use Watchers: viewer() or Watchers: yourusername to find projects you are watching in an ad-hoc way.

Oh, the upload control ended up better but not great, but I'm not going to specifically file anything for that since I don't think we'd pursue it on its own and don't think we'll forget about it when we next do adjacent work.

I think this stuff remains:

I don't think this is about inline comments, since @ajklen says "comment dropdown menu" and inline comments don't have one. I believe they want this, in the existing dropdown menu of (non-inline) comments:

I think the author is essentially asking for an easy way to map inline comments to the diff that they were originally made upon.

No. It's not that the builds can access credentials on the build hosts -- that part is a general problem -- it's that the Phabricator application hosts can be made to divulge their credentials (which are necessarily the same as the S3 credentials, because the same hosts must access S3) by instructing them to run builds that use 169.254.169.254 as a "build server".

In T5155#223416, @epriestley wrote:

As a general note here, we've been vulnerable to credential theft from the local service throughout this discussion, and still are until T12701 resolves: attackers can create a Harbormaster build plan which sends requests to 169.254.169.254, then read credentials from the output of the "failed build".

I think this is generally reasonable, but probably on the far side of T12010 since it implies API changes.

Users can also currently add http://169.254.169.254/ as a Git repository, although I'm not certain if they can actually capture credentials by doing this.

As a general note here, we've been vulnerable to credential theft from the local service throughout this discussion, and still are until T12701 resolves: attackers can create a Harbormaster build plan which sends requests to 169.254.169.254, then read credentials from the output of the "failed build".

T11632 is vaguely related.

Oh, no problem -- we likely won't look into this for a while anyway (T12664 is a big mess of related issues that we'll probably try to fix all at once).

See Contributing Feature Requests, but also note that we're likely to restrict this channel soon because no one reads that document (see T12134#212579).

(We probably won't look at this until T12664 moves forward, but when it does it would definitely be helpful to have a specific set of steps we can take to reproduce the issue locally in a clean repository.)

I don't think this is a bug: both systems are behaving as designed.

See Planning.

You're on the wrong install by mistake.

You're on the wrong install by mistake.

You're on the wrong install by mistake.

I think you've filed this against the wrong install by mistake.

I'm having a tough time picking pieces apart here so that the transition is gradual -- many of the remaining behaviors are highly connected to one another and hard to tease apart. Things feel fine up to D17846, but even D17859 breaks enough stuff that I don't feel great about it, and doesn't seem to have pushed me through things enough to emerge on the other side.

• If you want to implement backslashes or thunderclouds as escape characters, feel free to do so locally. I don't plan to bring these changes upstream.
• If you want to strip zero-width spaces or escape literals, feel free to do so locally. I don't plan to bring these changes upstream.
• I do not plan to implement any sort of generalized inline escape character, sequence, or block in upstream Remarkup at this time.

Yes, it would be very easy! Feel free to implement such a rule locally.

Okay: H3

You can't explicitly subscribe to a revision you're a reviewer for because being a reviewer makes you an automatic subscriber (and, due to a similar bug to the one here, probably can't subscribe even if you've resigned, today), so you'd need to resign, then explicitly subscribe. Also, I'm not sure we handle the other way (explicitly unsubscribe, then later become a reviewer) correctly. These are tractable.

Perfectly clear.

In T12689#223076, @epriestley wrote:

(But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

• There's probably one fairly narrow bug bug here: DifferentialTransactionEditor->getMailTo() likely includes resigned users but should not.
• Beyond that, when you've resigned, we should probably exclude you from getting indirect mail via a project/package? Maybe? (But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

rPbcd87e0e3f3756970d26d5e9c4a60e4be73ef6a6
rARC3c4735795a2963c5ddff6dceaf60122d01ca3dc0
rPHUa900d7b63e954e221efe140f0f33d3d701524aae

(It looks like I wrote this string myself, in D7159.)

Oh, the error just wasn't clear to me. I thought it meant "You must upload audio." in the sense of "you did not upload anything, but needed to". It actually means "You uploaded a file, but the file isn't a valid audio file as far as Phabricator is concerned.".

I'll poke at it.

Here's what I'm seeing locally in Safari:

Just noting that this cat is perfect and DOES NOT need any design improvement:

We might eventually support a trade/resale market -- one advantage is that we could give contributors something with slightly more valuable than stickers/flair/badges, but less complicated for us than doing fulfillment on schwag or dealing with taxes for actual money.

Everyone loves Opportunities For Improvement!

This stuff is probably going to churn for a bit but I'm pretty sure I'll forget about that thing if I don't write it down somewhere.

In View Options → Collapse File, we get into this sort of oldschool state:

T10469 is vaguely related.

I couldn't find them either but I understand:

Oh, isViewableInBrowser() is the wrong check, and includes things like text files. Should be isViewableImage().

Might be pre-existing. Source file is:

At this time I'm presently unable to sign a CLA (apologies) due to employment situation, however what I can do is make the following diff Public Domain and relinquish any claims to it, should Phacility wish to correct this behaviour in upstream Phabricator.

• Override willConfigureFields() in MacroEditEngine.
  • This fires after extensions add fields (so "Subscribers" will exist), but before form configuration acts (so users will still be able to turn the field on if they really want, by creating a form which enables it).
  • $fields is indexed by by field key. Ideally, we'd move 'subscriberPHIDs' to some constant on PhabricatorSubscriptionsEditEngineExtension, then use that, something like this:

• I couldn't realllly find any bona fide new issues with Ponder.

Just the input on the create form, not the feature wholesale, right? Let me finish up (just Ponder left) and then I'll dig it up, I'm pretty sure there's a method you can use for it but we don't do it very often.

Sorry about that! Thanks for the report.

Possibly we should just remove this flag because bin/storage status is equivalent and bin/storage adjust prompts by default, buuut...

Not at all! You can just buy an extremely expensive personal support plan and continue controlling 100% of the roadmap based on personal whim!