Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 197 of 238  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
icon4.gif   reverse sort option does not work for quick filter, posted by Heiko Scheit on Wed May 18 14:12:02 2005 
The 'reverse sort' option does not work for quick filter searches. In the
URL there is always written 'reverse=0'. For normal 'Find' it works OK.
    icon2.gif   Re: reverse sort option does not work for quick filter, posted by Stefan Ritt on Sat Jun 4 12:21:21 2005 

Heiko Scheit wrote:
The 'reverse sort' option does not work for quick filter searches. In the
URL there is always written 'reverse=0'. For normal 'Find' it works OK.


I don't understand the problem. If I take the example elogd.cfg from the distribution, it sorts in reverse order, since the file contains Reverse sort=1. If I apply a quick filter, the result is still sorted in reverse order (entry ID from high to low). If I set Reverse sort=0, the even after applying a quick filter, the entries are sorted with their ID from low to high. Applying a quick filter should not put a reverse=0 into the URL, so it's strange to me where this comes from. Can you try to reproduce the problem with the demo elogd.cfg?
       icon2.gif   Re: reverse sort option does not work for quick filter, posted by Heiko Scheit on Sat Jun 4 16:37:04 2005 
[quote="Stefan Ritt"][quote="Heiko Scheit"]The 'reverse sort' option does not work for quick filter searches. 
In the
URL there is always written 'reverse=0'.  For normal 'Find' it works OK.[/quote]

I don't understand the problem. If I take the example elogd.cfg from the distribution, it sorts in reverse
order, since the file contains [i]Reverse sort=1[/i]. If I apply a quick filter, the result is still sorted in
reverse order (entry ID from high to low). If I set [i]Reverse sort=0[/i], the even after applying a quick
filter, the entries are sorted with their ID from low to high. Applying a quick filter should not put a
[i]reverse=0[/i] into the URL, so it's strange to me where this comes from. Can you try to reproduce the problem
with the demo elogd.cfg?[/quote]

I played with the quick filter settings somewhat.  Here is what I get.
I can't really make sense of it, but maybe you can figure out what
happens.  Below, the first line always contains the 'Quick filter'
config setting.  The lines below show the URL after searching with the
quick filter for the 1st, 2nd,... attribute listed in the quick filter
setting.  (The common base of the URL was removed.  Shown is
everything after the last '/'.)  Each 'quick search' was started from
the 'List' or 'Back' page, i.e. the URL ended with a '/'.

As you can see below the result depends on the number and on the order
(!) of the attributes.  Only a few give the desired result (marked
with # OK).  Incidentally the option 'Date, Something' works fine,
which is the combination found in the demo config file.  :)

Quick filter            = Subject, Date, Login
?Subject=sd&Login=           # OK
?last=1&&reverse=0
?Login=sdf&reverse=0

Quick filter            = Subject, Login, Date
?Subject=scd&reverse=0
?Login=sdf&reverse=0
?last=1&reverse=0

Quick filter            = Date, Subject, Login
?last=1&&reverse=0
?Subject=sd&Login=           # OK
?Login=sd&reverse=0

Quick filter            = Subject, Date
?Subject=sd                  # OK
?last=1&reverse=0

Quick filter            = Date, Subject
?last=1&Subject=             # OK
?Subject=ddsd                # OK

Quick filter            = Login, Date
?Login=sch                   # OK
?last=31&reverse=0

Quick filter            = Subject, Login
?Subject=dsd&Login=          # OK
?Login=sd&reverse=0

Quick filter            = Login, Subject
?Login=sd&Subject=           # OK
?Subject=sd&reverse=0
          icon2.gif   Re: reverse sort option does not work for quick filter, posted by Stefan Ritt on Thu Jun 16 22:37:06 2005 
I finally found some time to fix this problem. The fix is under CVS.
icon5.gif   Moving eLog from Server to Server..., posted by Charles Duncan on Sat Jun 11 02:29:01 2005 
I am moving my eLog system from one server to another.

I moved all my log books, my /etc/elog.conf, and /usr/share/elog/elog.pwd file. Did I miss anything?

The Logbooks come up fine on the eLog list, but when I try to access them I get invalid user name...

