World: r3wp

I'll try logging out and seeing if that makes a difference. Maybe 
the session expires and then on this local machine (also runs the 
services), it needs the service restart.

Since Cheyenne is still working it sounds like the issue might be 
with the database ...

james, I have no such issues, but I guess it depends on how intensely 
the database is used. maybe write a separate test script that performs 
db access and reads some curecode tables into the browser. if it 
doesn't work, when curecode fails, then the db connection must be 
bad.

James, I've never experienced that. CC's default session expiration 
time is 30 minutes. I'll install Cheyenne as service on my XP box 
and will see how it behaves with CC after a few hours.

Guys, thanks for your input. I did log off, thinking that perhaps 
not doing so might be causing the issue. This morning, the same "page 
unavailable" occured. I checked the log and there is an RSP script 
 error in the head.rsp file:

 ** Script Error : say expected data argument of type: string none 
	** Where: rsp-script 
	** Near:  [projects/2: say projects/2 

Then a separate entry 

Request = make object! [ ...
 referring to the index.rsp file.


I can in fact run my test page which has a mysql test  that reads 
the curecode tables within it without any issues.


I have that work-around of restarting the service so I'm cool. I 
was just wondering if anyone else had that same behavior.

I'm also going to test it from another machine today.


Interesting. Reaching the server from another machine worked. Then 
when I went back to the server machine and tried curecode, it also 
worked.  

I'll do some more tests and let you know. Thanks.

Can you run it for a whole day in normal mode (not as service) to 
see if it's related to service mode?

OK, I''ll do that.

Alright. I ran it  overnight as an application and it produced the 
error. But, I also had the browser running overnight. I just closed 
and re-launched the browser and now it works. Perhaps it is a cache 
issue.

I think we can at least say that it is not related to the cheyenne 
services.

Thanks for testing. Good to know, I think that's probably related 
to the way session expiration is handled in CC. I'll see if I can 
reproduce that with a short session timeout.

After a few attempts playing with expired sessions, I can't reproduce 
your issue with the latest SVN revision. Try to run Cheyenne in verbose 
mode using : -vvv as command line argument and send me the log chey-* 
log file once the error happens.

OK, I will. This morning I quit the browser and started the browser 
up again. It works fine. So the context where I have that issue is 
when the page is left open for some period of time.

What page?

Could category be added to the possible criteria on the detail page?

Doc, the Curecode page. OK, I let it sit overnight and got the error. 
Which log do you want ? Trace-80? Default-access?

All of them (including chey-<pid>.log file if you have it). Just 
zip them and send them to me by email. Thanks for taking the time 
to help me investiguate this issue.

Yeah, I haven't seen the chey file. Where do you want me to send 
them to? The nr address?

The one from my AltMe profile is ok.

The chey-<pid> file is produced when Cheyenne is run in verbose mode 
(-v... command line option) with no window (-w or encapped).

Hmm. I thought I was running it in verbose mode but maybe not. I 
do not see that file. I sent the files a little earlier.

Got them. I give it a look today.

Brian: your request has been implemented in the upcoming 0.9.11 version. 
I should put it online by tomorrow.

Thanks. I've been trying to make the categories more useful, when 
you're fixing a bunch of related bugs. This should help.

It seems that some users are still not able to sign up for a curecode 
account:

http://www.rebol.com/cgi-bin/blog.r?view=0457#comments

I've activated all pending accounts manually. It seems that some 
hosting mail services like qip.ru have a hard time dealing with 8bit 
encoded emails. I've sign up for an account @hotbox.ru and will fix 
this issue in Cheyenne's MTA.

are you sure that they're not spam?

How can I know?

100% of the hundreds of signups for my old website from .ru domains 
were spambots

Normally the email confirmation fails so you know that way

CureCode server will be down for a few seconds for maintenance starting 
from now.

SimpleMachines forum is switching into temp page informing about 
maintenance mode - so people see the message, but are not able to 
access dynamic content, databases and so.

Database migration failed, Curecode server restarted with previous 
configuration. Will retry again after checking logs.

Oldes, that would require to setup a dedicated web server for that 
maintenance page. As usually, the service interruption is just for 
a few seconds, it's most of the time not even noticed by users.

If I have to take down the server for a longer time, I'll provide 
an info page.

Database migration done. Curecode.org domain's IP has been changed 
to point to a new server, so during the DNS propagation time, curecode.org 
will work on both the old and new server (24-48h). Both Curecode 
instances are now pointing to the same database instance on the new 
server. If all goes well, you shouldn't notice anything, nor have 
any downtime. Let me know if there's any issue.

The new version 0.9.11 is ready, I'll install it once the migration 
to the new server will be fully completed, so in two days.

FYI, my DNS hosting company doesn't allow lowering the TTL, so I 
had to resort to such solution to avoid service interruption due 
to DNS propagation. The new IP is a failover address that I can attach 
freely to any of our servers without any delay, so future server 
migration will be easier to handle.

CureCode application upgraded to 0.9.11. Changelog :

	o FEAT: Custom captcha system replaced by ReCaptcha.

 o FEAT: Auto-adjusting scale for bar charts in stats (more accurate 
 and readable).
	o FEAT: Category selector added in tickets list detailed view

 o FEAT: Empty attached file section not shown anymore in tickets 
 read-only view.
	

 o FIX: When clicked, attached files will now show up in browser's 
 window by default.

 o FIX: When attaching file in a new ticket, the returned attached 
 filename was 'none'.

New CureCode instance for Softnnov's OSS projects: http://curecode.org/si/
 (you can import your REBOL3 CC account on the new registration page: 
http://curecode.org/si/register.rsp, just use "rebol3" as instance 
name).

Today I am having trouble updating a ticket in the rebol3 project. 
I do "Update Ticket" and the changes stay there, except the "Fixed 
in" field changes, and when I go back to View Tickets the changes 
aren't there, nor are they when I go back to the ticket. Creating 
and updating comments works though.

Does it happen on any tickets or just a specific one?

I've only checked #1513 - I don't like to make test changes because 
they're logged. I can check another after I finish writing a comment.

It just worked on #1512 - I'll check again.

Still fails. I want to change #1513 to status: dismissed, severity: 
"not a bug".

Can you try with a different browser?

Yeah, already tried with IE8. I got the same behavior, plus layout 
bugs in the file upload submit button.

Plus saving the password worked; that was nice.

Layout bugs with IE: known issue, need to curecode it to not forget 
it again.

I found a post on the exact model IE8 uses to change its rendering 
mode. http://blogs.msdn.com/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx

Can't find anything wrong in the database, I'll give a look at your 
session data in memory, can you post me your public IP address privately 
please?

#1513: issue was an empty "description" field that was blocking the 
changes. I'm investigating how this mandatory field could have been 
skipped during ticket creation.