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
toaster/master:213fef6e87cbf60d773e28d31653e3c626d4058e
Is this a specific page ? How can I view this ?
(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.
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.
(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.
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.
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.
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.
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.
merged to master http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?id=961f6226fa8019a7492ee40fdba18c5916065001