5921 2014-03-06 16:29:58 +0000 Task outcomes are sorted by database value, instead of alphabetically 2014-07-31 16:42:16 +0000 1 1 7 Build System, Metadata & Runtime Toaster toaster 1.6.1 All Multiple RESOLVED FIXED Medium normal 1.6.1 1 belen.barros.pena david.reyna alexandru.damian belen.barros.pena bluelightning cristiana.voicu david.reyna jessica.zhang --- --- No (bug/feature does not impact docs) oldest_to_newest 40929 0 belen.barros.pena 2014-03-06 16:29:58 +0000 The outcomes seem to be sorted by database value, which means that you see the outcomes in this order: Succeeded Covered Cached Prebuilt Failed Empty Of course, the above makes no sense when you are looking at the strings in the Toaster interface. They should be sorted in alphabetical order: Cached Covered Empty Failed Prebuilt Succeeded 40930 1 belen.barros.pena 2014-03-06 16:31:34 +0000 toaster/master:213fef6e87cbf60d773e28d31653e3c626d4058e 41089 2 alexandru.damian 2014-03-11 15:52:50 +0000 Is this a specific page ? How can I view this ? 41093 3 belen.barros.pena 2014-03-11 16:07:11 +0000 (In reply to comment #2) > Is this a specific page ? How can I view this ? Sorry: I wasn't very clear. In the tasks table, sort by the Outcome column. 41337 4 alexandru.damian 2014-03-17 18:39:46 +0000 Fixing this would mean to break compatibility with the existing data builds. The reason is that the system orders the outcomes based on the numeric values assigned to different tags. If we change the values, prior data will not make sense anymore. Please advise. 41374 5 belen.barros.pena 2014-03-18 14:18:36 +0000 (In reply to comment #4) > Fixing this would mean to break compatibility with the existing data builds. > > The reason is that the system orders the outcomes based on the numeric > values assigned to different tags. If we change the values, prior data will > not make sense anymore. This is what I guessed, but the problem is, as it behaves now it makes no sense, and the longer we wait to solve this problem the worse the impact of breaking the compatibility with previous data will get. We probably have no users right now outside of the people contributing, so now is the right time to make a change like this. I've cc'ed Paul and David: it would be good to see what you guys think. Thanks! > > Please advise. 41376 6 bluelightning 2014-03-18 14:32:23 +0000 Hacking the data values to influence sorting seems like the wrong solution to me. If the values do not sort correctly then the answer is to add something else to the database so you can influence the sort order. 41891 7 belen.barros.pena 2014-03-28 10:25:47 +0000 We have the same problem with the "Cache attempt" column, by the way, where Failed will appear after File not in cache in the A to Z sorting. 41928 8 david.reyna 2014-03-31 05:54:14 +0000 The only general solution I can think of without polluting the database, is to (a) hide the 'real' ordeby value for the normal query processing (a) right before the pagination (since that is when the table is instantiated anyway), dynamically create a new virtual column with the text string values of the numerical field(s) and explicitly "orderby" this synthetic column. That way we get a custom sort, and not much overhead. 42631 9 david.reyna 2014-04-14 02:52:48 +0000 I have completed 5921 for both the "Outcome" and the "Cache attempt" columns. This used the technique of a python class ‘property’ as a ‘field’ together with an explicit python sort (instead of ‘sortby’), as described in this web site. This general method can be used for any transient or synthesized value of a class instance. http://blog.mattwoodward.com/2013/02/generating-and-sorting-on-transient.html This patch handles both forward and reverse sorts, plus it handles the ‘-1’ base for the outcome text table and the convention of using a blank string for sstate_cache values of SSTATE_NA. 44893 10 belen.barros.pena 2014-07-31 16:42:16 +0000 merged to master http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?id=961f6226fa8019a7492ee40fdba18c5916065001