From elsewhere, it would also be nice if this tokenizer highlighted instance members of instances associated with the billing account. There isn't a straightforward way to determine which "joe" or whatever is correct right now that works better than "ask Joe what his account name is".

See this document for instructions on getting Phacility support:

From elsewhere, it would also be nice if this tokenizer highlighted instance members of instances associated with the billing account. There isn't a straightforward way to determine which "joe" or whatever is correct right now that works better than "ask Joe what his account name is".

The driving use case for this fell through, and I no longer plan to pursue it.

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

T10358 discusses a case where we use (valid, spec-compliant) JSON for presentation, but could use an alternate form which is more human readable (specifically, when displaying unicode characters).

The resolution of T7053 should indirectly resolve this.

Resolved via email.

I do need the user deleted. It is new and was created incorrectly. I just want it gone. I'll send a mail.

If you definitely want to delete the user (usually, it's better to just disable users), can you shoot us an email at support@phacility.com with your instance name and the user you want deleted?

What are you trying to do and where? Is there a reason to delete vs. just disabling the account?

As a minor technical point, you're trying to create imported repositories (i.e., import repositories from GitHub), not hosted repositories, right? This endpoint can't create hosted repositories at all, AFAIK.

This endpoint is very old and has a lot of problems, including not being cluster-aware. In the Phacility cluster, the web host and repository hosts are separated. repository.create can not create cluster-aware repositories.

Presuming that answers the question, let us know if not. T7148 is the general production task here.

Unsatisfying conclusion here, but:

(We caught up in IRC.)

Thanks, we're investigating. If you have any other specific details, let us know.

Yes, with caveats. See T7148 for discussion of why this is complex. Roughly, here's the state of the world today:

We have plans to beef up Projects (subprojects, sprints) in the near future. We can't run 3rd party code on the cluster for security reasons.

Cool, glad things are working again.

Also, we certainly disable and re-enable users occasionally, so hopefully that will continue to be a supported use case.

@epriestley, I got a flood of emails starting at 1 PM, thanks! I'm not aware of any further issues with this.

The queue has flushed so I think this is now resolved (there are no longer any publish actions backed up in the queue), can you let me know if you're still seeing issues when you have a chance?

I've deployed this to repo001 (where this instance's daemons are located) and the queue appears to be flushing. I'd expect that you'll start receiving missing mail shortly (there are about 100 affected commits in the backlog). I'll follow up in a few minutes once things flush or otherwise stabilize.

Effectively, I think this is a variant of T9067. I'm going to patch this narrowly since it's straightforward.

Actually, I'm less sure that this is credential-related.

There's a specific issue with a subset of commit-related mail not using the right credentials to hit the API locally. Here's a characteristic trace:

On meta at least, I receive email fine.

Looking into this now, this is likely related to key cycling (see T7399 for details). I suspect something is just out of sync or needs to be restarted, let me figure out what's up.

D14137 (with the new prompt) is now in master. It will promote to stable in about a week. You can grab it with arc upgrade.

That sounds great to me :)

D14137 replaces the prompt with this one:

Darn :( Introducing language specific calls sounds like a very complicated and fragile change for something like this. I don't think it will be too big of a deal :) Thanks for looking into it.

Actually it looks like these states aren't distinguishable from git diff --raw:

Awesome, thanks :)

Our behavior here is strictly wrong. We ask you a question:

So I talked to some of the other people working on my project and we're ok with .gitignore'ing the .iml file in our submodule so it will get rid of the issue if you don't have any changes and if you have changes then you either have to live with the prompt or commit to the submodule first.

Ah, okay, so the missing steps are something like this:

Uhg, it only shows up if there are changes in the submodule. So things like the .iml files will trigger it to show that and then cause an arc prompt for asking about it

I can't reproduce this. Here's what I did:

Cool. Let us know if you run into anything else.

There's no easy way to browse configuration without being an administrator because some configuration may be vaguely sensitive, and some of it depends on other configuration or module availability so we don't (and, broadly, can't, at least in its current form) export it as flat documentation in a text file or HTML or whatever.

Got it all working :D thanks

Is there a list of all the flags you could give me? I can't seem to find one

My guess is that differential.allow-reopen is set to false (the default value), which disables the "Reopen" action. If you (or an administrator) change this setting to true in the Config application that should enable the action.

That is on a closed revision

When you scroll to the bottom of a revision page (the URL should look like /D123), you should see something like this:

Does Differential look different than this for you?

See T9408. A security researcher found a low-severity but practical attack against our implementation of dot.