Also, Support has basically moved to Discourse now.

From https://discourse.phabricator-community.org/t/how-to-get-custom-field-of-transactiontype/1532 (and my followup research), there doesn't appear to be a way to extract custom field information using conduit (or Herald Web Hooks).
transaction.search actually lists type as null and no fields.

👍
Javascript is !!fun!!.

lgtm

See also long chatter in https://discourse.phabricator-community.org/t/request-less-obtrusive-status-updates/1530.

Very soon now, git is getting an exciting new wire protocol. Highlights are improving performance on repos with unholy amount of refs, and being "easier to expand".

This is probably much clearer now.

Want to counter-diff, @eadler?

See PHI251. This requests an "Ignore generated changes." option for Owners.

Historically, an issue with this was my hesitance to add more "Add Owner As Reviewer If Moon is Full" builtin rules to Owners: Herald already allows you to implement arbitrary rules with Owners, and an implementation of Herald where every possible rule is a dropdown option obviously isn't very good.

Incidentally, the first page shown after the install (as of 4dc8e2de564f48) is a white exception page with [Core Exception/Exception] Define 'phabricator.base-uri' in your configuration to continue..

install_ubuntu.sh seems to be completely broken for modern Ubuntu. I don't mind updating it, but I think we discussed dumping it completely?

Oh, good, it's about time this task be created!

(What's \z in the regexp?)

I'm wondering how this should interact with T8407: Control diffusion's syntax highlighting.

Appears to be broken for non-draft revisions: https://discourse.phabricator-community.org/t/openning-any-differential-fails-with-undefined-variable-object/1216

👍

Are there cases of "added subscriber" that don't/shouldn't count as mentions?

That kinda makes sense, and kinda confusing. Maybe we should show this information somehow - under view details for the creation, or just consider reviewers/subscribers/project as special cases.

(I don't see any "added subscriber: avivey" transaction, but I'm subscribed)

For what it's worth, I think the Mute feature adds a lot of complexities to the system, in excess to the norms of the last few years:

• Code to handle it in the sending mechanism
• Prioritizing this feature against any other notify feature (like T9031)
• UI to show the to the muting user (on the object and in /mail/?)
• UI to show to other users that this user will not be notified (What if all members of a project are muting a thread?)
• Can a mailing list/project mute a topic?
• "why did I not receive this notification?" - there's still some issues about this - novice users don't know/understand /mail/, and admins can't see this for them. I suspect this question will require a written checklist somewhere.

If all you're going for are emails, why not spin up your own Exchange server (or whatever the kids use these days)? With maybe forwarding to a epriestley-phacility@gmail.com so you remain compliant?

not applicable...

This was mostly a preemptive change for me, because my users are more likely to be confused by it. I don't mind forking it if you'd like to keep the poem...

You need to clear some caches too - ./bin/cache purge - but I'm not sure which; And then hard-refresh the in the browser.

Those are really good points, thanks!

Re-implement using EngineExtension

https://phacility.com/ is still giving ssl error - it's net::ERR_CERT_COMMON_NAME_INVALID, I think (Maybe *.x doesn't cover x?)

I could add an isAvailableInGlobalSearch() method to PhabricatorTypeaheadDatasource, but it felt like there are too many of those to filter in run-time.

From https://discourse.phabricator-community.org/t/644 - it appears that HM now triggers a build on revisions when they are closed via landing, which fails because the build expects a Staging ref. I don't have the setup to test any of it, but the latest revision landed here doesn't show the behavior, so either f7f3dd5b2084 hasn't rolled in here yet, or that user is doing something funny.

Also, is there a "help" section for this?

Maybe call the parameter temp file name?

There are 4 copies of the important rules because:

1. !print transformation doesn't handle selector, selector rules, which I guess could be fixed in some way.
2. At least in my tests, .device-desktop .phabricator-action-list-view + .phui-curtain-panel {...} beats @media print { .phabricator-action-list-view + .phui-curtain-panel { ... }}, so it needs the !print .device-desktop variant.
3. In my Chrome, the print layout depends on the width of the window that prints - if the window is narrow enough for .device, the print css gets the .device tag. I'm not sure if this is javascript or media calculations? That makes the !print w/o device-desktop needed (Although I guess since it's mostly the same rules as the .device variants, we could get rid of those?)

remove border-top

• Use !print more
• Also remove background when printing