Pulp

It seems to me that ideally the /users/ URL would accept the GET and POST parameters for searching, and then we wouldn't need to have a /users/search/ URL at all. In fact, this is probably true for all of our URLs. Perhaps this is something we should consider for 3.0.0.

There are a lot of <stuff_here>/search/ urls in the Pulp API. The idea that GET and POST parameters should provide search is a good one, and should be applied to all search URLs, not just this one.

Regarding this defect, one possible backwards compatible fix would be to reorder these statements in urls.py. The problem with that is that search will break if the user makes a username called 'search'. I think not having one username that isn't allowed and can be documented is better than having search completely break if the user makes a user named 'search'.

Based on that I recommend we document this as a known limitation at a minimum. We could also put in some validation code at the API and/or CLI level.

On 03/16/2015 09:24 AM, bmbouter wrote:

There are a lot of <stuff_here>/search/ urls in the Pulp API. The idea
that GET and POST parameters should provide search is a good one, and
should be applied to all search URLs, not just this one.

Agreed, I hinted at this in my comment.

Regarding this defect, one possible backwards compatible fix would be to
reorder these statements in urls.py. The problem with that is that
search will break if the user makes a username called 'search'.

I believe it's worse than that - if we reorder the URLs, it will be
impossible to search regardless of whether a user named search exists,
as "search" will always match as a user ID, and then the View for
dealing with individual users will always be used.

rbarlow wrote:

Agreed, I hinted at this in my comment.

Indeed you did. I created #763 so that we could track that broader effort and set backwards incompatible = True.

I believe it's worse than that - if we reorder the URLs, it will be
impossible to search regardless of whether a user named search exists,
as "search" will always match as a user ID, and then the View for
dealing with individual users will always be used.

You're right it is worse then that. Is the fix for this issue to disallow 'search' as a user's login ID in the API? What about the CLI? Also how does the fix for this similar or different from a fix needed for #760?

On 03/16/2015 11:52 AM, bmbouter wrote:

You're right it is worse then that. Is the fix for this issue to
disallow 'search' as a user's login ID in the API? What about the CLI?
Also how does the fix for this similar or different from a fix needed
for #760 <https://pulp.plan.io/issues/760>?

I think the fix is either to change the URL structure (which requires
waiting until 3.0.0), or to disallow "search" as the user's login ID
until then. I don't feel strongly one way or the other, but I wanted to
at least document the issue via a ticket.

#760 is not really related to this. I did try to create a user named
"search" as an example there, but it turns out that no user of any name
can be created. I mentioned it here because I was unable to verify for
sure that it was true that a user named "search" can be created. After
reviewing some code, I do believe it's possible, but I wanted to just
try it to find out.

Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.