[Freevo-tracker] [ freevo-Bugs-2954480 ] Favorites list in webserver mis-sorted after edit (patch)

[SourceForge.net <no...@so...>]

Bugs item #2954480, was opened at 2010-02-18 17:04
Message generated for change (Comment added) made by jroldroyd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=446895&aid=2954480&group_id=46652

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: J.R. Oldroyd (jroldroyd)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Favorites list in webserver mis-sorted after edit (patch)

Initial Comment:
If you view the Favorites list using the webserver interface, then click an Edit link to edit any favorite - other than the bottom one - and then save that favorite, you are put back to the Favorites list.  However now, the list is no longer properly sorted -- the just edited favorite is at the bottom rather than in its correct place.

This is a problem because the Higher and Lower buttons are now not correct on the juet-edited item and also the item that is really the bottom of the list.  The item that is really the bottom in the list (now displayed as second from the bottom) now shows both Higher and Lower buttons.  Clicking its Lower button changes its index to n+1 which should not be possible since it is already, in fact, the lowest in the list.  This can result in gaps in the favorites list index numbers.

Since the indices of the favorites do appear to be correct just after the initial edit, the problem is merely not sorting the edited item back into the list properly after the edit.  In fact, since its index doesn't change, editing a favorite shouldn't have to remove and re-add it from the favorites list.


----------------------------------------------------------------------

>Comment By: J.R. Oldroyd (jroldroyd)
Date: 2010-02-19 11:10

Message:
OK, I traced down the favorites list code in record_types.py and found
recordserver's addFavorite and addEditedFavorite, the former of which
changes the item's priority to be at the end, and the latter of which
doesn't.  But it is the latter method that is properly in use here.

It turns out, though, that this problem is due to the sortByPriority code
in htdocs/favorites.rpy not working as intended.  The code looks OK, but in
fact the priority comparisons are being done as string comparisons rather
than integer comparisons.

The attached patch fixes this.


----------------------------------------------------------------------

Comment By: J.R. Oldroyd (jroldroyd)
Date: 2010-02-18 18:09

Message:
I am looking at the code... I see the sorting code in
www/htdocs/favorites.rpy that sorts based on priority, so I am assuming
that when editing an item, the priority is somehow being changed.

Looking at the HTML page sent to the browser, the correct priority is
shown in the hidden "priority" field.  So when the form is submitted, and
the code in favorites.rpy is executed, performing:
        elif action == 'edit':
            self.recordclient().removeFavoriteNow(oldname)
            self.recordclient().addEditedFavoriteNow(name, title, chan,
dow, mod, priority, allowDuplicates, onlyNew)
this must lose the priority value, moving the re-added fave to the end of
the faves list.

I followed that into recordserver.py and also scheduled_recordings.py but
don't see where the favorites list is maintained in the schedule.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=446895&aid=2954480&group_id=46652