World: r3wp

although I do see why it's intended not to sort.

I could refresh the list below when you jump in Detail mode (and 
clear it when jumping in Search mode), but that means doing a quite 
big SQL query on all the tickets each time you switch from one mode 
to another...I tried to avoid that in exchange to a little less intuivite 
UI. Maybe there's some better solution.

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.

Most of Preset filters are supposed to show you the ticket list in 
a particular order. Letting users change the order would make the 
resulting list inconsistent with the displayed filter.

Yeah, the order is the point to most of the presets - we use it for 
project management and prioritization.

Default to blank: sounds like a good and simple solution (I would 
keep the auto-listing when jumping back to the Preset filters mode).

How about also disabling the link to sort in the header where it 
won't be used?

Found this interesting little thing in Chrome but not Safari:

Go to Presets
Set Unreviewed Submissions
Select bug#481

I get a redirect loop error message.

(This is Chrome 1. Installing Chrome 2 now...)

Chrome puts a lower limit on the number of redirects than any other 
browser.

For now go to the address bar and hit enter, repeat until it gets 
through.

Disabling the link: I'll see if this can be done without too much 
effort.

I've noticed the redirection issue with Chrome too, I'll see if I 
can improve that, but last time I've checked, it looked very expensive 
to fix i(but would make CureCode cleaner).

What I find confusing is when you try to look at changelog. There 
is initially no list, unless you select your project first, which, 
in case of R3, is just only one - R3 ....

Not for long, I think.

For now, but that may change. CureCode is built on a multi-project 
model.

Can you move tickets between projects, or do they need to be redone 
or copied?

Also, do they split the ticket numbers between them or use separate 
numbering?

Currently only using a SQL query. Adding a button on each ticket 
page to move it to another projet is a planned feature.

On a related note, do you think it would be possible to export from 
RAMBO to CureCode?

Numbering: that's one central question. Currently the numbering is 
global to all projects for a given CC instance. When I made the first 
CC version, I wanted to follow the Mantis application as much as 
possible while make things simplier. I wasn't sure if the numbering 
should have been global or local to each project. Now, I think that 
I used it long enough to think that the local numbering is more natural 
and user-friendly. I'd like to switch to that local numbering in 
a future CC release while keeping the global numbering as an install 
option (for Mantis users and for migrating Mantis databases).

RAMBO to CC: sure, it shouldn't be very hard, RAMBO data model is 
pretty simple.

If you use global numbering it will be easier to reference tickets 
externally, and to move tickets between projects.

Otherwise you'd have to change the ticket number if it was assigned 
to the wrong project, and to include the project number in the ticket 
references.

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.