Would T5207 solve your base problem?

Closed by commit rPc07425c534e0.

I'm taking care of this issue.

I'm going to skip all the account binding junk and just sign the SAAS requests as a user instead of as a device. It's simpler and not much different in the end.

I need to reduce/alter the authentication strength of this a bit. D1040 originally required CLI access to associate a key with a device, so it was OK to give requests using a key to authenticate omnipotent access because association guaranteed direct database access.

Thanks @qgil

Yep, same failure mode I'm getting. There are reasonable workarounds, it's just a minor setback.

Chads-MacBook-Pro:~ chad$ ssh-keygen -y -f ~/.ssh/id_rsa > rsa.pub
Chads-MacBook-Pro:~ chad$ ssh-keygen -e -f rsa.pub -m pem
PEM_write_RSAPublicKey failed

I can work around it regardless, but you can check with this if you have Yosemite:

What about Yosemite?

Sooooo it looks like ssh-keygen -e -f ... -m ... is broken on Mavericks.

project.query does not emits the auxiliary dictionary, so there's no way of getting custom field value with the api :(

I've paved the way for this in T5833 and it's coming up shortly.

@austinstoker, you want to see this: T3179#81309

We want to migrate to phabricator from trac, but to get buy-in we need to migrate trac tickets and their custom fields to Maniphest tickets. As I understand we can either wait on this ticket, or delve into the code and try to resolve this. Is there any other option?

Thanks, that works. Our project also need a conduit call for creating a new credentialPHID. I looked through the conduit calls and don't see it. Am I missing the option? Or can it be added?

Great, thanks. Checking it out.

https://secure.phabricator.com/conduit/method/repository.create/ is the conduit call to create a new remote-tracking repository (There used to be a separate Repository "application", hence the name).

• T5873 discusses general treatment of edge relationships, like watchers.
• Flags can already be queried with flag.query. They're also personal to the viewer. We're unlikely to expose them by default in other application query methods.
• Description is a CustomField and covered by T5873.
• Color and icon are primary fields, straightforward to expose, and uncontentious (except possibly that the internal icon name is prefixed with "fa-" for "FontAwesome", which feels like somewhat of an implementation detail). I'd be happy to accept a diff to add them to both the parameters and output in advance of T5873.
• Policies are also primary fields and straightforward, but there's generally no way to query for policy information after you have them. You can recognize common policies (public/users) but can't decode a custom policy over the API right now. So probably this is an easy first have and then an involved second half.

Thanks for the quick clarification. I understand now.

Just to clarify, it's not for filtering tasks, but for filtering which projects are included in the IRC message. Thatt is, we'd like the format to be

(Ooops, I wasn't aware that this is upstream and not Wikimedia's Phabricator. Anyway, the comment is still relevant.)

Closed by commit rP6db25aa41c9d.

phriction.history and phriction.edit should probably wait on T5873 to make sure they end up looking like whatever all the other modern transaction-aware endpoints look like. And maybe phriction.create too. We could create phriction.query now fairly safely, although some discussion in T5873.

Context from IRC:

As we've already discussed that task is far from it's implementation. Until then current API call works, why mark it as deprecated and prevent anybody willing to add comment to commit from seeing that call on /conduit/ page. I guess deprecation status only affects visibility of that API call, but it still continues to work.

See T5873.

I've found that there is API call for creating comments for commits called diffusion.createcomment, but it's marked as deprecated. Any idea why? It looks like working one to me.

No. See: https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#setting-expectations

Can this be implemented this year? Would be great present for Christmas.

This is blocked by T5873, which is very complex.

@voldern , have you implemented that in your local fork or found another way how to achieve this?

Closed by commit rPc51489f138cb.

Created pull request: https://github.com/phacility/phabricator/pull/734

Closed by commit rP03ddb4a0fcec.

Closed by commit rP923f625130cd.

A couple of other thoughts on this:

Support Impact A lot of application functionality is not accessible over Conduit (or is accessible only in a confusing or broken way).
High Support Impact Removing methods gets harder over time, and this broadly limits our ability to expand many Conduit capabilities.

Support Impact Conduit can not represent some messages (e.g., diffs with non-utf8 text), which has no workaround, and is very difficult to use relative to other APIs.
High Support Impact Waiting on this makes it harder to deprecate the old stuff (since it will be more widely deployed) and may mean we need to convert or modernize more methods.

I poked at this for about 30 seconds but it's not a completely trivial fix.

This bit is fixed to get the affected user moving, will want to check the rest of the API later

Looks like this is working now (sorry if these updates are spamming anyone).

https://github.com/bloomberg/phabricator-tools/issues/9

We should support T5603 before allowing projects to be left via Conduit, because at least one major install assumes bots can't leave projects (which is currently true).