World: r3wp

I have lost some work on occasion due to the login timeout not being 
long enough. The post-only interaction model means that I can't go 
back to get my edits, so if I have to log in again my edits are lost 
for good.

I have taken to composing my comments and tickets offline as a result.

either have a longer timeout or implement ajax pings to keep session 
active

Brian, I agree that's an issue that needs to be solved. I thought 
about removing session timeout. Session would then end only when 
the browser is closed.

On second thought, that solution wouldn't be reliable enough on server 
side.

Not even that. It would be sufficient to do two things:

- Do a server-side redirect to a get page when you go into edit mode 
on a ticket or comment update.

- If doing a post and the session has timed out, create a new session 
and save the data to it temporarily and take the person to a login 
page. After the relogin, take them back to the page with their edits 
prefilled in. Then let them save (or perhaps save on the way).

Yes, that would be a good approach that could solve the issue at 
application level (not having to modify Cheyenne's session framework).

That is the method I used when I ran into this situation in the past 
with ASP.NET and ColdFusion sites - don't know the RSP version.

Seems doable in RSP.

I'll add that to the todo list for next release.

Thanks

Carl is having me review the submissions for him, so I have been 
using CureCode a lot lately.

Outside of work time, of course. (Hi Reichart!)

:-)

I'll give you admin rights then, so you can have more control on 
lists like Versions and Categories. My development version also allow 
admin users to force account activation easily from the users admin 
page.

Cool.

Brian, the new CC version has this new feature : "Ticket submitter 
can now delete his ticket." Do you agree with this feature for R3's 
CC?

Updating R3's CC to version 0.9.6...

yes, good feature. :-)

;-)

Upgrade done. Let me know if there's any regression.

Changelog : 0.9.6 - 21/01/2009

	o FEAT: Ticket submitter can now delete his ticket.
	o FEAT: Admin can now delete any ticket.
	o FEAT: Admin can now delete a user.
	o FEAT: Admin can now change user's role.
	o FEAT: Admin can now force validation of a new user's account.
	
	o FIX:	Tickets list loading twice on first visit issue fixed.
	

 o LOOK: Input fields and buttons border width reduced to 1 pixel.

After adding a ticket to CureCode I can no longer  get the ViewTickets 
page.
I just get  


Sorry, this page cannot be displayed. Try again or contact the web 
site administrator.

Go back to home page

Strange bug. I can see the new ticket : http://curecode.org/rebol3/ticket.rsp?id=573&cursor=1

Looking at the log files...

Try to log out, then log back in.

i logged out a few times, no difference.
Later i will try to restart my Seamonkey.

Ok, after closing and restarting of  Semonkey it works again.

The error has been logged correctly, but reading the guilty code 
lines, I can't see how such error can happen...Looks like a nasty 
side effect hidden somewhere.

ah, good, I logged in Cheyenne using the builtin remote console and 
got your session object, now I see what happened, just need to find 
what caused that in Curecode scripts.

Being able to inspect a running Cheyenne instance using a remote 
console, that's why I like REBOL :-)

The same error happens with Firefox too, if I search for incidents 
and logout.
Without restarting my browser I cannot view the tickets.

That's a bug in RSP framework fixed in a more recent Cheyenne version. 
I'll upgrade CureCode's server tonight.

Is there going to be a pulic release of the latest curecode?

I can make you a snapshot of the last version as is, if you want?

That's the best I can do right now.

An official public release with docs and install script is planned, 
but I honestly don't know when I'll have time to work on it, I have 
a lot more tasks with much higher priorities to complete during the 
next weeks...so maybe by the end of february.

In the meantime, if you can be satisfied with a snapshot, I can put 
it onlin in a couple of minutes.

sounds good to me :)

Here it is : http://curecode.org/rebol3/tmp/curecode-096.zip

For database declaration in %httpd.cfg use 'r3bugs as keyword :

databases [
	r3bugs    mysql://...
]

mmm...should be : mysql://root:[password-:-localhost]/r3bugs

thanks

Suggestion : in the "new ticket" form, insert in first line the project 
selector, with the current project value.

My opinion is that the project selector where it is placed is not 
very seen by the early user.

I think It will avoid some submissions of bug in the wrong project.


Eg: R3 curecode must have a "RebDev" project for RebDev bugs and 
then, when you hit "new ticket", you can select "RebDev" or "Rebol 
3.0" immediatly.

That makes sense, I might add a Project: label (not editable) in 
the first line of the "Add Ticket" form. The project selector is 
global, it affects almost every page, so it needs to be in the banner 
zone (but I understand your argument).

In CureCode there are some tickets under Unreviewed Submissions older 
than half a year.

Are they seen as not important, missed or just not tagged rightfully 
?

Doc, I can't add a platform in CureCode. I would like to add WINE.

There's no UI for that list. I'll do it by hand right now and will 
note that feature in the todo list.

Cool. I'll tell Carl that the platform means Windows builds on WINE.

I need to restart the server to flush the DB cache (hopefully this 
won't be required anymore by the new Cheyenne version).