World: r3wp

.

Bugzilla exporter: sure, it's possible, but requires a significant 
amount of work to make the mapping between the Bugzilla and CC data 
models. 

Bugzilla: http://www.bugzilla.org/docs/2.16/images/dbschema.jpg

CureCode: http://softinnov.org/dl/DB-schema.png(not the latest version, 
but close enough)


Btw, I did some similar work when I migrated tickets from AltMe tracker 
to CC. You can find the migration script in R3-alpha world (cached 
locally at altme\worlds\r3-alpha\files\Users\DocKimbel\migrate.r)

Brock: well, I guess that's maybe because, sometimes, the "cure" 
can be worst than the desease, so you might want to call it a "curse". 
;-)

I'm about to release a new CureCode version in a few hours, let me 
know if you have some bugs/issues to fix.

Currently the changelog for the new version is :

	o FEAT: "User" column added to tickets list page.
	o FEAT: Search text feature extended to comments.	
	o FIX:	"By Submitter" filter now working correctly.	
	o LOOK: Textarea edit fields enlarged to maximum width.

will sorting work? they don't work for me in Safari

Cool. Does it have the value="" removed from the login page fields? 
That is the top of my want list :)

BrianH, that one has been fixed in the previous release.

Gah, it has and it didn't solve the problem for me. Darn.

Sorting: it works with the "Search" and "Detail" filters but not 
with the "Preset" ones. That's an intended feature. I've just tested 
with Chrome 2.0 and sorting works as expected (should be the same 
for Safari, no?).

Let me check...

If I click Detail and click a header, it just jumps back to Preset 
and doesn't sort. There is an orderby=N in the header though.

checking in chrome and Firefox...

Same in Chrome and Firefox.

Clicking on Detail only shows the Detail filters, the list below 
still reflects the result of the Preset filter. You have to activate 
the Detail filter first by hit "Apply" button.

oh, you're right. I wonder if there could be a UI tweak done here.

or simply have sorting working under Presets. then no need for UI 
tweaks.

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.