Item8302: Init Sorting in TablePlugin is broken if no header row.

Try any of the date sorting in TablePlugin#Examples and notice how they are incorrect.

-- AndrewJones - 07 Oct 2009

Also on trunk.

-- AndrewJones - 07 Oct 2009

On my SVN install, I had to roll back to revision 3524 to get the date sorting in the second example working. The checkin that broke it was made in Item1214 back in April.

Even back then, the first example (multiple headings) doesn't correctly sort by dates.

It looks like a fresh approach is needed to fix this.

-- AndrewJones - 07 Oct 2009

hmm plot thickens... It works fine when sorting up, but not down.

I have some unit tests that describe the problem (in 1.0.x), which I will check in, but I can't work out the problem with the code.

I will update this report if I find anything, but any help would be appreciated :-).

-- AndrewJones - 07 Oct 2009

I think your conclusion is not correct. TP sorts dates fine both up and down. I think it is the date format with dashes which is not supported so the sorting happens alphabetically. The test cases for this must be constructed so they only pass if the plugin see the format as dates and not as normal strings. Or numbers.

Example in bug report would have been nice.

-- KennethLavrsen - 08 Oct 2009

Sort by clicking header works both directions. It is initdirection up that does not work with dates.

D	10 Oct 2009		30 Nov 2009
H	11 Jan 2008	11 Jan 2008
G	12 Dec 2007	12 Dec 2007
F	17 Oct 2007	13 Dec 2007
E	12 Oct 2007		12 Oct 2007
C	10 Oct 2007		10 Oct 2007
B	26 Sep 2007		26 Sep 2007
A	12 Sep 2007		12 Sep 2007

A	12 Sep 2007		12 Sep 2007
B	26 Sep 2007		26 Sep 2007
C	10 Oct 2007		10 Oct 2007
E	12 Oct 2007		12 Oct 2007
F	17 Oct 2007	13 Dec 2007
G	12 Dec 2007	12 Dec 2007
H	11 Jan 2008	11 Jan 2008
D	10 Oct 2009		30 Nov 2009

-- KennethLavrsen - 08 Oct 2009

It is not just initdirection . If I click the following table once, it sorts them incorrectly. In fact, it does not seem to sort them at all. This is without using any %<nop>TABLE%:

When
1-Jan-2004
1-Jan-2003
2-Jan-2005

-- AndrewJones - 12 Oct 2009

It looks like Foswiki::Time::parseTime does not understand the date formatted as 1-Jan-2004, so the table I pasted above is getting sorted as a number.

However, it does understand 13 Dec 2007 as a date, so the initSort problem is still a bug.

So in fact there are two bugs here. One related to the TablePlugin, and the other in the parseTime function.

-- AndrewJones - 12 Oct 2009

I have raised Item2238 for the Foswiki::Time::parseTime issue, so this report can focus on the initdirection problem.

-- AndrewJones - 12 Oct 2009

Analysed more

This bug has nothing to do with date. The bug is

• If you have initdirection="up"
• AND you do not have any headerrow

then the sorting does not work at all. It tries to sort but does it wrong. Also with non-dates

Example with non-dates

F	90	13 Dec 2007
A	40		12 Sep 2007
C	35		10 Oct 2007
E	28		12 Oct 2007
D	21		30 Nov 2009
B	20		26 Sep 2007
H	7	11 Jan 2008
G	2	12 Dec 2007

Dates but with headerrow. Now it sorts correctly.

Alpha	Planned	Forecast	Actual
D	10 Oct 2009		30 Nov 2009
H	11 Jan 2008	11 Jan 2008
G	12 Dec 2007	12 Dec 2007
F	17 Oct 2007	13 Dec 2007
E	12 Oct 2007		12 Oct 2007
C	10 Oct 2007		10 Oct 2007
B	26 Sep 2007		26 Sep 2007
A	12 Sep 2007		12 Sep 2007

Probably some index that assumes a header.

-- KennethLavrsen - 13 Oct 2009

Changed the format of the first date column to the format first reported, to verify if that is not broken as well - it is.

-- ArthurClemens - 13 Oct 2009

Andres raised Item2238 for the dashes in dates problem.

-- KennethLavrsen - 13 Oct 2009

Since 2238 is fixed I changed the example back to show the differences.

And after having looked more at the examples I can see that both up and down is broken.

The real bug is that when you have no header row the plugin assumes the first row is a header anyway.

-- KennethLavrsen - 18 Oct 2009

Looking at the code.

There is code that actively assumes that we always have a header row. You cannot make a table and sort it and get the first row sorted as well.

I am not sure this is a correct feature. I would have expected the headerrow count to be based on how many rows we have with bold content. Overridden by headerrows setting in the TABLE tag.

I am not keen on changing the code without discussion. But the sorting as such is not broken so I would call it a release blocker any longer.

-- KennethLavrsen - 18 Oct 2009

I am deferring this to 1.1. The trunk code for TablePlugin is totally rewritten and it will be too much waste work to fix this in 1.0 context.

And now that we know the nature we can live with it like we have done for many 5 or more years.

Most table do have a header.

-- KennethLavrsen - 18 Oct 2009

Commenting is disabled while not logged in