I believe this is effectively complete. We'll probably look at revising the control itself at some point, but I think it's likely fine until we do a more complete iteration on these UIs as part of T6943.

Presuming resolved, yell if anyone's still running into issues.

This has been implicated in other crimes by @csilvers.

I'll find a way!

I'm tentatively going to close this out, but yell if the "Private Correspondence" thing sucks and we can find another approach or find ways to refine it. I sleep better at night knowing handles aren't loading other handles, though.

Implement a new subclass of PassphraseCredentialType which works like PassphraseCredentialTypePassword but stores a large block of text (like a configuration file, or a secret will, or the eldritch words of command which must not fall on mortal ears). This could be called "Note" or "Block" or "Blob" or something similar.

You've hit this too, do you want to try to figure it out?

This is probably a one-line implements PhabricatorMentionableInterface on PholioMock.

• One possible cause of this is the application not being installed. If so, the documentation should make this more clear.
• Another possible cause is the active link to phabricator.example.com being confusing.
• The current modern approach to communicating how to get places is to use the {nav X > Y} element to show the user how to navigate: Applications → OAuth Server → Create Application. This is more resistant to UI/URI changes and teaches the user how to use the application.

• Add an 'outdated' (or similar) key after 'updated'.
  • It should map to the vector array('-updated', '-id').
  • Give 'updated' and 'outdated' human-readable names which better reflect their meanings.
  • It should appear after 'updated' in the order list.

Oh, I guess T5681 is the better fit, although the two are closely related.

(And likewise for View Policy.)

Folding this entire distinction into a modal choice at creation time seems reasonable to me.

It's technically accurate!

I plan to add a "note" or "text" type to Passphrase to handle this, but there isn't a good approach now.

I got bored and went ahead with this.

OK, after creating a user I made some progress... but now I hit this:

Ah actually, this seems to only be an issue when there are no issues in the database.

I think I can cheat it in in like 3 lines of code so maybe we can try it and see if it sticks out.

I think the current state is good and would want to keep it in all the non-handle UIs (menu, Conpherence, column, etc.). I'm pretty sure the only places you actually see a Conpherence handle right now are:

Development Log

static title for untitled threads

Well, I think I figured this one out. No one look at the diff, it's real embarrassing.

@btrahan, per D13216, I'd ideally like to stop this class of problem by getting rid of the need for Conpherence threads to load other handles in order to load their own handles (I believe they're the only case where we do that) but that seems a bit tricky since we need them to generate the titles of some threads.

As a possible attack on this, we could rename phabricator_pastebin to phabricator_paste first and see how awful that is.

On our install, this data is ~250MB.

Yeah, we migrated a long time ago and also never hit issues.

I started working on this in D13094, but it's nowhere near finished.

Haha, thanks for collecting these. I've been meaning to do that...

I don't, but it maybe stops bad things from happening in cases where destruction takes a bad time? I was destroying a Diviner book and it took a long time so I ^Ced it and ran it again with --trace. I wasn't too worried in this case because Diviner books don't utilize a lot of infrastructure. But for other objects, this could be problematic maybe?

To tie in some context:

The index should update without needing the daemons, but that code did get touched in connection with T6367, so maybe I fixed something by accident.

Seems OK here, here's the create / detail / search UI:

Thanks!

One thought -- what type of field were you using? I tried reproing it with an "int" field, but maybe the issue is with certain field types or something like that.

It's only issuing one statement so it will jump from 0% to 100% after adding the key, but it might take a bit if you have a lot of data in the table.

Presuming this is resolved, but let us know if that doesn't work for you.

Write "7 days ago" or "-1 day".

I believe the error is now fixed at HEAD.

I believe this is now resolved in HEAD, but let me know if you still see it after upgrading.

FWIW, I do think this UI is poorly designed, and it's reasonable for users to find it confusing: it teaches them how to do something, then takes that away from them.

Why do you need to destroy enough objects for this to matter?

D13205 is a possible fix; if that's the issue, a workaround is to avoid mentioning any users with @mentions in the summary, test plan, or other description fields until it lands.

Do the problematic revisions mention a user with @username in the summary or test plan?

If it reproduces via the web UI on your install, try to hit it on this install by typing stuff in here:

Thanks for the stack trace, in any case -- I'll keep digging; if you can come up with a repro case on this install that might help get things resolved faster.

I'm not immediately able to reproduce this. Does it reproduce for you on this install?

On this task, I got the second email, but the addressee list for the first mail was not computed correctly. This might already be resolved by changes attached to T8455, or might be a general issue related to T6367. I'll look into it.

Use bin/config delete --database phpmailer.smtp-password to delete the database value.

Over time, we've generally increased the barriers faced by new contributors: they were previously lower, and with lower barriers we accepted a number of changes which were net negatives for us in the long run. It is harder to get changes into the upstream today than it was a year ago (and was much harder then than it was in 2011).

(Test...)