World: r3wp

If I input a search item, then to clear the search item I have to 
clear it, and hit enter to resubmit with a blank search field?

Is there a filter to on searches to only show active issues?

Active issues: no such filter yet, I miss it too.

Looking at your preferences saving issue...

Can't see anything wrong with your prefs data nor in the prefs saving 
code. Your current default project is "All Projects", selecting R3 
project in the droplist, then going to Profile and hitting "Set default..." 
button should work, can you try it again?

Password remembering: Chrome's password system seems to have difficulties 
too. I don't have any clue about what the cause is, maybe BrianH 
would, as he had investigate such issues deeper.

Search item: any filter will remain active until you change its parameter 
or select another one.

Reset password link: CC's reset password link can only be compromised 
if someone get access to your email account or if he's able to sniff 
your web traffic. I'm not sure that the risk of someone taking control 
of your CC account and mixing up your posted tickets, or spamming 
comments is severe enough to raise the security protections higher. 
I usually apply protecting measures proportionnally to the level 
of risks involved. If you can convince me that the current level 
of protection used in CC is not high enough, I will raise it.

Doc, well, when I tried to log in for the first time I get the "Sorry. 
this page cannot be displayed.." error.  After fooing around with 
it for a while I thought perhaps the curecode code had to be located 
inside the root-dir. I originally had it on another drive. Well, 
that seemed to fix it. Thanks.

fooing = fooling

Such error message means that a REBOL error! has been raised in a 
RSP script or in %app-init.r. The error is then logged in %trace.log 
for you to review. I should make a customized error page by the way.

Doc, yes,  I realized that it was representative of an error after 
trying to create a test page to read a mysql db using your mysql 
library (just to test my mysql install). I wsa wondering though whether 
it's true that all the scripts have to be located within the root-dir? 
 That is, in my case, I had the curecode folder on a different drive.adn 
referenced that via the "root-dir" in the curecode web-app section. 
Well, actually, that was generated bu the "install.r" script. Just 
curious.
Thanks.

Webapp's root-dir must point to the folder where CureCode application 
is located. The install script doesn't move anything nor creates 
any file, it just builds the bugs database and prints out a webapp 
definiton based on the location of the CureCode folder, and answers 
you give.

Yes, I see that. What I was referring to was whether or not Cheyenne 
can see outside of  host's root-dir. BTW, the whole thing (Cheyenne 
and Curecode) work great.

Cheyenne can see what REBOL can see, there's currenlty no specific 
limitations in Cheyenne. However, it would be safer to limit accessible 
folders using the SECURE sandboxing system.

OK, thanks. Great stuff.

Would be better to create a R3 GUI project  now ... or filter them 
off and import them later on?

Doc, you might want to add a feature to curecode so that a user has 
a default project so we don't need to choose it everytime.

There is already ...

Really? I'll recheck as I must have missed it.

Ahhh there is.  I haven't been in my profie for so long.

Just wondering if  others are experiencing this behavior and/or this 
is a Cheyenne issue. After so many hours I have to restart the Cheyenne 
services in order for curecode to work. Cheyenne is working in that 
I can go to any other page.

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