Looks like you are already aware of T8404, and this is a dup; Why did you submit another ticket?

Thanks so much.

Right. This was a feature request to have "ctrl+enter" (or cmd enter on osx) to work in all fields (in addition to enter in the fields where it makes sense), so that there's 1 key that always works to submit the current form.

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

Also for posterity, I discovered that I was able to take a task in which this link works as expected and break it simply by assigning it to myself. Removing the assignment to myself and forcing uncached page refresh did not unbreak the task (so now I seem to have another one in permanent workaround state). This is still not a very detailed reproduction scenario, but maybe if someone hits this, it will help hone in on the problem.

Alright, I think you should get different behavior at HEAD for both of those issues. No promises it will be correct, but let me know if those changes just uncover a second series of errors.

I also don't think it's wholly unreasonable to change the prefix rule to be stricter, but I think getting rid of the username@ stuff will moot it in all realistic cases. We could look at the rules after the next Conpherence update if we want to reintroduce the username@ rule.

Ah, that makes perfect sense. Thanks!

The mail looks like this:

How is it even getting mail addressed to, say, jonah@company.com if the system's mail is handled by Postfix and the aliases file only pipes phabricator@ to the Phabricator script?

Phabricator strips the prefix if it is present, but does not require it to be present, and attempts to route all mail for the domain it is given.

The way I thought it was supposed to work is that instead of addresses like D832@company.com, we'd use phabricator+D832@company.com and thus only have to reserve the phabricator@ address. Is that not viable?

I intend to remove username@domain.com causing interactions with Conpherence.

(Allowing Phabricator to receive mail at domain.com and also having real mailing lists and users at that domain is still a bad idea, because the two namespaces will collide, but few normal addresses resemble Phabricator object addresses so the practical badness is low -- almost no one has D832@mycompany.com as a real address.)

Which feature do you mean to remove?

The second (or third or fourth or whatever, depending on how we're counting) Conpherence issue I'm unsure about.

Great, thanks. I've been putting off opening a task about the various errors we get when trying to comment on tasks by email when they involve aliases and replying all, but I will do it next time.

"Array to string conversion" is a bug. Once that's fixed (by D14996), the user will start getting some kind of error email instead (the bad conversion was occurring while trying to compose an email to notify the user about an error). That error email may describe an upstream bug, or may describe user error. The stack trace doesn't have enough information for me to guess.

In the sense that I'm doing something wrong, or that it's a real bug but probably easy to fix?

The first error is happening while we're trying to generate an error mail, so this maybe quite a deep rabbit hole, but that first surface error looks straightforward.

I (user B) also got this error message:

I've marked D14995 as fixing this, but only commits parsed after the upgrade will have author dates shown.

Sorry we don't have more ideas for you.

For posterity, opening the "Edit Blocking Tasks" link in a new tab did work, and that's good enough for me.

There's currently no way to create those relationships via the API (see T5873; see also T10034).

The server side of this is a fairly boring RHEL 7 setup. It's doing nothing other than running Phabricator, and so it has no other server side modules installed in Apache other than the minimums required to run Phabricator. My browser is also pretty boring; nothing extra added except for Postman. I've set up some creative and full featured web stacks in my day, and this isn't one of them.

Ok, thought I missed some magic strings or a trace posted elsewhere.

Got it - those are fair points. We'll maintain a fork of Phabricator with this Asana integration, so please ping me if you'd like to reference it at some point in the future!

Oh, sorry, I was agreeing with you ("points to something environmental").

Oh, where does the trace say that?

Yes, the trace implies your entire environment is unsound. RocketLoader (T9716), mod_pagespeed (T4854) and other technologies which rewrite page content and Javascript can sometimes cause this, if you have any of that stuff enabled.

I don't know offhand what debugging information you can collect. No one else is reporting it and we can't reproduce it. This generally points to something environmental on your server (not Phabricator itself).

I don't know what about these tasks is unusual. The tasks I noticed this on were created two months ago and only today did I want to connect them together. From a user standpoint all I'm doing is opening the tasks and clicking on the edit blocking tasks link, and then I see only this in the javascript console:

I've also noticed this does not happen on every task (though it is certainly more than a few)

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

For me, the big advantage to using IAM roles is that the credentials rotate automatically, every hour.

This sounds awesome.

In T4705#61706, @ott-consult wrote:

Yes, this would really be a useful feature. Especially as CentOS still uses a 5.3 version of sshd and on production machines, I would like to keep the "normal" sshd on the standard port. Using a different ssh port for all other tools require a lot of extra config.