Bug 468801 - bodhi-client with "--mine" fails to return any results
Summary: bodhi-client with "--mine" fails to return any results
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: bodhi
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Luke Macken
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-28 04:50 UTC by Chris Weyl
Modified: 2016-09-20 02:39 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-20 19:23:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch implementing Option #1 & serverside #2 (1.23 KB, patch)
2008-11-20 01:20 UTC, Toshio Ernie Kuratomi
no flags Details | Diff

Description Chris Weyl 2008-10-28 04:50:06 UTC
Shouldn't:

[cweyl@athena bin]$ bodhi --status testing -m
0 updates found

Instead return a list of the updates I currently have in testing?

This is on an up-to-date F-9 system.

Comment 1 Toshio Ernie Kuratomi 2008-11-20 00:17:30 UTC
We've identified the basic issue here: bodhi client is requesting the information from an API method that returns information whether you are logged in or not.  when logged in, it returns the list of packages.  When not logged in it returns an empty list.

There is another server side method that should do what we want but we need to write code to access it in python-fedora and bodhi-client has to be ported to use it instead of the current method.

Comment 2 Toshio Ernie Kuratomi 2008-11-20 01:10:33 UTC
ugh.  So this isn't going to be as easy as I thought.  bodhi-client is currently using the fedora.client.BodhiClient.query() method.  This calls controllers.list() on the server which returns a list of updates filtered by criteria that's provided to it.  This is the method that allows unauthenticated access and therefore is causing us to fail.

There's also controllers.mine() on the server that returns a list of all the updates that the user owns. This requires an identity so it would prompt for username and password if the user was not logged in and then give us the correct values.  Unfortunately it: 1) Does not take other arguments to filter the return value and 2) Returns the list of updates as a preformatted text string so client-side filtering would have to jump through hoops.  :-(

Here's the options that I'd propose:

1) On the server in the list() method if the "mine" option is given to list() and identity.anonymous == True: response = 401; return dict()  This will raise an AuthError on the clientside so that the user will be asked for a password and then the server will be queried with a proper identity.

2) On the server, in the mine() method, do not turn the list of updates into a text string.  That way the client code (in fedora.client.BodhiClient) can filter according to the values passed into it.  The client code will also have to be ported to use the new mine() method in the client API.

3) On the server, in the mine() method, take optional keyword params that do the filtering serverside.  Then port the client code tothe new mine() method in the client API.

I think that #1 is the best choice for fixing this problem.  If we're going to keep the mine() method serverside, I'd implement the server portion of #2 as well as returning preformatted text from the server is just wrong ;-)

Comment 3 Toshio Ernie Kuratomi 2008-11-20 01:20:31 UTC
Created attachment 324127 [details]
Patch implementing Option #1 & serverside #2

Untested patch to implement #1 and serverside #2.  If bodhi is running in the staging environment, this would be good to test there.  We'll have to wait for the freeze to be over to make this change.   Also note that 401 response code doesn't trigger AuthError until python-fedora-0.3.8 which I'll be releasing as soon as we get the other bodhi bug fix committed.

Comment 4 Bug Zapper 2009-06-10 03:06:14 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Luke Macken 2009-07-08 02:48:40 UTC
Thanks for the patch, Toshio.  I applied it to git, and will push out a new version to staging shortly.

Comment 6 Luke Macken 2009-07-20 19:23:35 UTC
This fix is now live in production.  Please re-open this ticket if you are still experiencing this issue.  Thanks!


Note You need to log in before you can comment on or make changes to this bug.