I would say that would be an intriguing feature request.

@chad thanks for the clarification, I indeed mangled these authentication tokens with the Tokens application.

If so, I'd generally claim this is an issue with the client you're using: I think clients generally should not do parameter validation themselves. They will always be less able to do validation than the server is, even though server validation is not especially sophisticated right now. If/when we have a formal Python API client, it is very unlikely to perform client validation. Does client validation provide any advantage?

2 cents:

This will be available in a future repository.search method, via T7715. See here for some discussion:

Reading Custom Fields is now supported in new *.search endpoints (paste.search, maniphest.search, owners.search).

The maniphest.search endpoint at HEAD now has full-power ordering controls.

I think this stuff is basically in good shape, I'll follow up on the Phame stuff in T9897 and the arc stuff in T7715.

This feels like we're in much better shape, now. We can refine it if more stuff comes up once the new endpoints start to land.

I also put the DAO itself back to make storage adjust happy, so that should get nuked when the data is nuked.

gotta up ur game

See T9908#148194.

Yes, but I have some hesitance around adding "search for a string in another string" fields without building better infrastructure first. There's some discussion in D14411#161139.

Ok, got it. Do you think it's reasonable to search using a package name?

We don't check that the path actually exists -- you might be searching for a deleted path that used to exist, or the repository might have a million branches and it only exists on one, and you might have a thousand different repositories too.

You are right for the cases you described. But the case I mentinoed is that /src/infrastructure/PhabricatorEditor.php doesn't exist in both Arcanist and libutil.

That result looks correct to me -- if a package includes "/", that means it includes everything under "/" too. So if you search for /x/y/z.cpp, any package that owns /, /x/, /x/y/ or /x/y/z.cpp will be returned, since any package owning a parent also owns the path itself.

In T9964#148566, @epriestley wrote:

I can't reproduce that. Here's a search using "Path", which seems to work correctly:

Can you give me more details about how to reproduce the issue you're seeing?

I can't reproduce that. Here's a search using "Path", which seems to work correctly:

You might already know, but I noticed that the owners search is broken if I use "path" instead of "Repositories" to query. Also it would be great if we can use the package name to search.

Broad update here after T9132:

Alright, I will and I'll let you know, thanks

The same way you call it against your install.

No, I am asking you how can I make use of your install of Phabricator to test my script

Are you asking me how to write a script?

Sorry, and how can I do that?

You said you have having issues with your install of Phabricator. Why not try to test your script against our install of Phabricator.

What's not clear?

What you mean?

Can you reproduce the issue against this install?