See example at http://twiki.org/cgi-bin/rdiff/Plugins/FindElsewherePlugin?rev1=22;rev2=21

• Before: 4.0.0, 4.0.0-beta6, 01 Sep 2004, 01 Feb 2003, 01 Dec 2001, 01 Sep 2001
• After: 4.0.0, 01 Dec 2001, 01 Sep 2004, 01 Sep 2001, 01 Feb 2003
• Proper sequence: 4.0.0, 01 Sep 2004, 01 Feb 2003, 01 Dec 2001, 01 Sep 2001 (as defined in TWiki:Plugins/TestedOnTWiki)

Not sure if this is an issue in general, or just on TWiki 3 to TWiki 4 topic format upgrade.

-- PTh

Just went through the process of generating a testcase for this, and it works just fine using your example data. This is probably a result of a form change in your data (someone changed the sort order of the fields, which seems likely given the changed content).

It would help enormously if you could provide testcases for problem reports showing how to reproduce the erronous state. It takes me ages to build testcases for things like this, and the frustration factor when it works as expected is considerable.

CC

And it is equaly frustrating to have real bugs closed.

The way Cairo worked was to arrange the field values according to the sequence in the form definition topic. I do not know why this has been changed, e.g. why some form fields show up in random order on twiki.org (and other TWiki sites)

Reopened.

-- PTh

It hasn't changed

Read my lips; it works for all the testcases I have been able to generate! Unless you can demonstrate a problem, I have no choice but to close it!!!

Discarded pending a reproducible testcase.

CC

Crawford, this time I am going to play the ping pong. It looks like we have different expectations here. I simply report bugs and expect that bugs are handled as bugs until fixed. You expect the bug reporter to supply test cases, which I find excessive. I do not expect you to fix this bug, but please do not discard it.

OK, I try again. See

http://twiki.org/cgi-bin/rdiff/Plugins/FindElsewherePlugin?rev1=22;rev2=21

• r21: TestedOnTWiki has: 4.0.0,  4.0.0-beta6,  01  Sep  2004,  01  Feb  2003,  01  Dec  2001,  01  Sep  2001
• r22: TestedOnTWiki has: 4.0.0,  01  Dec  2001,  01  Sep  2004,  01  Sep  2001,  01  Feb  2003

TWiki:Plugins/TestedOnTWiki looks like this:

Name	Type	Tooltip message
4.0.0	option	Dakar
01 Sep 2004	option	Cairo
01 Feb 2003	option	Beijing
01 Dec 2001	option	Athens
01 Sep 2001	option

The saved sequence does not match the definition, which I consider a bug. Most likely related to topic upgrade from format 1.0 to 1.1.

--PTh

Also, look at the history of TWiki:Plugins/TestedOnTWiki, the sequence of the items has not been changed.

--PTh

Here are other topics that have an incorrect sequence of TestedOnTWiki items: TWiki:Plugins/SpreadSheetPlugin, TWiki:Plugins/NewsPlugin, TWiki:Plugins/FindElsewherePlugin, TWiki:Plugins/KoalaSkin, TWiki:Plugins/BeautifierPlugin, TWiki:Plugins/HeadlinesPlugin, TWiki:Plugins/TocPlugin. In all cases the incorrect sequence happened on topic format upgrade.

The proper fix is to save items in the sequence of form definition.

--PTh

The reason I discard reports that I consider do not have enough supporting information is simple. I have seen too many bug DBs that have totally lost their effectiveness because they have become constipated with reports that no-one knows what to do with - because they lack sufficient information to reproduce the problems. A week ago the TWiki bug DB was nearing this state, with over 70 open reports, many of a dubious quality. I have burned a lot of time in the last week or so dredging through all those reports, fixing, prioritising and clarifying them.

I will continue to discard reports that don't meet a minimum criteria for fixability. With that number of reports in the DB, I do not have the time or the motivation to run around after people researching poor quality reports. Asking for feedback seems to be a waste of time, as reporters very rarely offer it - look at the number of reports currently sitting in that state. I also don't want to see other, desperately needed, bug fixers demotivated by vague or unreproducable reports.

