World: r3wp

Dockimbel -- could we have some way of searching (or sorting results) 
according to Submitter name?

I just tried to have a quick scan of all my contributions to the 
R3 bugs (see discussion in REBOL3 group).
It was not easy.

I'd especially like an easy way to find FIXed bugs by submitter name......That'd 
remind and encourage me to test the ones I'd raised.

Good point, the "By submitter" filter is not fully implemented yet, 
so not really working. I've added that in my Todo list and will see 
next week if I can improve that quickly.

thanks!

Did anyone tried to play with CureCode's API yet? Should be fairly 
easy to make a VID-based popup notifier for new or modified tickets.

Looks interesting.

Should be also easy to integrate in RebDev, so you could see a ticket 
content without going in the browser. Or maybe just by extending 
the 'bugs function to accept an issue! ID and display the ticket 
in console...

We could write an example client to show how it would work?

I thought about doing that for the last release, but didn't had the 
time. I should be able to work a little on that next weekend. IIRC 
Gabriele wrote a small popup notifier app in View (was it for incoming 
emails?) with a nice slide in effect.

we still don't have an API for writing bots for Rebdev, though.

does anyone think it would be even remotely possible to write a one-time 
exporter from bugzilla to curecode?

I have a question for CureCode users : do you think that adding a 
rich text editor for Description and Comment editing areas would 
be a usefull addition? See an example of such integrated rich text 
editor in the bottom of the page there : http://www.cheyenne-server.org/blog.rsp?view=19&cmt=on

One drawback of such change would be that these fields would be stored 
as HTML in the database making them less easily usable for external 
non-HTML renderers (like making a View-based client, or integrating 
in a IDE).

HMTL can always be stripped out.

I'd rather see a possibility for wrapping code in preformatting tags. 
Rich text is not important in comments.

I don't think that rich text descriptions and comments will add much 
value. 


I agree with Henrik that  pre-formatted code (and console sessions) 
would be helpful especially if they were  displayed in "boxes".

Don't think so too.

I don't think rich text will add much value.

me to.. maybe bold and italic.. to emphasise something but not much 
beyond that

I sometimes use a few HTML tags for CureCode tickets like : <B>, 
<U>, <I> and <A>, but not much more. Having to type HTML code inside 
text areas is not a clean method, that's why I proposed an integrated 
WYSIWYG editor. But it seems not adequate to R3 users. I might add 
it as an option for our customers in a future CureCode version, thought.

yes, for links it's also helpfull.. I agree that <a href=...> or 
other html stuff inside of comments field is not that great

Doc, did you ever notice that Cure is one letter away from Curse? 
 ;-)

.

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.