World: r3wp

if you use external uid tables, you can have a dual id... the ticket 
global uid, and the projects-related id.

use the global uid internnaly, and show the project on on displays.

Well, I would need to be able to work on more than one project at 
the same time so I can copy tickets that apply to more than one product, 
like R2 and R3. The advantage for using CureCode would hopefully 
be to reduce work.

the use of the external tables can probably be replaced by some SQL, 
but for some reason I find it simpler to let mysql handle autoincrementing 
and retreiving last insert id, it seems easier to support when many 
threads are inserting at the same time on the same table.

I think we're going to start adding categories to the R3 project 
too - at the very least to separate out the chat and GUI bugs.

reproduces
 table? What's that?

A table containing reproducibility qualifications :
	('Always'),
	('Sometimes'),
	('Random'),
	('Have not tried'),
	('Unable to reproduce'),
	('Not applicable');

Where in the UI is that set? Future reference?

Present in CC, but not used in current CC/R3 (I've removed it, because 
we add 2 new fields : Type and Platform, and I wanted to avoid overloading 
the tickets header section with too much info).

It's not often used and you can't currently filter tickets on that 
field, so adding it back now would not give much gains. When CC will 
allow to query on all tickets fields, this field might find its way 
back.

Well, we've been using the comments for the reproducibility ant it's 
been working fine. No problem :)

<local numbering in the UI>

A project specific number as well as an internal UUID will be most 
flexible.
Think of cases when you may want to:
-- delete a project, and then later re-instate it
-- import a project from somewhere else

-- have the project database running decentralised across several 
loosely-coupled machines

-- have a project database that (for whatever reason) gets forked, 
and then needs to be merged back into one.


At the user interface level, all I should ever need to know is that 
issues are numbered sequentially from 1 for that project. How you 
implement that internally should be invisible to me.

Except that the tickets are referenced by human-written numbers from 
inside and outside CureCode. Inside is no problem - just assme the 
samme project. Otside is a problem unless some kind of project reference 
is included. An example of an outside reference is the bug#794 style 
referencing in R3 chat, or the get line referencing elsewhere. It's 
easy to add a project reference to get line stuff, but harder for 
bug#794 referencing.

I'm pushing the new v.0.9.8 in production, it shouldn't need to restart 
Cheyenne, but if someone (e.g. BrianH ;-)) is writing a long text 
in CureCode, better save it right now.

Changelog : 0.9.8 - 26/05/2009

	o FEAT: "User" column added to tickets list page.
	o FEAT: Search text feature extended to comments.
	o FEAT: "Main" page now populated with statistics.
	o FEAT: New Preset filter: "My Reports" (default when logged)
	
	o FIX:  "By Submitter" filter now working correctly.
	o FIX:  Redirection issues with Chrome fixed.
	o FIX:  In Preset mode, columns sorting links removed.
	
	o LOOK: Textarea edit fields now enlarged to maximum width.

For users having a session running before the upgrade, you should 
terminate your session (logout or restart browser). The session content 
has been changed, so you'll get some page errors if you keep using 
your old session.

yes.. now it's fine

Let me know if the word "Stockpile" is the adequat english word in 
"Main" page (I'm not sure about that).

We haven't been using "block" much because there is no consensus 
as to what it should mean. It could be "blocking further development 
in some way" or it could mean "process halts but doesn't crash (usually 
an endless loop)".

When I did a search for "return", I got duplicate entries in the 
results. If it matters, I was on the "Recent Changes" preset beforehand.

I see the duplicate entries too.

Some of the duplicates had the same number as the number of comments.

Good hint, looks like a SQL grouping issue.

Only seems to be dismissed tickets, but not all dismissed tickets. 
Annoying inconsistency.

Wait, that last one is not true. I found a dup tested.

No dups if I limit the search to the summary fiields.

Duplicates issue fixed. It was a SQL error : DISTINCT COUNT(id) instead 
of COUNT(DISTINCT id).

I hate when that happens :(

Verified working.

Is the fix for Chrome ok too for you?

Re "block": it should be considered from the user POV. It means that 
the feature is not available because of the bug and that there's 
 no workaround. It's higher than "crash", because a crash can have 
workarounds, giving you access to the feature using other ways.


Example: if "make vector! [4 10]" crashes but not "to-vector [1 2 
3 ...]", it should be marked as "crash", there's a workaround for 
using vector! values. If both were crashing, the issue should be 
marked as "block", because, there would be no way then to use vector! 
datatype.

I haven't noticed any redirect errors since the new version, so tentatively 
yes, it seems fixed.

That's what I thought block should mean. Let's adopt that meaning 
for the next round of reprioritization.

Henrik: "An alternative would be to blank the list when switching 
mode. That perhaps will lead the user to see that an action needs 
to be done to display a list that corresponds with the search query."


Sorry, couldn't fix that in this release, it's much more complicated 
to fix efficiently than I expected first. I should maybe try to clean 
the  result list using Javascript...will see that later.

I don't mind having the list still there.

It's ok. You tried. :-)

What is type=Nuts supposed to mean? It's too fun to get rid of, so 
we should use it :)

Lol. IIRC, it was transfered from AltMe R3 Tracker during the migration 
process. I don't what was the exact meaning in Tracker.

<don't know>

Color changed for following statuses : problem, waiting, and deferred 
(to help distinguish "active" from "suspended" tickets).

The color is quite close to the dismissed/completed color - I had 
to see both next to each other to tell them apart.

It seems to be related to the angle of my monitor. At high angles 
they are the same, at low angles they are different.

I'll see if I can adjust that a little.

The history in view/edit ticket mode shows status changes as "=> 
none 8" for varying numbers, depending on the status. The status 
field in the edit dropdown above is correct.

I'm trying to change ticket 820 from an issue to a bug, but I get 
a server failure.

Did you notice such failure only for that ticket?

Since you can't delete history, I tend to not make such changes unless 
they are necessary.

The failure is consistent though - I've tried multiple times. Changes 
to other fields worked, as long as the issue-to-bug change wasn't 
there.

Issues fixed. It was caused by a conflicting library version from 
another webapp running on the same Cheyenne instance. Should be ok 
now.

Verified fixed. Apparently the failed attempts were partially completed, 
so the history is a little messy on ticket 820 now :(