Page MenuHomePhabricator

Move Pholio to EditEngine and modern APIs
Open, WishlistPublic


My company is using phabricator for among other things mocks (using pholio).

To simplify the workload and automate lots of things in our workflow we have written some tools using the conduit API to handle maniphest tasks, pastes, etc. Unfortunatly we are not able to extend those tools with pholio.

The main requirements for our tools would be to be able to get informations from the mocks: titles, description, and the ability to close a mock

At the very least being able to get information from existing pholio mocks modeled over the maniphest or the differential conduit API:

Event Timeline

epriestley added a subscriber: epriestley.

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

Let me add some more detailed and specific information. We wrote (and released)

It's very convenient to have, on our irc channel, a bot giving meta-information on our Phabricator objects when they are cited (by id or by url). But it means we are to be able to retrieve object information by type+id rather than by PHID. The Conduit methods, and are the ones we use.

What @bapt talks about is that we also work a lot with Pholio and would love to have a way to get mocks information by id by the way of a new method. Plus, if we can have a mock.edit method, that would also open nice perspective for our hubot plugin.

reopening due to additional details

Thanks for the extra context!

You can use phid.lookup to get some information (name, monogram, URI, PHID, status) about monograms, including Pholio mock Mxxx monograms, which you can build from IDs or URIs. For example, on this install:

phid.lookup query
  "names": ["M1"]
phid.lookup result
  "M1": {
    "phid": "PHID-MOCK-6g6p65ez5ctxudji5twy",
    "uri": "",
    "typeName": "Pholio Mock",
    "type": "MOCK",
    "name": "M1",
    "fullName": "M1: Test Mock",
    "status": "open"

It looks like this might be good enough to solve the immediate problem today. (This kind of thing is why we ask users to describe what problem they're trying to solve -- there's no way I could have guessed that a possible solution already exists from the original description.)

Where they exist, you should prefer the newer *.search and *.edit ("generation 3") methods over *.info / *.close ("generation 1") or *.query / *.update ("generation 2") methods. The third-generation methods are more powerful, more consistent, and have a brighter future. It looks like you're already using some *.edit endpoints -- Blog Post: Reading and Writing Paths in Owners has an overview of both endpoint types.

Not all applications have third-generation API methods yet, including Files and Pholio. They'll get support at some point, but probably not until we're doing other adjacent work there. Technically, providing would be easy today since the SearchEngine is already modern, but it looks like phid.lookup might be a more general-purpose tool in this case anyway. Providing pholio.edit is more involved, as Pholio hasn't updated to EditEngine or ModularTransactions yet.

I expect us to bring first-class bot integrations to the upstream eventually, but this is probably two iterations out on Conpherence and almost entirely the stuff of myths today.

I'll realign this task around modernizing Pholio, but this is a significant amount of work (1-2 days?) and we don't currently have any adjacent work planned, so I don't expect to get to it any time soon.

epriestley renamed this task from Add a conduit API for pholio to Move Pholio to EditEngine and modern APIs.Jul 21 2016, 11:05 AM
epriestley added a project: EditEngine.
epriestley moved this task from Backlog to v2 on the Pholio board.

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.

Adn it's clear that working with *.edit is much better for an api consumer, because we can bundle various transactions in one go.

eadler added a project: Restricted Project.Aug 7 2016, 7:23 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Aug 9 2016, 5:07 PM

@amckinley, for general context on where I'm headed here:

I want to get rid of applyInitialEffects() to clear the way for D19897 in the MFA stuff.

applyInitialEffects() is currently used to do a giant mess of object and storage transformations when you add or replace images on a mock.

I'm generally going to try to make it work more like this:

  • Images are more-standalone objects, and have some properties like "name", "description", and "file", that will eventually get transactions.
  • Generally, Images become more like Diffs in Differential. Images do not need to be attached to a Mock.
  • When you add or replace images on a mock, we first create standalone Image objects (which aren't attached to a mock), then apply a transaction to the Mock which attaches them.
  • The "attach to a Mock" transaction will mostly just use imagePHIDs, not a big horrible mess of different weird objects.
  • It will be possible to end up with Images not attached to anything (just like you can have Diffs not attached to anything) but that's totally fine.
  • In the future, pholio.mock.edit and pholio.image.edit will be separate things, and you'd update an image by doing pholio.image.edit first, then updating the mock.
  • This series of changes won't get us all the way there, but should mostly make the future brighter and get us some of the way there.

Not completely sure how far I'll get -- and I may give up and do something else to make D19897 work -- but we'll see.

epriestley triaged this task as Wishlist priority.Dec 20 2018, 7:48 PM