World: r3wp

It depends what you use it for I guess... 


for myself, I'd also use global numbering cause I have many projects. 
but I might want to have different sets of numbers on the same server. 
 


maybe you could just have an uid table name as part of the CC project... 
that way the decision is up to user and totally flexible.

project

darn altme, hehe

part of the CC project *name*

my god I think I'm becoming dyslexic! hehe

part of the CC project **CONFIG**

How is the information stored? Can you switch to a composite key, 
or an additional projectid-readableticketid key?

I was thinking about keeping the current ticket number as a "technical" 
number for external references and moving between projects while 
providing a local numbering in the UI (with the option to reference 
a ticket by its local number+project ID, or by it's absolute and 
unique internal ID). I feel like maybe it would be overcomplicated 
and not worth the effort?

I don't mind global numbering, but I may be in the minority here. 
As long as the filters filter by project, the apparently skipped 
numbers are not much different from deleted tickets.

CC data model : http://softinnov.org/dl/DB-schema.png

Yes, it's possible to switch to a composite key (ID+project or project+localnumber), 
but I often rely on a unique key (even if it is for internal use).

It may be confusing if we start a new project now, in the R3 CC instance, 
the first ticket would be #844...looks odd.

bug#3-794 referencing?

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).