I'm sorry you have fallen foul of this policy - your original report wasn't all that bad, after all. But you provided a list of historical symptoms; sure, I can observe the same result as you, but without being able to reproduce the effect, I can't do anything with it.

BTW I strongly doubt it's anything to do with a format change. The only difference between 1.0 and 1.1 formats is in the encoding of values to remove the %__Q__% etc symmetric encoding. The most likely cause is a change to the ordering when the query is translated to Meta during a save. I vaguely recall seeing some work in that area being checked in.

CC

This was a pretty accurate bug description to begin with. And with a topic on twiki.org to verify. And with the proper indication that the bug is related to topic upgrade (as confirmed later).

The proper fix is to save items in the sequence of form definition on every topic save. This will fix also topics broken by this bug.

-- PTh

---

OK. I verified the problem.

Test case: I took the following form

|  *Name:*|  *Type:*  |  *Size:*  |  *Values:*  |  *Tooltip  message:*  |
|  [[Know.TopicClassification][Topic  Classification]]  |  select  |  1  |  Select  one...,  NoDisclosure,  PublicSupported,  PublicFAQ  |  Classify  a  topic  |
|  [[OperatingSystem][OperatingSystem]]  |  checkbox+buttons  |  3  |  OsHPUX,  OsLinux,  OsMacOS,  OsSolaris,  OsSunOS,  OsWin  |  Select  the  OS  |
|  OsVersion  |  textarea  |  100  |  |  |
|  Another  |  text  |  10  |  A  really,  really  bad  event  |  |
|  Select  |  select  |  1  |  low,  ,  high  |  |
|  web  |  text  |  10  |  |  |
|  Start  |  date  |  30  |  02  Oct  2006  |    |

In a topic with this form, I selected OSMacOS and OSSolaris. They were ordered correctly in the saved topic. Then I selected in addition OSLinux. However, now it was stored with OSLinux after OSMacOS but before OSSolaris, while one would expect this to be the first in the list.

All this said, I am not sure whether there really is a spec saying that the items are stored in the order in which they are defined. However, such spec would be sensible as it makes comparison on merging more reliable. -- TW

---

I looked into the code and found that the arbitrary ordering is coming from the browser. It appears that there is no way of predicting which order the browser will take the checkboxes when it assembles them as a single cgi parameter.

Therefore, if we want the order in which the items are written into the topic to be the same as the order in which they appear in the form, we must enforce this order.

I have updated TWiki::Form::getFieldValuesFromQuery so that it respects that order. There may be a slicker way of doing this, but as the number of items is typically small, it probably does not matter. -- TW

---

P.S. I agree with CC. If one does not have a reproducible test case, it is very difficult to get motivated to fix a defect.

P.P.S. Maybe this warrants another state in our bug state machine: "Limbo" with the meaning: "I have examined the bug but could not find a test to reproduce it". Such state would avoid closing the bug but would not clutter up the bug pipe line with irreproducible reports. -- TW

---

Add CC's suggestion to avoid loosing 0 checkbox values. -- TW

---

This introduced Item3434. Reverted.

MD

With all the hard work done to fix the original problem I want to make sure both TW and others see this and fix it. Hopefully without breaking anything else this time

Setting to urgent since it seems important enough since people have spent time both analysing and fixing.

KJL

---

MD introduced a defect in his roll-back in that there is a leading "," before the list of values.

In addition, MD's solution to his problem does not seem to work anyway, at least not in my installation. -- TW

---

This is a release blocker. No release tonight Sunday.

KJL

---

Overlap in editing.

Supporting Bugs:Item3434. -- TW

---

Just a comment on timing. The bug system has no way of alerting me that this bug had been reopened with Urgent priority. I found this by accident when killing time in Miami airport on route to Argentina. This being a rather long flight involving several hour stop over in Santiago I could not get to this defect until late on release date (it took a while to get the network working in the hotel here, to boot). So sorry, but I did my best.... -- TW