In T5181#170236, @jayvdb wrote:

In T5181#136123, @epriestley wrote:

In particular, I think we're going to hit cases like this:

> quack quack quack
bark bark bark

...and have no idea if "bark bark bark" is the first line getting wrapped or an inline reply, and every time we get it wrong someone will file a task complaining that we're the worst software in existence.

It would be better to reject incoming emails with inline comments from such email clients (such as gmail), as opposed to get it wrong.

There's an overview of a different third-generation endpoint, owners.search, here:

It's available on maniphest.search.

FWIW I've gotten the same feedback about the new design, and I've had the same reaction as well.

I used gmail app. I was using inline quoting, hoping to have a result similar to the web "quote" function.
The tests you mention don't include any inline quotation, and a little browsing Maniphest leads me to T5181: Parse in-line replies in email responses .

@chad: Ok, it makes sense, but in github, the layout is a small fixed one, not a full page one, thus the information is much more compact (at least on a 24" screen) and the "Author" is referenced under the issue title.

In T5181#136123, @epriestley wrote:

In particular, I think we're going to hit cases like this:

> quack quack quack
bark bark bark

...and have no idea if "bark bark bark" is the first line getting wrapped or an inline reply, and every time we get it wrong someone will file a task complaining that we're the worst software in existence.

This appears to be a Differential feature request , and is roughly the "show thread context for reply comments" suggestion on T10694 is about.

Given current progress and velocity, I'm aiming for a timeline roughly like this:

My example for this problem was with Maniphest tasks in T10790, where identical task titles is problematic in the search results.

I've started moving these changes into production (T10784) so I can begin gathering confidence that they actually work. The repository stuff definitely still doesn't work since several core pieces are currently implemented as // TODO comments, but it has the synchronization bookkeeping in place for all the locking/versioning: if that's stable, it will give me confidence that we're on relatively firm ground and can move forward.

Ah, I had found T7860 before creating this request, but that is not the same issue in my mind.

This should be resolved at HEAD of master; updating Phabricator should restore things to working order.

I happen to know this one offhand.

Quoting and signature stripping works properly in major clients -- you can find the implementation here:

Ha. I see quoting via email doesnt work properly

(via edit or follow up comment). We also have plenty of valid reasons
someone wants to post just a quote (especially on long threads). I can't
see much value in spending engineering time on this, personally.

This is the same as T4181, sort of, except that merged somewhere else and isn't the same as itself, if you will.

I'm pretty sure I sneezed earlier today and Herald added @eadler as a subscriber.

I would generally assume most people quote without text intentionally, more so than accidentally. At least anecdotally I quote things without comment and I don't recall doing it by accident. If it something with page loads, we could maybe take a look into that specifically.

Basically I think this occurs very rarely, is immediately recoverable (via edit or follow up comment). We also have plenty of valid reasons someone wants to post just a quote (especially on long threads). I can't see much value in spending engineering time on this, personally.

I consider this expected.

Maybe T8646 is a closer match? Dupe of one or the other in any case, I think.

merging into T7860, not quite identical, but I think both are same core issue? @epriestley can correct me if I'm wrong.

I believe D15612 introduced the bug, but unclear why newDialog isn't doing the right thing here overall. Easy to revert.

This bug report is missing complete steps to reproduce as well as version information.

I thought that might be an issue but on all the clients I tested on there's no special askpass or credential helper setup, so it should be prompting for the password.

Another workaround is directly editing the Phabricator database (e.g. with phpMyAdmin).

Yea, I definitely would not recommend that,
then again using http instead of https isn't great either (its sent in plaintext anyway, regardless if you include it in the url or not)

I can confirm putting the password in the URL works. Unfortunately we can't use that as a workaround within the company due to the security implications. Though I'm sure you weren't implying that we use it as one.

You should be able to delete the bad tasks with ./bin/worker cancel --id 117317.

We don't really want to take bugs on prototypes, especially ones that don't reproduce. No idea what steps I would need to take to get this error, we run Phortune fine on Phacility. Sorry.

Reopening, this is definitely different from T4181

I was playing with it and made a "Give me your money for free" Fund and now... I regret that...

Why are you filing bugs against a prototype? Are you using it?

T10772

Hey @eadler, thanks for looking into this. I feel this ticket is different from T4181. The former covers starting phd at boot, this ticket covers using process supervisors (like daemontools) which monitor processes on an ongoing basis.

BINGO! We have duplication. The updated steps in the description *will* recreate the issue.

http://admin.phacility.com/ -> New Instance -> Test Instance

@eadler, how do I do that? EDIT: Nevermind.

@CodeMouse92 consider duplicating on a phacility test instance.

@chad, I updated the reproduction instructions. I think the project having Subprojects already before adding the Milestone might be the mitigating factor. Let me know whether that reproduces. If not, I'll dig some more until we get this thing reproducing. I swear it's there!

Ah, yep, thanks.

(I'm just guessing it has something to do with this, because ops)

Logged-out users can't browse diffusion: ERR-INVALID-SESSION: Session key is not present.

This sort of works now. The 002 node is live, just not reachable yet. Some weird stuff I hit:

I'm probably going to break all repositories momentarily. If I do, I'll try to fix them.

Very minor technical note: we can't support this for all providers. The username + password, LDAP, and I think Persona (although see T10125) providers can't initiate a login flow with a redirect (since the user has to type stuff or do javascriptey things, not just navigate to a URI).

sure.

Should I file a separate task for the general feature request?

[text intensifies]

That feature exists, but it's currently only supported for the Phabricator provider. There's no technical reason we can't support it on other providers, it was just built very narrowly for a Phacility (SAAS) use case and it was simpler to keep it narrowly scoped:

Unsure if fits into this task or not but with only a single auth provider enabled for login it would be nice if it were transparent (and got automatically selected) rather than requiring the user to press a button.

Okay, I found the culprit in the apache configuration after debugging what happens in aphlict.

In T10775#169974, @clemvangelis wrote:

Sorry, I read the "Describing Root Problem" and I thought that explaining the main problem (not intuitive for users and lack of visibility for Assigned to and Authored By) was sufficient.
The problem is that users ( at least ours) want to find all essential information (and assigned to seems to be an essential information) in the same place by taking a quick look at the task such as for priority and status.