Roundup Tracker - Issues

Message4997

Author r.david.murray
Recipients r.david.murray
Date 2014-03-06.19:52:04
Message-id <1394135526.74.0.958129763004.issue2550831@psf.upfronthosting.co.za>
In-reply-to
The attached patch makes the classic template query.edit page work.  It
addresses several different problems, and makes one related content change:

  1) Previously, once a user included a public query that query would
show up with a yes/no dropdown in the private column.  When the form was
submitted, roundup would try to set the private_for property on that
query the user didn't own, and the result was a permission error on 'query'.

  2) The 'private' dropdown always showed 'yes', no matter what the
actual value of private_for was.  (See issue 2550830).

  3) Pressing the 'delete' button resulted in an invalid request error,
since it was doing a GET and roundup is requiring a POST.

The fix also comes in several parts:

  1) Restructure the loops so that we look at all queries and pick out
only the ones the user owns for the first section, and the ones they
don't for the second.

  2) Fix the private yes/no dropdown by using 'not query.private_for'

  3) Change the delete button javascript to use POST.

  4) Remove the retired queries section.  As written it would show only
retired queries that were included in the user's query list.  It seems
to me that when a user deletes a query, they want it gone, so we should
not show it, just as we don't show retired records in other interface
screens.  If it is desirable to keep it, it should be moved to the
bottom and fixed to show all retired queries created by the user.

Note that there are several things in this patch that perhaps could be
done better by someone with more knowledge of roundup internals.  For
example, I could not get filter to work, which is why I look at all
queries and use a condition to only include some of them.  (The fact
that filter arguments of private_for: uid and private_for: None returned
all queries may or may not be related to the LinkHTMLProperty issue). 
If we do need to iterate the whole list there may be a better way to get
it than calling filter with no arguments, I don't know.  Finally, I
don't know if there is a way to refer to query.is_retired without going
through the path expression.
History
Date User Action Args
2014-03-06 19:52:06r.david.murraysetrecipients: + r.david.murray
2014-03-06 19:52:06r.david.murraysetmessageid: <1394135526.74.0.958129763004.issue2550831@psf.upfronthosting.co.za>
2014-03-06 19:52:06r.david.murraylinkissue2550831 messages
2014-03-06 19:52:06r.david.murraycreate