Re: Self Register = 3 doesn't work any longer, posted by Olivier Callot on Tue May 17 17:00:03 2011
|
| Stefan Ritt wrote: |
|
| Olivier Callot wrote: |
|
Dear Stefan, after a long time I managed to get a test setup. The line that creates the misbehaviour is
Guest Menu Commands = List, Find, Login, Help
which seems inocuous! But with this line a user with inactive account can login without validation. Without this line I get also the proper web page indicating that the account has to be activated when I register as new user.
Another little annoyance: When a user is prevented from login ("The account is currently deactivated") there is NO WAY to login, as any action with Elog tries to use the (non activated) username and password. I can't get back the login page!
Thanks
|
Great. This this description I could reproduce the error and fix it. The fix is in SVN revision 2414.
Cheers, Stefan.
|
If you could also obtain the display of the message "Your request has been forwarded to the administrator.You will be notified by email upon activation of your new account." when a new user apply in the presence of the Guest Menu commands, that would be perfect. Cheers |
Spurious characters in the searched string, posted by Olivier Callot on Mon Sep 26 08:13:10 2011 
|
Hi,
We have a problem with the search command: Since our last upgrade to v2.9.0-2418 the searched string is pre- and postfixed with ASCII character expressed in % format, see the attached image. The searched string is prefied with %255E and postfxed by %2524 in the URL. And teh search fails. This affects searches from drop-down menus.
Thanks in advance. |
|
Re: Spurious characters in the searched string, posted by Olivier Callot on Mon Sep 26 11:16:19 2011
|
| Stefan Ritt wrote: |
|
| Olivier Callot wrote: |
|
Hi,
We have a problem with the search command: Since our last upgrade to v2.9.0-2418 the searched string is pre- and postfixed with ASCII character expressed in % format, see the attached image. The searched string is prefied with %255E and postfxed by %2524 in the URL. And teh search fails. This affects searches from drop-down menus.
Thanks in advance.
|
Strange. In this forum it works without extra characters. Just try it yourself. Do you have any strange configuration? Can you send me a minimal elogd.cfg which produces that error, maybe derived from the example elogd.cfg from the distribution.
- Stefan
|
Well, It may be our implementation of re-routing web requests: The requested string in elog is prefixed by %5E (^) and postfixed by %24 ($). But in my case, the '%' is again escaped as %25 so the prefix becomes %255E that is not understood by elog as being '^' ...
I will see with my experts in routing if this is something that can be fixed in our configuration. But when elog processes the input string, it should un-escape these characters and find back the '^', no? |
|
Re: Spurious characters in the searched string, posted by Olivier Callot on Mon Sep 26 14:49:48 2011
|
| Olivier Callot wrote: |
|
| Stefan Ritt wrote: |
|
| Olivier Callot wrote: |
|
Hi,
We have a problem with the search command: Since our last upgrade to v2.9.0-2418 the searched string is pre- and postfixed with ASCII character expressed in % format, see the attached image. The searched string is prefied with %255E and postfxed by %2524 in the URL. And teh search fails. This affects searches from drop-down menus.
Thanks in advance.
|
Strange. In this forum it works without extra characters. Just try it yourself. Do you have any strange configuration? Can you send me a minimal elogd.cfg which produces that error, maybe derived from the example elogd.cfg from the distribution.
- Stefan
|
Well, It may be our implementation of re-routing web requests: The requested string in elog is prefixed by %5E (^) and postfixed by %24 ($). But in my case, the '%' is again escaped as %25 so the prefix becomes %255E that is not understood by elog as being '^' ...
I will see with my experts in routing if this is something that can be fixed in our configuration. But when elog processes the input string, it should un-escape these characters and find back the '^', no?
|
It turned out to be a setting of our re-routing of requests that re-escaped the '%'. Sorry for the noise. Cheers |
Comment tooltip shows comment from other logbook, posted by Oleg Solovyanov on Wed Aug 10 18:32:14 2005
|
I have several logbooks with Comment lines,
but the tooltip shows sometimes the correct comment,
sometimes the comment from other logbook...
I see the same behaviour also on this very page...
I use Mozilla 1.7.10.
Tried with Konqueror -> same problem. |
|
page2?cmd=List does not show next page, posted by Oleg Solovyanov on Tue Nov 15 08:35:33 2005
|
Maybe I'm doing something wrong, but the following does not work on a Elog with multiple pages:
1. View message
2. Click List
3. Click Next or page number
4. Only the last page is shown
It looks like the URL pageN?cmd=List does not work, while pageN works.
Any hints?
Same behaviour can be seen also with Discussion forum on Elog site. |
|
Re: page2?cmd=List does not show next page, posted by Oleg Solovyanov on Wed Nov 16 15:24:53 2005
|
| Stefan Ritt wrote: |
| Oleg Solovyanov wrote: | Maybe I'm doing something wrong, but the following does not work on a Elog with multiple pages:
1. View message
2. Click List
3. Click Next or page number
4. Only the last page is shown
It looks like the URL pageN?cmd=List does not work, while pageN works.
Any hints?
Same behaviour can be seen also with Discussion forum on Elog site. |
I don't understand. I tried on the Discussion forum:
1. View message, for example http://midas.psi.ch/elogs/Forum/1506
2. Click List, which takes me to http://midas.psi.ch/elogs/Forum/
3. Click Next, which takes me to http://midas.psi.ch/elogs/Forum/page2
Then I really see page2, not the last page. So what do you do differently? |
Somehow in my logbooks List command would add cmd=List to the URL
And this does not work... |
|
Re: page2?cmd=List does not show next page, posted by Oleg Solovyanov on Thu Nov 17 23:40:10 2005
|
Yes, new version seems to fix this bug, but...
Now there's a new feature: sometimes it breaks the text message line into 2 when
displaying the summary page.
Maybe it happens only with Russian text  |