World: r3wp

Anything I can do to help?

Once a ticket is dismissed, what is the proces for it getting to 
closed?
 I have been wondering that same thing (I'm the reviewer).

Carl and been in a hole generating R3 documentation so he hasn't 
been available to make policy decisions, but that would be the job 
of Carl and the reviewers (just me right now, want to volunteer?). 
However, I think "dismissed" should be removed from the stats and 
current list just like "closed", since it is useful to make the distinction 
between them for documentation purposes.

I think it would be better to exclude 

wishes" from the front-page stats too" Please don't. All requests 
for new functions or options are marked as wishes, so we need to 
keep track of those too if they aren't dismissed.

Missing functionality is a bug too, though less severe.

I entered a bug report into the Rebol3 tracker and it got duplicated 
- #645 & #646. I don't think I clicked "submit ticket" twice though 
I may have accidentally double-clicked on it.


I tried to delete #645 and followed the sequence "edit ticket"->"delete 
ticket"->"confirm ticket" but it wasn't deleted.

Doc, two requests:

- Remove the value="" attributes from the username and password input 
tags on the login page.

- Filter out tickets with dismissed status from the "Active Priorities" 
and "Worst Severity" preset filters.
Dismissed should be considered complete - rejected, but complete.

Noted. I'll make these modifications this weekend.

Is the value="" removal request related to an issue you've experienced 
with Chrome?

The value="" disables saved passwords. I don't want to have to load 
up my password database if I am on a trusted computer that I can 
just let the browser track my passwords.

Good to know. Your fixes are built on my CC developer instance. I'm 
currently adding a few more feature/fixes before releasing.

BrianH, on 21-Jan 11:16 PM you said : "Do a server-side redirect 
to a get page when you go into edit mode on a ticket or comment update."


I'm not sure to understand the "server-side redirect to a get page" 
part. When you click on a ticket ID or comment [Edit] button, you 
enter in edit mode using a GET request. What would a redirect improve 
here? Is it related to the browser Back button and client cache management?

New CureCode version released. Changelog : 0.9.7 - 11/04/2009


 o FEAT: Dismissed tickets are now filtered out from "Active Priorities" 
 and "Worst Severity" filters
	o FEAT: Current project name added to "Add Ticket" form.

 o FEAT: Reversed sort order for Versions and Categories lists in 
 admin page.

 o FEAT: Added an experimental API for getting tickets in REBOL format.

	o FIX:	Front page stats now count "dismissed" tickets as closed.

 o FIX:	Message "n ticket(s) found" fixed for localization, now translates 
 correctly in french.

CureCode API documented here : http://rebol.net/wiki/CureCode#API_documentation

Let me know if there's any bug or regression.

Source code package for 0.9.7 available at : http://curecode.org

I've started working on the "POST data lost when session times out" 
issue, but that requires some deep changes in the RSP engine, so 
this enhancement is currently postponed.

Great.

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