Do I have to do some sort of conversion to move the pwd file from one server to another?

Or should I try using the sync command for the move? does sync also move the pwd file??

-Charles-
    icon2.gif   Re: Moving eLog from Server to Server..., posted by Stefan Ritt on Mon Jun 13 17:45:47 2005 

Charles Duncan wrote:
I am moving my eLog system from one server to another.
I moved all my log books, my /etc/elog.conf, and /usr/share/elog/elog.pwd file. Did I miss anything?
The Logbooks come up fine on the eLog list, but when I try to access them I get invalid user name...
Do I have to do some sort of conversion to move the pwd file from one server to another?
Or should I try using the sync command for the move? does sync also move the pwd file??


Of course you have to start elogd after you copied all files over, but I presume you did that. The password file itself does not need any conversion, it should work on both hosts fine. Cloning an elog logbook (via the "-C <url>") flag, does copy the password file if you enter "yes" to the according question. Have you checked the file permission of the password file? Maybe the user name elogd is running under has no read access to it.
       icon2.gif   Re: Moving eLog from Server to Server..., posted by Charles Duncan on Mon Jun 13 18:45:45 2005 

Quote:

Stefan Ritt wrote:

Charles Duncan wrote:
I am moving my eLog system from one server to another.
I moved all my log books, my /etc/elog.conf, and /usr/share/elog/elog.pwd file. Did I miss anything?
The Logbooks come up fine on the eLog list, but when I try to access them I get invalid user name...
Do I have to do some sort of conversion to move the pwd file from one server to another?
Or should I try using the sync command for the move? does sync also move the pwd file??


Of course you have to start elogd after you copied all files over, but I presume you did that. The
password file itself does not need any conversion, it should work on both hosts fine. Cloning an elog logbook
(via the "-C <url>") flag, does copy the password file if you enter "yes" to the according question. Have you
checked the file permission of the password file? Maybe the user name elogd is running under has no read access
to it.


I reinstalled elog on the new server and ran the clone (via the "-C <url>"), wow that is really slick. But unfortunately my passwords and user data were not transfered. I did say 'Y' when prompted to transfer the password info.

I think my problem is that one server is running 2.5.9 (or 2.6.0 beta, unstable, Debian) and my new server is running 2.5.5.3 (stable, UBUNTU).

Are the password files not compatible between the 2 versions?

All my logbook entries appear to be there in full.

btw: I am back leveling to 2.5.5.3 because I lose my last column on every log book view.
          icon2.gif   Re: Moving eLog from Server to Server..., posted by Charles Duncan on Wed Jun 15 00:20:56 2005 

Charles Duncan wrote:

Quote:

Stefan Ritt wrote:

Charles Duncan wrote:
I am moving my eLog system from one server to another.
I moved all my log books, my /etc/elog.conf, and /usr/share/elog/elog.pwd file. Did I miss anything?
The Logbooks come up fine on the eLog list, but when I try to access them I get invalid user name...
Do I have to do some sort of conversion to move the pwd file from one server to another?
Or should I try using the sync command for the move? does sync also move the pwd file??


Of course you have to start elogd after you copied all files over, but I presume you did that. The
password file itself does not need any conversion, it should work on both hosts fine. Cloning an elog logbook
(via the "-C <url>") flag, does copy the password file if you enter "yes" to the according question. Have you
checked the file permission of the password file? Maybe the user name elogd is running under has no read access
to it.


I reinstalled elog on the new server and ran the clone (via the "-C <url>"), wow that is really slick. But unfortunately my passwords and user data were not transfered. I did say 'Y' when prompted to transfer the password info.

I think my problem is that one server is running 2.5.9 (or 2.6.0 beta, unstable, Debian) and my new server is running 2.5.5.3 (stable, UBUNTU).

Are the password files not compatible between the 2 versions?

All my logbook entries appear to be there in full.

btw: I am back leveling to 2.5.5.3 because I lose my last column on every log book view.


I wanted to add that the elog.pwd file did transfer when I used the "elogd -C <url>" command, but the passwords and accounts were not recognized. Also I edited my elog.conf file to contain the absolute address of my elog.pwd file.
             icon2.gif   Re: Moving eLog from Server to Server..., posted by Charles Duncan on Wed Jun 15 18:59:23 2005 

