In T10855#172123, @chad wrote:

A Phriction Panel which we talked about briefly would provide this automagically without wiring Dashboards to Conduit.

We would be okay with this too.

We aren't really sold on this as a specific use case, but can give you a modern dashboard.panel.edit which will let you implement it. If there are weird followups arising from this (like difficulty managing the 300,000 transactions on the panel detail a year from now) we may be somewhat less sympathetic to them than we would be to a more on-label use case.

These changes are live on this install:

After D15959, user.search should support "find all non-disabled human users", likely with parameters in this vein:

I think T5953 is a better fit for that in the upstream.

FWIW is something like user.edit on the table? We'd like to be able to pre-create users with specific information such as 'real name', and a particular external account linked.

To further elaborate:

Yep, works now. Thanks

Thanks, try HEAD?

D15934? looks like it introduced "suffixes" for reviewers.

I'm not sure if this change is correct, but it seems to fix the issue for me: https://secure.phabricator.com/differential/diff/38381/

I think the output format from differential.parsecommitmessage has changed:

Oh, this is probably the correct error log:

Server-side, I have the following commits deployed:

I'm going to merge this into T10366. After D15822, this information is available via diffusion.repository.search by asking for the uris attachment. Note that:

I'm going to merge this into T10748, since that's now clearly the way forward.

Yeah in those cases, writing your own "Internal Tools Status" application would probably be better.

A few things that might motivate writing an API panel (which pulls from external sources) instead:

(I agree that this is a bad solution for notifying users of downtime/maintenance on the current instance, and that rooster/broadcast is better.)

Maybe T8145 / T5231, but I think the driving use case there was "notify users of Phabricator downtime" specifically. I'm imagining the driving use cases here not affecting all users and not directly impacting Phabricator, just having wide enough impact that there's interest in surfacing them more broadly. e.g., "We're having a production incident affecting video upload, ops is investigating" is important, but not "every Phabricator user must be notified" important.

We also talked about a "Rooster" system as well. Something outside of dashboards that is tied to a time or is user-closable.

Doing a Phriction panel, an iframe panel, or a custom API panel would also be reasonable approaches.

I think we also have a "notify my users about event x or y or downtime" task floating around somewhere else.

Here's an example I could imagine us doing: we have some button on admin.phacility.com that says "Start a deploy". When that's pressed it causes these actions to occur:

My concern is users will install their own dashboards and this doesn't particularly solve anything. I don't know what the core problem is to suggest an alternative solution.

This one seems OKish to me -- I think those use cases are pretty reasonable and root-problem-ish? I'm assuming "waht's currently broken" and "can we do deploys" are information known by some other system or tool.

Please see Contributing Feature Requests

This no longer needs to wait for T5873, since enough of that has been sorted out in EditEngine and related work that it can move forward.

I'm just going to merge this into T10337, which discusses providing modern endpoints. repository.create is a broken mess and we tend to replace it rather than fixing it (it can't reasonably be fixed without breaking the API, anyway, so we'd end up with a new endpoint in effect, regardless). The new diffusion.edit will fix this and the many other problems with repository.create.

I expect two more diffs for this task: one for awarding/revoking badges in the badges.edit API call, and one for querying who awarded whom.

Yeah, I was pondering the award/revoke flow. PasteEditConduitAPIMethod is so bare bones as an example, and PhabricatorBadgesEditEngine is so different from other edit engines... I'm just not sure how that will hook into the badges edit API method.

The new *.edit endpoints can both create and edit, so a badges.create method would be redundant.

Is there a reason, other than scope, why we're not implementing a badges.create Conduit API method? Or any of the other ones?

This is the only difficult blocker for T7673, a bad behavior which is annoying and sort of user-hostile, so I'd like to at least plan our way through it.