(T11357 is a companion issue for Files.)

Excellent! Thanks for this so very detailed answer. I will try the way of the phid.lookup to work this issue around in the while.

Thanks for the extra context!

reopening due to additional details

Let me add some more detailed and specific information. We wrote (and released) https://github.com/Gandi/hubot-phabs

Please read Contributing Feature Requests carefully before filing feature requests. In particular, we need you to describe a root problem (see Describing Root Problems).

I use maniphest.query (which is marked stable).

They're available in the "points" field of maniphest.search.

maniphest.search method contains that under points:

calendar.event.search is still pretty useless/bare-bones (you don't get very much information back), but we can expand that as use cases arise. We don't have specific needs for this yet.

(Only unique queries are saved, so this should be a small amount of data in most cases, but the Phacility setup tends to mean we issue a lot of unique queries.)

A possible alternate approach would be to attachRepository() as a side-effect of validating the transaction instead of while applying the transaction, but then if something throws between the "validate" and "apply" steps we could end up with a URI in a weird state. That probably never actually matters, but feels a little more awkward to me than ordering the transactions.

ok, that makes sense.

It's impossible to create a URI without a repository transaction (it doesn't make sense, since URI objects can't just exist), and we already give you an appropriate error when you try:

That kinda feels like a band-aid... Shouldn't we be able to not-crash for any input? Like if a user will only provide a uri transaction?

My initial thought is that we should just reorder these transactions. We should use a stable sort, but that's relatively easy now that we have msortv(). There are probably a handful of other transactions with similar properties in other object types.

if it helps anyone, the workaround "fix" is to place the following code in the file "src/applications/conduit/parametertype/ConduitBoolParameterType.php "

Turns out that CustomFields sort of just work properly with EditEngine out of the box, so D16226 provides a technically-functional dashboard.panel.edit, which allows you to edit text panels like this, for example:

We probably need to do almost all of this work before adding new panel types anyway, since building a new panel type on top of CustomFields would make moving everything from CustomFields to EditEngine harder.

FWIW we'd be perfectly fine with the following:

• allow editing phriction documents via Conduit
• create a panel which shows the contents of a specific phriction page

The actual panel transactions that we need to update for this aren't too bad. The board transactions are a little more involved, but we can skip them.

No, no I can't. I can't make a Phriction Panel.

I might be able make a Phriction Panel

FWIW, the answer to both of your questions before you edited it was yes :p

ignore me - wrong install

Thanks for such a quick response!

8bb124c37de3dfa29fcd23d4be53a5696b705c81 seems most likely root cause. I can trace it down to ssh coming in from getProtocol which should be blank and give you an error.

I'm not sure what to do with your link. Here's what I can reproduce:

It should be erroring out that you're not putting in a valid URI.

Stock arcanist:

Bug Reports require reproduction steps.

Appears resolved and accounted for.

Sounds good. I'll call this done for now, let us know if you run into issues.

I was able to filter by status using the queryKey, which is much more valuable than displaying the status. So omitting status from the response is ok by me considering the level of effort required to refactor the numeric constants. Thanks again, much appreciated!

I return the other fields, but don't currently return "status" because I'd have to return an internal numeric constant. So we may need to fix that more thoroughly before you can move forward.

Awesome, thanks for the quick turnaround. This looks good to me. Currently I'm using revision ID, title, status, and authorPHID in the response for display purposes. I'll try your recommendation for 'open' revisions using the queryKey to handle the status.

Actually, this is slightly more involved because you want to select open revisions.

You essentially only need the revision IDs in the response, right?

Which instructions did you follow that included a key called value_add? These instructions were wrong and should be updated.

• https://secure.phabricator.com/conduit/method/maniphest.edit/
  • insert in the field

[       {         "type": "title",         "value": "TEST_3"       },     {       "type": "description",       "value": "Test 3?"     },     {       "type": "owner",       "value": "PHID-USER-y7djwtvdkrc7sd2dymn6"     },     {       "type": "status",       "value": "open"     },     {       "type": "priority",       "value": "0"     },     {       "type": "projects.add",       "value_add": "PHID-PROJ-nitxwme6cvo45mcfry4s"      }   ]

I can't reproduce this; I've used conduit to add the "Conduit" project to this task:

The trouble is that that could sometimes give the wrong answer, because querying the Git URI is not the only way that arc itself finds the repository; for example, the repository callsign can be hardcoded into .arcconfig.

I think the only way right now is to get the remote uri, call repository.query with it, and parse that.
It might make sense to just teach arc which to output it's things in json.