Charles Duncan wrote:

Charles Duncan wrote:

Quote:

Stefan Ritt wrote:

Charles Duncan wrote:
I am moving my eLog system from one server to another.
I moved all my log books, my /etc/elog.conf, and /usr/share/elog/elog.pwd file. Did I miss anything?
The Logbooks come up fine on the eLog list, but when I try to access them I get invalid user name...
Do I have to do some sort of conversion to move the pwd file from one server to another?
Or should I try using the sync command for the move? does sync also move the pwd file??


Of course you have to start elogd after you copied all files over, but I presume you did that. The
password file itself does not need any conversion, it should work on both hosts fine. Cloning an elog logbook
(via the "-C <url>") flag, does copy the password file if you enter "yes" to the according question. Have you
checked the file permission of the password file? Maybe the user name elogd is running under has no read access
to it.


I reinstalled elog on the new server and ran the clone (via the "-C <url>"), wow that is really slick. But unfortunately my passwords and user data were not transfered. I did say 'Y' when prompted to transfer the password info.

I think my problem is that one server is running 2.5.9 (or 2.6.0 beta, unstable, Debian) and my new server is running 2.5.5.3 (stable, UBUNTU).

Are the password files not compatible between the 2 versions?

All my logbook entries appear to be there in full.

btw: I am back leveling to 2.5.5.3 because I lose my last column on every log book view.


I wanted to add that the elog.pwd file did transfer when I used the "elogd -C <url>" command, but the passwords and accounts were not recognized. Also I edited my elog.conf file to contain the absolute address of my elog.pwd file.


I fixed it... I merely backed out of the XML format of the elog.pwd and reverted to common passwd format. Everyone can log in now... great product.
icon1.gif   Find seems to ignore Start Date, posted by Emiliano Gabrielli on Tue Jun 7 16:52:27 2005 
It seems that making a search in which one selects *only* a start date *and* a "last" number of days
does not works correctly ..
Elog infact simply ignores the start date, showing the last N-days entries ..
This is a bug IMHO, and prevents me to include a quick filter for user, making easy to select a particular year/week in a JS calendar and than using this date as the start date for the logbook ...

here is an example: http://midas.psi.ch/elogs/Forum/?mode=threaded&reverse=1&npp=8&ma=6&da=14&ya=2004&last=7

If one specify *also* an "end date" the beaviour is correct..
    icon1.gif   Re: Find seems to ignore Start Date, posted by Emiliano Gabrielli on Tue Jun 7 17:59:54 2005 

Emiliano Gabrielli wrote:
It seems that making a search in which one selects *only* a start date *and* a "last" number of days
does not works correctly ..
Elog infact simply ignores the start date, showing the last N-days entries ..
This is a bug IMHO, and prevents me to include a quick filter for user, making easy to select a particular year/week in a JS calendar and than using this date as the start date for the logbook ...

here is an example: http://midas.psi.ch/elogs/Forum/?mode=threaded&reverse=1&npp=8&ma=6&da=14&ya=2004&last=7

If one specify *also* an "end date" the beaviour is correct..



uhm ... maybe I have realized ...

it's End Date to be used for this task... right??

If it is (as it seems) the search form is quite confusing .. as the "/ Last " select box it's just after the "start date" ...
icon4.gif   elog & firefox pipelining, posted by Emiliano Gabrielli on Mon Jun 6 12:28:21 2005 
Having the Firefox pipelining feature enabled makes elog unable to correctly show avery attachment in the full view when a quite large number of them is present..
disabling pipelining makes all works fine again
    icon4.gif   Re: elog & firefox pipelining, posted by Stefan Ritt on Mon Jun 6 15:17:50 2005 

Emiliano Gabrielli wrote:
Having the Firefox pipelining feature enabled makes elog unable to correctly show avery attachment in the full view when a quite large number of them is present..
disabling pipelining makes all works fine again


As is said:

Pipelining is an experimental feature, designed to improve page-load performance, that is unfortunately not well supported by some web servers and proxies.

So what do you expect Tongue

I have not checked in detail, but it seems that the browser fires off several requests in parallel, one for each image. This can only be handled by a multi-threaded server, which elog is not (yet). What is more an issue for elog in relation to multi-threading is that one long request blocks all other users. So if I do a synchronize for example from home, the server can be nonresponsive for a minute or two. I have some plans for making it multi-threaded, but as you can imagine this is not so simple to do in a portable way.
       icon12.gif   Re: elog & firefox pipelining, posted by Emiliano Gabrielli on Tue Jun 7 13:12:25 2005 

Stefan Ritt wrote:

Emiliano Gabrielli wrote:
Having the Firefox pipelining feature enabled makes elog unable to correctly show avery attachment in the full view when a quite large number of them is present..
disabling pipelining makes all works fine again


As is said:

Pipelining is an experimental feature, designed to improve page-load performance, that is unfortunately not well supported by some web servers and proxies.

So what do you expect Tongue

I have not checked in detail, but it seems that the browser fires off several requests in parallel, one for each image. This can only be handled by a multi-threaded server, which elog is not (yet). What is more an issue for elog in relation to multi-threading is that one long request blocks all other users. So if I do a synchronize for example from home, the server can be nonresponsive for a minute or two. I have some plans for making it multi-threaded, but as you can imagine this is not so simple to do in a portable way.


You are right .. I'll wait the m-t support then Smile ghghgh
icon4.gif   shell exec not working, posted by Emiliano Gabrielli on Mon Jun 6 12:25:53 2005 
It seems that, since Fri 2005-06-03, 12:50 almost, the shell exec feature is not invoked anymore.
the -x flag is present in the command line and the elog.cfg Parameters are present both for edit and for insert..
I'm not disabling shell exec by the checkbox

the dummy-level log in syslog does not show *anything* about shell exec.
    icon4.gif   Re: shell exec not working, posted by Emiliano Gabrielli on Mon Jun 6 12:43:48 2005 

Emiliano Gabrielli wrote:
It seems that, since Fri 2005-06-03, 12:50 almost, the shell exec feature is not invoked anymore.
the -x flag is present in the command line and the elog.cfg Parameters are present both for edit and for insert..
I'm not disabling shell exec by the checkbox

the dummy-level log in syslog does not show *anything* about shell exec.


oh my @#[#@ .. sorry stefan, my bad ... for some reason the make_thumbs script was not +x ..

Is it possible to check the executability of the script in elog and eventually tell about this in syslog ? Tongue
icon4.gif   password encryption, posted by Alex H on Fri May 20 14:40:12 2005 password.gif
Hi Stefan,

I have found a little problem with elog. I'am using ELOG V2.5.8-6. When I'am on the logon page,
I type my Login and password and hit "submit", in the bottom of IE, we can show my password without encryption, it can be dangerous. I have made a screenshot to explain my problem better.
Could you fix it for the next release ?
Thanks a lot.
Alex
    icon4.gif   Re: password encryption, posted by Stefan Ritt on Fri May 27 14:48:05 2005 

Alex H wrote:
Hi Stefan,

I have found a little problem with elog. I'am using ELOG V2.5.8-6. When I'am on the logon page,
I type my Login and password and hit "submit", in the bottom of IE, we can show my password without encryption, it can be dangerous. I have made a screenshot to explain my problem better.
Could you fix it for the next release ?
Thanks a lot.
Alex


Unfortunately there is no real way around that. If a password is entered into a text box, it is always transferred in plain text (which means that in security-sensive installations one should always use SSL together with elog). I encrypt it on the server side and do an immediate redirect which "hided" the plain password, but if your connection is slow, you might see it for a moment. Unless nobody has a clever idea of how to prevent this, we're out of luck.
       icon12.gif   Re: password encryption, posted by Alex H on Mon May 30 10:01:14 2005 

Stefan Ritt wrote:

Alex H wrote:
Hi Stefan,

I have found a little problem with elog. I'am using ELOG V2.5.8-6. When I'am on the logon page,
I type my Login and password and hit "submit", in the bottom of IE, we can show my password without encryption, it can be dangerous. I have made a screenshot to explain my problem better.
Could you fix it for the next release ?
Thanks a lot.
Alex


Unfortunately there is no real way around that. If a password is entered into a text box, it is always transferred in plain text (which means that in security-sensive installations one should always use SSL together with elog). I encrypt it on the server side and do an immediate redirect which "hided" the plain password, but if your connection is slow, you might see it for a moment. Unless nobody has a clever idea of how to prevent this, we're out of luck.


Oki Thanks for the answer Smile.

Alex
    icon2.gif   Re: password encryption, posted by Gary Clayson on Mon May 30 19:18:34 2005 
Hello Alex and Stefan,

I know of only one way to "hide" the text of the status bar in a web browser;
use JavaScript - specifically the status method (as in the following example):

<!-- the following goes in the body of the document, perhaps in a link. -->

<!-- sample link -->
<a href="javascript://place link url here"
onMouseOver="window.status='Status Bar Text Goes Here'; return true">Link Text Here</a>

<!-- place the following script in the head of the document -->
<script language="JavaScript" type="text/javascript"><!--
window.defaultStatus="Default Status Bar Text Here";
--></script>

Of course the above only works in those browsers that support javascripting,
but it is one way to hide the actual text of links from the user.
Hopefully this helps you!

Gary Clayson


Alex H wrote:
Hi Stefan,

I have found a little problem with elog. I'am using ELOG V2.5.8-6. When I'am on the logon page,
I type my Login and password and hit "submit", in the bottom of IE, we can show my password without encryption, it can be dangerous. I have made a screenshot to explain my problem better.
Could you fix it for the next release ?
Thanks a lot.
Alex
       icon2.gif   Re: password encryption, posted by Emiliano Gabrielli on Mon May 30 19:56:01 2005 

Gary Clayson wrote:
Hello Alex and Stefan,

I know of only one way to "hide" the text of the status bar in a web browser;
use JavaScript - specifically the status method (as in the following example):

<!-- the following goes in the body of the document, perhaps in a link. -->

<!-- sample link -->
<a href="javascript://place link url here"
onMouseOver="window.status='Status Bar Text Goes Here'; return true">Link Text Here</a>

<!-- place the following script in the head of the document -->
<script language="JavaScript" type="text/javascript"><!--
window.defaultStatus="Default Status Bar Text Here";
--></script>

Of course the above only works in those browsers that support javascripting,
but it is one way to hide the actual text of links from the user.
Hopefully this helps you!

Gary Clayson


Alex H wrote:
Hi Stefan,

I have found a little problem with elog. I'am using ELOG V2.5.8-6. When I'am on the logon page,
I type my Login and password and hit "submit", in the bottom of IE, we can show my password without encryption, it can be dangerous. I have made a screenshot to explain my problem better.
Could you fix it for the next release ?
Thanks a lot.
Alex


I don't have double checked .. but .. why we need to pass the sensible information in the Query String ??
Are you sure that putting it in an hidden field (and eventualli using a GET methon in the <form>-tag) can't be a solution?
          icon2.gif   Re: password encryption, posted by Stefan Ritt on Mon May 30 20:16:11 2005 

Emiliano Gabrielli wrote:

I don't have double checked .. but .. why we need to pass the sensible information in the Query String ??
Are you sure that putting it in an hidden field (and eventualli using a GET methon in the <form>-tag) can't be a solution?


Hidden means only these fields are not shown in the form, but they are added to the URL in the same way as non-hidden fields. But I got another idea: I will try to use a POST form instead of the GET form. Using the POST method, fields are attached to the request and not present in the URL. Hope this will work. When I find some time to work on it I will let you know.
             icon14.gif   Re: password encryption, posted by Alex H on Tue May 31 09:07:37 2005 
Thanks Stefan 8)
    icon2.gif   Re: password encryption, posted by Stefan Ritt on Sat Jun 4 14:00:17 2005 

Alex H wrote:
I have found a little problem with elog. I'am using ELOG V2.5.8-6. When I'am on the logon page,
I type my Login and password and hit "submit", in the bottom of IE, we can show my password without encryption, it can be dangerous. I have made a screenshot to explain my problem better.
Could you fix it for the next release ?
Thanks a lot.
Alex


