Ah ha! Yes, I totally missed those little gear off to the right. Thanks very much!

You should be able to configure this in:

Ignoring the actual invite workflow for now, the major technical issue with supporting this is handling the eventual merging of accounts.

Yep, @epriestley has nailed the scenario exactly. I'd like use of Phabricator to spread organically (hopefully virally) through the org. That makes user commitment to it much stronger - and it gives me a measure of how enthusiastic people are about the tools and whether we should commit to it.

You can just type 500 email addresses into this box (and, at least locally, it works fine, although admittedly I haven't done it in production personally):

I think that @oliver.fisher's use-case - this ticket and T9297 has more to do with initial on-boarding to Phacility/Phabricator, and bulk-creation of accounts.

I'm not familiar with @oliver.fisher's case or the numerous situations that Phabricator would need to account for, but this problem sounded relate-able to ones we've come across in the past.

This is desirable, but a bit involved, particularly in the cluster.

Awesome! I'll see if we can clean up that login-error-state stuff soonish. Let us know if you run into anything else.

Thanks for the quick turnaround! Just went through it with a couple of people and seems to be working great.

This is now deployed to the cluster and I've updated the configuration for your instance. You should be able to see the domain on your instance page, and the configuration change in the transaction log in case I spelled it wrong or something silly like that.

That would be awesome! I've shown Phabricator (Differential specifically) to a few people and used it for some changes. They've basically gone crazy about how awesome it is (they've only known github PRs). I'd like to have them start spreading the word virally in the org without me. Something like a multi-use invite link would work well for that, although are certainly other approaches. Thanks!

There isn't really much of a workaround available at the moment, but I think we can get the feature deployed in some reasonable form by later today.

Yep, that sounds pretty much perfect.

This isn't currently supported, but I think it's reasonable to implement. Behavior would roughly be something like this:

This task made for a good read.

The specific UI (Phacility → Instances → (Choose an Instance) → Adjust Configuration) in question doesn't actually use PhutilJSON to format the output right now, so it's still rendering the less-preferred form:

Is this complete?

Awesome! I'll keep this around as context for getting the root issue fixed. Thanks for the report, and let us know if you run into anything else.

Another possible workaround would be to go find the credential in Passphrase and just update that, assuming the rest of the configuration is correct.

The edit link you provided let me fix my private key. I'm pretty sure I'm good to go now.

Er, sorry, had the wrong URL in the previous comment. Should be correct now, I think.

If you manually go to /diffusion/COLP/edit/ does that work?

I'm almost certain I put in the wrong SSH key.

We should improve the error handling behavior here. Because this is a clustered repository, we're failing more abruptly than we would with a non-service repository, but we should make the behavior more similar.

Just to follow up on this, the transcript will show this at HEAD once T8726 lands:

Have a free badge.

Looks like this is in good shape now.

Ah, perfect. Yeah, either contact@ or support@ will work fine. Thanks!

Cool, I'll get this importing. Do you want to shoot us an email at support@phacility.com to coordinate the rest of the import? There might be some private questions later on in the process about data specifics in case we run into any issues.

I'll email contact@phacility.com with this info. Thanks again! :)

Ah! Drag-n-drop worked like a charm.

Are you dragging and dropping or using the upload button? The drag and drop should chunk the file.

Looks like my phabricator_data.sql.gz file is bigger than the post_max_size setting.

Also https://admin.phacility.com/book/phacility/article/importing/ has a rough overview of the process and https://admin.phacility.com/book/phacility/article/limitations/ notes any limitations, I should have mentioned those first.

Not a problem, go ahead and make an account on Phacility and whenever you're ready:

In any case, glad to hear this is working now! I think the UI should improve pretty soon (next week or two-ish) for this specific class of problem, at least. Let us know if you run into anything else.

Upcoming changes related to T5791 and T8726 should increase debug-ability, but giving web users access to mail is tricky while still respecting policies (e.g., administrators shouldn't be able to violate policies by just reading other users mail) and limiting the ability for an attacker to escalate access (e.g., an attacker who gets an admin account shouldn't have a blank check to access every other account by reading other users' "Welcome" or "Password Reset" mail).

I'm learning stuff here today too, not a waste at all.

Never mind! Not only did my latest test task come through, all the previous ones did too. There was a few minutes delay but it seems to be working now. Thanks a ton for you help.

Test above wasn't quite right. I have now added the user to the "Signifyd Employees" project as well:

Suggestion makes sense, but does not seem to have worked. I added the user in question to the project:

Specifically, you could get the behavior you want by changing the visibility policy of the task (so the user can see it) or adding the user to the project (so they satisfy the current visibility policy).

It looks like T1603 on your install has a project visibility policy (i.e., the task is visible to members of a specific project). However, I think the user customer_support_pagerduty is not a member of the project, so they can not see the task. (I'm just looking at the database here, so it's possible I got the WHERE clauses wrong.)

Thanks for the quick debugging. However, I don't think that fixes my real problem (not your fault since I didn't tell you what that is). The rule was originally to trigger an email to a mailing list user (a PagerDuty integration email specifically). That "user" does not have the don't email for self actions action set (and even if they did, I'm the one creating the bug so it shouldn't apply). Those emails weren't going through. So I changed the rule to email me as a debugging step and found that I'm not getting the email so figured that was the root cause. As you suggest, if I change my preference so I get emailed on self-actions I then do get emails. However, if I change the email back to the mailing list it is not getting emails. Perhaps there's something else blocking these??

Oh, I thought all Herald rules were stronger than preferences.

Here's why you didn't receive the mail:

I can't reproduce this. I made this rule:

I can confirm, Rule says it passed and it emailed me, but I received nothing.

Attaching screen shots of the rule and the task that I think should have triggered it:

T7607 might help here as well.

Yes - it would be great to have a "billing contact" email for these kinds of things.

This is a valid, compliant JSON-encoding of the string, which allows / to be escaped -- here's the grammar diagram from json.org:

This looks like it was primarily caused by operator error. I stopped some services on the paired repo host in order to recover db001 in connection with T8764 yesterday. This worked, and let me revive the host immediately rather than needing to restart it, but I then failed to completely restart services later.

Thanks! We are receiving emails now

I think the immediate issue is now resolved, I'll look at this in more detail and post a followup a little later.

Looking into this now.

Thank you for the fast response, as well as the credit. We appreciate it. Cheers.

I believe this is now resolved. Thanks for the report, and sorry for the duplicate mail. I've issued your instance a service credit for the last 48 hours, which will be reflected on your next bill.

Repository tier is restarting now with D13319, so this should be fixed in about a minute.

D13319 should fix this specific issue.

The issue is roughly: