I can give you an extension for this in about 15 minutes (at consulting rates).

You can't currently examine the most-recently-applied set of transactions, although we could reasonably pass them down and expose them.

I'd like to remove this event, because (a) it doesn't work right and never has and (b) all use cases we've seen are better suited to either Herald or mechanisms covered in T5462.

Can you do that with Herald instead?

What does the logic in your listener do?

Thanks! Should be fixed in HEAD.

Yeah, I'd really like to just get rid of this option. It's definitely not something we'd accept upstream today.

Sorry about the delay... here's the trace from running /bin/storage upgrade --namespace testT9773_$RANDOM --force --no-adjust --trace:

Gah, details of the Herald transcript have already been garbage collected.

Out pf curiosity, why not use the @{article:...} syntax instead of copy-pasting the full URL?

We haven't seen other installs encounter difficulty here. T5055 will eventually build some flavor of first-party package manager which should address a large superset of this problem class.

D14523 possibly describes a cleaner fix for this (special case autoloads when class_exists() is on the stack).

Who does the transcript show as the "Reviewer" for the change?

This is intentional, consistent, documented, etc.

No one else can reproduce this. storage upgrade --trace ... might provide some insight, or add --xprofile to that or whatever. We can look at it in more detail if you can narrow it down more.

This report doesn't appear to describe a specific problem.

It's intentional that we normalize the slugs to try to make typing URLs a little more forgiving: For example, if you go to any of these links:

Just to set expectations:

There were some changes to slugs about 6 weeks ago (D14260, D14261, D14287) but I don't think they would have affected this.

Since we can't reproduce this, I'm not sure how we could fix it.

This task doesn't contain enough information for us to reproduce the problem you're encountering. Please see Contributing Bug Reports for an outline of what we need in an actionable bug report.

I have made these changes to the planning document which are hopefully more clear:

Just to confirm, there are no plans to implement this within some timeframe, right?

That isn't what the planning document is intended to convey. I'll update it to make it more clear.

I've been using the ((alias)) syntax pretty frequently and it's been really helpful -- we have a bunch of documentation we point people at all the time, and before Phurl I'd open a new tab, search for the document, copy-paste the URL, and maybe put some [[ ... | nice title ]] syntax around it. Now I just ((thing)) and it's way easier. The search + copy/paste workflow wasn't hugely time consuming, but it was really annoying.

Phurl (T6049) is still a prototype and not yet documented.

@polybuildr, please see Planning.

This Phabricator install is not related to Wikipedia.

We don't plan to support these webhooks.

Cool. We definitely want to make dashboards easier to use in the future, but it's entangled with a bunch of "Welcome" / "Role Profiles" / "New User Experience" stuff that makes it a big project. Maaaaaaaaaybe Q1 2016-ish-ish. Maybe?

Just to make sure I remember things, specific issue is:

Alternatively, you could use a dashboard to provide the "executive dashboard" view, and bring text into that with text panels:

1. Create a query in Maniphest with the stuff you want to show.
2. Save it as a named query.
3. Create a new Dashboard panel with that query.
4. Embed the view with {W...}. For example, here's {W402} on this install below (which shows a few recent tasks in Phriction):
5. You can delete the named query now.

We need to hard-wire stuff like that, Herald can't do "after X days" and I don't plan to add that capability in the near future.