I switched the login page to the HTTP "POST" method, where arguments are not passed in the URL.

The new version is under CVS. Can you try if the behaviour is better now? I upgraded also the ELOG forum, so you can try there as well.
icon4.gif   Logbook locking issue, posted by Steve Jones on Tue May 17 21:38:36 2005 
Stefan, any ideas on this problem?


Quote:
Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.

SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.

PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset".
    icon4.gif   Re: Logbook locking issue, posted by Steve Jones on Wed Jun 1 16:14:22 2005 

Steve Jones wrote:
Stefan, any ideas on this problem?


Quote:
Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.

SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.

PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset".


Hmmm, I don't seem to be seeing any responses - is email being generated?
    icon4.gif   Re: Logbook locking issue, posted by Stefan Ritt on Wed Jun 1 16:33:54 2005 
Sorry about my unusual slow response, but I'm pretty busy these days. I hope I will be able to address this problem in a two weeks from now.


Steve Jones wrote:
Stefan, any ideas on this problem?


Quote:
Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.

SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.

PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset".
       icon6.gif   Re: Logbook locking issue, posted by Steve Jones on Wed Jun 1 21:00:01 2005 

Steve Jones wrote:
Stefan, not a problem. ITMT, any idea how I can manually clear this "lock"? Is it embedded in the logbook itself?


Stefan Ritt wrote:
Sorry about my unusual slow response, but I'm pretty busy these days. I hope I will be able to address this problem in a two weeks from now.


Steve Jones wrote:
Stefan, any ideas on this problem?


Quote:
Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.

SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.

PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset".
          icon2.gif   Re: Logbook locking issue, posted by Stefan Ritt on Sat Jun 4 13:06:08 2005 

Steve Jones wrote:
Stefan, not a problem. ITMT, any idea how I can manually clear this "lock"? Is it embedded in the logbook itself?


I would recommend to remove the Restrict edit time = 0.5 temporarily from your config file, then edit this entry, the clicking Back instead of Submit (since you don't really want to edit the entry). This removes the lock, and you can re-enable the Restrict edit time = 0.5 in the config file.


Quote:
Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.

SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.

PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset".


I fixed this problem and committed it to CVS. It will be contained in the next release.
icon1.gif   Incorrect Display, posted by David Spindler on Sat May 21 15:05:23 2005 capture-firefox-1.03.JPG
I hope this is the correct place for an apparent bug report. The display is incorrect except when displaying a particular entry. I just downloaded 2.6.0-beta thinking I was getting 2.5.9. Nice surprise. The elcode (bbcode? ) is a great idea, but the display, when showing the main screen of a logbook does not have the correct fields showing in the correct places. I will attach two screen captures for illustraton. Never mind, I guess not. It is not letting me upload the screen captures. On the main screen, for example, my field contents for "Route" appear in the "Text" field. But when on the specific entry screen, these field contents are in the correct field. I will be glad to eamil the screen captures, if anyone wants.

I am running Firefox 1.0.3 (same results with IE 6, BTW), on a WinXP OS (sorry fellows, but I am still in process of learning Linux, so I have not tried this version of elog on it, yet), on a Gateway 2.2 GHZ, 1 GB RAM PC.


BTW, I love elog and have it running at work. It is being used extensively.
    icon1.gif   Re: Incorrect Display, posted by David Spindler on Sat May 21 15:23:08 2005 capture-firefox-1.03-log-entry.JPG

David Spindler wrote:
I hope this is the correct place for an apparent bug report. The display is incorrect except when displaying a particular entry. I just downloaded 2.6.0-beta thinking I was getting 2.5.9. Nice surprise. The elcode (bbcode? ) is a great idea, but the display, when showing the main screen of a logbook does not have the correct fields showing in the correct places. I will attach two screen captures for illustraton. Never mind, I guess not. It is not letting me upload the screen captures. On the main screen, for example, my field contents for "Route" appear in the "Text" field. But when on the specific entry screen, these field contents are in the correct field. I will be glad to eamil the screen captures, if anyone wants.

I am running Firefox 1.0.3 (same results with IE 6, BTW), on a WinXP OS (sorry fellows, but I am still in process of learning Linux, so I have not tried this version of elog on it, yet), on a Gateway 2.2 GHZ, 1 GB RAM PC.


BTW, I love elog and have it running at work. It is being used extensively.


I guess it did upload. Here is the other screen capture.

BTW, I received the following message upon submitting my last post:
Quote:
"Error sending Email via "mailsend.psi.ch": malformed address: <>"
       icon1.gif   Re: Incorrect Display, posted by David Spindler on Mon May 23 17:47:24 2005 
Never mind. I figured it out. I used two fields (date and time) that are automatically placed in elog. It messed up the spacing, altough what was puzzling was that it displayed correctly on the entry itself, but not the list. Anyway, I renamed the date and time to another name and it is ok.

Thanks, anyway. Keep up the good work.


David Spindler wrote:

David Spindler wrote:
I hope this is the correct place for an apparent bug report. The display is incorrect except when displaying a particular entry. I just downloaded 2.6.0-beta thinking I was getting 2.5.9. Nice surprise. The elcode (bbcode? ) is a great idea, but the display, when showing the main screen of a logbook does not have the correct fields showing in the correct places. I will attach two screen captures for illustraton. Never mind, I guess not. It is not letting me upload the screen captures. On the main screen, for example, my field contents for "Route" appear in the "Text" field. But when on the specific entry screen, these field contents are in the correct field. I will be glad to eamil the screen captures, if anyone wants.

I am running Firefox 1.0.3 (same results with IE 6, BTW), on a WinXP OS (sorry fellows, but I am still in process of learning Linux, so I have not tried this version of elog on it, yet), on a Gateway 2.2 GHZ, 1 GB RAM PC.


BTW, I love elog and have it running at work. It is being used extensively.


I guess it did upload. Here is the other screen capture.

BTW, I received the following message upon submitting my last post:
Quote:
"Error sending Email via "mailsend.psi.ch": malformed address: <>"
          icon1.gif   Re: Incorrect Display, posted by Geoffrey Carman on Fri Jun 3 17:34:44 2005 

David Spindler wrote:

BTW, I love elog and have it running at work. It is being used extensively.


We just did the 2.60 beta upgrade, and now our pre-existing logbooks, with a
List Display = Name, Author, Date for example will only show the first two fields.

It seems like Elog is dropping the last attribute in the List Display line.

We can 'fix' it by making it say:
List Display = Name, Author, Date, Date
so that it drops the second Date, but that is a bad workaround.

Anyone else seeing this?

Elog 2.60 beta on Linux, Firefox 1.04 as the client. Or IE fully patched on WinXP SP2.

PS: Love Elog at work here too! Truly has made our documentation way better. And RSS feeds of the logbooks is just wonderful.
             icon1.gif   Re: Incorrect Display, posted by Emiliano Gabrielli on Fri Jun 3 18:02:25 2005 

Geoffrey Carman wrote:

David Spindler wrote:

BTW, I love elog and have it running at work. It is being used extensively.


We just did the 2.60 beta upgrade, and now our pre-existing logbooks, with a
List Display = Name, Author, Date for example will only show the first two fields.

It seems like Elog is dropping the last attribute in the List Display line.

We can 'fix' it by making it say:
List Display = Name, Author, Date, Date
so that it drops the second Date, but that is a bad workaround.

Anyone else seeing this?

Elog 2.60 beta on Linux, Firefox 1.04 as the client. Or IE fully patched on WinXP SP2.

PS: Love Elog at work here too! Truly has made our documentation way better. And RSS feeds of the logbooks is just wonderful.


I just reported it to Stefan last week ... it's the "pippo-bug" Smile I called it this way becouse you can put anything you want as garbage Attribute to go around the bug .. I temporary corrected my elogs configs addig a ", pippo" to every "List Display" line ...
                icon2.gif   Re: Incorrect Display, posted by Stefan Ritt on Sat Jun 4 10:59:52 2005 
I finally found some time to fix the pippo-bug Wink.

It had to do with the request that one can turn on and off the summary lines of the text body in Guest list display. So if this option does not contain Text, the text summary is not shown for guest access, but only for registered access. This modification had the side effect that one column was dropped on the non-guest access.
ELOG V3.1.5-3fb85fa6