...and here are foreseeable issues with this mess occurring in the wild:

Broadly, I want to avoid implementing things that don't have good technical justifications.

I've done some more digging as well and it appears that this issue arose in the Go library already: https://github.com/golang/oauth2/issues/111

OK I imported some real great events:

Is "GitHub-specific OAuth" just normal OAuth with client_id / client_secret as parameters instead of in an "Authorization" header? The GitHub OAuth documentation seems to suggest passing these as parameters, too.

It seems like section 2.3.1 is poorly worded. They talk about a "client password" but the example request only includes client_secret as a POST variable. In the case of the Golang OAuth2 module (which Concourse uses), it sets the basic auth username to the client ID and the password to the client secret (https://github.com/golang/oauth2/blob/master/internal/token.go#L164).

I think the textarea predates using JS magic to make "copy" work. I think we could probably remove the "disable highlighting" mode now; I can't really imagine any legitimate reason to intentionally disable it in modern code, except maybe not realizing that "copy" will work correctly via magic.

I don't think we have a "client password" in this case -- I believe that refers to a mode that no one uses for anything (well, maybe a mode that Concourse uses, I guess), where the flow is actually handling normal user passwords?

I understand the situation. I will have a look myself.
Thanks for your answers!

Essentially, if there is a way to accomplish something in Phabricator, but it's not an install's ideal solution, we're not likely to add a second means of solving the same issue unless it meaningfully solves something new. We have 2 developers and thousands of tasks competing for upstream resources - so prioritization is difficult for tasks like this.

Then I'd recommend forking Phabricator to provide the functionality you seek.

We just want to connect 2 tasks, not to create one more task. If we add more tasks then the Task Graph get more complex.

In this case we have a new task for nothing

I don't know what you'd call this type of relationship

there are 2 tasks related to the same problem, but different isses

I think you meant to comment on my answer, not add a new one.

Protocol for URI "svn+ssh://..." MUST be "svn+ssh".

what

Please see and follow Contributing Feature Requests for what information is required in a feature request. Specifically we only take requests that state root problems, not just that a feature is desired.

That's too bad. I've done some testing and realized that the repositories that are exhibiting this behavior are non-bare, and one older repository that is bare is fully up-to-date in Diffusion's UI. (All are git repositories.)

@cspeckmim - Thanks for your answer! I will ask on the forum.

@remusvrm - Your question is probably best asked on Conpherence, IRC, or in the Ponder Q&A application. A Maniphest Task is meant to be representative of work to do and not a question.

?

+1 - quickly adding several tasks to a given column does currently feel quite tedious

I believe that using phid.query should be helpful.

I'm facing the exact same problem.

Phortune is prototype application, which means "The upstream does not offer support for these applications".

@rfreebern Nope, no clue how to debug it. We just don't use Diffusion any more and instead use the Bitbucket page, whose UI we anyway prefer to see commits and browse the code :/

@adityar7 Were you ever able to resolve this? I'm seeing the same behavior on my installation, which we recently transplanted to a new server and converted its ancient file://-based repositories to hosted. My suspicion is that there's something not quite right with user permissions on the system, but /var/tmp/phd/log/daemons.log doesn't have anything useful.

Actually probably moot if we can just provide a link to the new print view.

We can, but all styles need to be inline. DifferentialInlineCommentMailView is an example of an arbitrary-HTML-generating rendering class used in mail.

Calendar is a prototype application, and we don't accept bug reports against prototypes. See User Guide: Prototype Applications and Contributing Bug Reports.

See Contributing Feature Requests for a detailed breakdown of what a feature request needs to have before we'll accept it.

I'm building out a PhortuneReceiptView for the web, which I think we can also send as the HTML version in mail? Not sure if we can call custom HTML rendering in mail.

I'm going to merge this into T10510, which discusses improving Harbormaster error behavior.

Yes, you are correct, I want to wildcard the repository names. Thanks for your alternative fixes. The low priority is not a problem.

@pingpongboss, in T11787 it looks like you actually want to wildcard the repository names, not the paths?

I'm just going to "fix" this by just preventing you from hiding/locking/defaulting these fields, since it doesn't seem useful to create a "New Event on January 3, 2013" sort of form anyway.

No easy way, but we'll keep a lookout for how common this request is and roll with it if needed.

D16752 was approximately the same thing but I think this is a little complicated -- both in general, and for recurring events. I'm also not really sure this should use the trigger system at all.

I don't suppose there is any easy way to add this to a users preference settings? I often compose complex stuff in conpherence and am continually sending incomplete messages to the chat...