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

We haven't seen any other users find this confusing.

As a general note, Azure appears to have both SAML and OAuth flavors. D10297 / D10289 implement the OAuth flavors, and don't invoke the messy SAML problem. I'm not sure if these providers are equivalent or not.

Current state of the world is:

I think we can do this gradually by:

(This is likely an example of the issue.)

Oh, this was already fixed at HEAD (rP06aa3a0a1b). I pushed this server, should be good now.

Thanks, I'll look into this.

Do I have to create a new library when I create new files/classes in the extensions directory?
In my test the new linter worked, but only with single files...

Works well now. Thanks a lot @chad

Thanks a lot @chad .

@avivey: Thank you for clarification and references. I understand the rationale behind the changes, though, I still see that Phabricator still allows executing "trusted" binaries (whatever it means). Anyway, I could not find documentation on using extensions, so I'm not too sure about how to use tex2im, tex2png or similar programs in Phabricator's context. Perhaps, someone could point me to the relevant documentation and/or, better, share some examples for that approach.

I think I found one here:

Specifically that error message is from Phriction, not Maniphest. So I don't know how to reproduce it.

Please see Contributing Bug Reports. We need the full steps to reproduce the issue, or try to reproduce the issue here.

@ablekh: quite a lot has changed in this front since April - see T9408: Upgrading: `dot` (Graphviz) support removed, changes to `figlet` and `cowsay`; in particular, we no longer consider "executing arbitrary binaries" to be reasonable approach for this kind of situation.

After reading the Contributing Code guide, it seems that I would have quite a high barrier of entry, should I decide to contribute to the project on this feature (upstream; normal process). In regard to listed alternatives, local fork is likely not a good idea for me and developing an application is likely not relevant to this feature, as, if I understand correctly, it should be a part of general/core code (i.e, Remarkup blocks for wiki). Therefore, the only feasible option (for enabling this feature on local install) that I could think of (additional benefit: this would be general, enabling LaTeX for any Phabricator's Web output) is to move the LaTeX-to-HTML on-the-fly conversion outside of Phabricator's code, specifically, as part of Web server request processing. For example, it could be implemented as a Nginx module or directly - via Nginx config - pass the output through KaTeX's server-side processing ("Server side rendering: KaTeX produces the same output regardless of browser or environment, so you can pre-render expressions using Node.js and send them as plain HTML."). Does it make sense? Please let me know what you think about all this.

@chad: Got it, thank you for the reference!

See Planning.

New kid on the Phabricator block here. Firstly, I just wanted to say that I thoroughly impressed by Phabricator and thank all of contributors you for producing such a nice piece of software. After rather comprehensive evaluation of existing tools (mostly open source), I have chosen Phabricator as a platform of choice for my initiatives on improvement of research and software engineering processes a materials science / materials informatics research group, where I currently work (Georgia Tech).

Just wanted to clarify as I'm not entirely sure that I understand... So we currently have a puppet role named phabricator_worker which runs phd daemons. As a step in our puppet scripts, we basically run /usr/src/phabricator/bin/almanac register --device=worker.phabricator.example.com --private-key=/path/to/private.key.

In D14535#163975, @epriestley wrote:

This code looks good to me in a technical sense, we just don't want to take over maintaining it. Two minor suggestions:

• phutil_utf8_strtolower() has better behavior than strtolower() on some utf8 inputs.
• phutil_json_decode() has better behavior (throws a detailed exception) on invalid JSON than json_decode() (returns false).

Thanks for the review!

This code looks good to me in a technical sense, we just don't want to take over maintaining it. Two minor suggestions:

Fair enough. Thanks for your thoughtful reply.

Per T9827, I currently believe this would be used by only one install and don't want to bring it upstream without seeing much broader interest first.

We haven't seen other requests in this vein from other users, and are not aware of a more general interest in using JSON bindings to write linters. From your problem description, it sounds like you have a fairly unusual and specific need within your project. We haven't seen other projects report similar needs, and I think this is isn't a good candidate for bringing upstream: we don't want to upstream code which will only be used by one install, and I have no reason to believe that these bindings will see wider use.

Correct comments

@epriestley, the amended text should clarify my goals here.

This probably requires $types[] = PhabricatorTransactions::TYPE_EDGE; in PonderAnswerEditor->getTransactionTypes(). It would be vaguely nice to do this more automatically/consistently, but probably not worth pursuing some grander approach at this time. T9789 is probably on the horizon and represents a better opportunity.

This obscurity is currently intentional, for policy/security reasons. I don't want to leak anything sensitive into the relatively-accessible web UI.

See Contributing Feature Requests. Please describe the specific, concrete problem you're encountering.

Fixed by D14527.

To move forward, we should split this into two tasks:

These cases aren't closely related.

See Contributing Code.

In T9784#145136, @andrask wrote:

@joshuaspence what do you think about this issue?

@avivey I'm not sure how I can create a patch for that repo as it has no valid .arcconfig and I don't have the config for the whole Phabricator project. So I just created an svn diff that you can apply locally and then create the patch with your setup. I uploaded it here: https://secure.phabricator.com/F989152

@andrask: I couldn't quite understand what exactly is going on, and what is the expected behavior.

("No time specified" in Phame is a bit odd too, but I think that's been fixed already)

See Contributing Bug Reports. Mainly, contributing comments to an unrelated task will not likely get a bug verified or fixed.

Because the publish step isn't run command. The publishing step is actually 8 other "Run Build plan" steps; these in turn have run command, but there's about 10 run command steps (these build plans clone a repository, update the binary artifact in them, then commit and push).