New APIs are going out tomorrow morning (Saturday, February 27). I expect to unprototype Almanac shortly after that, provided things go relatively smoothly, so it will become available the following week (Saturday, March 5).

Thanks!

Hmm, alright -- file a task and I'll take a look when I have a chance. I don't expect this to require any weird magic.

I tried that and it gives the same complaint.

It looks like that can leave two external (LDAP) accounts pointed at the same Phabricator account. If that's working, great. It will be supported explicitly after T2549.

is T5954 really a fully blocking Task of this feature?

is T5954 really a fully blocking Task of this feature? Forgive my ignorance as I haven't worked on or even looked at the codebase, but it seems that adding all task fields as additional columns to an Excel download would be relatively trivial?

Awesome. That worked, thanks.

Please see Support Resources for how to get support using Phabricator. This doesn't appear to be a bug report.

That's correct. There is no Audit per file, just per commit. Depending on what you're trying to accomplish, maybe T4348 is what you're looking for?

In T10449#161931, @dtf wrote:

Shouldn't restricted repositories short-names be rendered as [ Restricted Repository]? Sorry for this off-topic.

In T10449#161836, @epriestley wrote:

I also have a small patch against rCORE, but it's pretty minor and I can't really test it fully until the rest of this stuff makes it into production.

This is the script that we had been using to do this which looks like it aligns cleanly with your second bullet point.

Oh, there are also really two issues here, but only one that I think is actually hard:

On external account mangling in particular:

Yeah, that's broadly the "think about" part in the task title -- I don't have a good answer. I'm not quite sure how to reconcile diffusion.edit with the current multi-page form.

Doesn't making an edit endpoint that is similar to the ApplicationEditor endpoint bypass the multi-page setup (And lets people shoot themselves if the foot)? RepositoryCreateController seems to be fully transactions-based now.

Some possible tools that may form part of a solution here, roughly in order from greatest upstream willingness to greatest upstream resistance:

I changed the unit file to this:

Probably a really quick partial remedy to the fallout (not root cause) is just exploring ways to make it super obvious to people that they shouldn't be interacting with disabled accounts.

To explain the hairiness of this a little better in our case, the actual "migration" procedure looks like this:

There's also mode=recurring... all these seem to do is change different default options on the form. Should I try to implement form edit engine support for this @epriestley? Would you be prepared to review it?

I did some digging through the source code and found PhabricatorCalendarEvent::initializeNewCalendarEvent which does this:

if ($mode == 'public') {
  $view_policy = PhabricatorPolicies::getMostOpenPolicy();
}

See also T7643 and T9294

As a note to myself, I also need to adjust config for instances after pushing this, since empty values are now explicit. This only affects a handful of instances and they're easy to identify, so I may just do it manually rather than trying to write a migration.

I also have a small patch against rCORE, but it's pretty minor and I can't really test it fully until the rest of this stuff makes it into production.

Subscribers were removed from projects, so this policy no longer functions.