Hi,

When I upgrade from build 2278 to  2282 the thread view changes when performing searches: The thread children are not indented and there are no "thread icons" in the search list (e.g. like the read right arrow for replies).

On the forum site I also note that the thread view is not indented when performing searches.

Does anyone have an idea ?

Soren

This seems to be a bug. I reproduced it with a different browser (Opera) with the default ELOG configuration. When I do Find and select Display Threads I have the message icons but the layout is not correct. Also, all message icons are of the "reply" type even if they are new threads.

This concerns only the latest build 2282.

Soren

That's not a bug, that's a feature

But honestly, this feature was requested recently and implemented. See https://midas.psi.ch/elogs/Forum/66670. So when searching, the thread organization is broken up and messages are treated independently. If you want to see the thread for a certain entry in you search result page, click on that entry and you will see the full thread above the entry. 

That sounds fine but I think there is a problem with rendering under Opera. I enclose a screen shot: There is too much white space in the lines, it seems $

The problem only appears in Find

Soren

 I just tried myself with V10.50, and things work fine, even in the find page:

Can you try on the forum, just to check if it's specific to your configuration?

 Thanks. The Forum is fine. The problem is - apparently - specific to my installation. The white space origins in long sequences of "&nbsp" (repeated); in the lines in Find.

Let me re-install with the latest version and see if I can solve it like that.

Soren

 I have re-installed the latest, fastest, smartest, brightest version. And it all works perfectly! Thanks a lot for your help.

Soren

 Everything is fine. But my users do not like that the threads are broken into individual entries and not shown as full threads as before. So I am stuck with the "old" version. This is probably asking for too much but would it be difficult to have a flag to specify if you want to benefit from the new behaviour or keep pre-2282 behaviour (with its inconvenience which led to the presentation change). It could even be a compile tag flag, if it just me (well, my users) who is asking for this.

Soren

Hi,

I'm trying to implement top groups and started with the sample configuration shown in the 'Syntax of elogd.cfg' chapter of the documentation. But now I'm facing a problem with the links in the logbook selection page.

Here's my group configuration:

Group Linux PCs = Red Hat, Debian, Mandrake
Group Windows PCs = NT, XP

Top group engineering = Linux PCs, Windows PCs
Top group administration = Employees, Purchases
Show top groups = 1
 

The selection page for the top groups is displayed correctly, but the URL for the groups beneath the top group is incorrect. The URL for the Linux PCs group for instance is http://localhost:8080/engineering/engineering/ . The URLs for the logbooks within the Linux PCs groups is correct (e.g. http://localhost:8080/Debian/)

Has anybody an idea what's going wrong in y configuration?

Bertram

Thanks for reporting this bug. I fixed it in the intermediate release 278-4 which is ready for download. 

 Thanks for the quick bug fix.

Bertram

Hi,

This little logbook has a problem:

------------------------

Attributes = Author, Category, Type, Subject, Number

Type Number = numeric

Options Category = General{1}
{1} Options Type = Routine

------------------------

(it was of course more complicated to start with).

When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.

To avoid the problem, I just comment out the line "Type Number ... "

Is this a bug ?

Thanks for your time

Soren

(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the  problem).

 To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"

It was a mistake not to include the "global" settings in this bug report.

What probably happens is that something in the French translation (accents ?) disturbs the java scripting.

Soren

 To use "Language = french" it is necessary to remove or substitute the accent character ' with something else in eloglang.french and then the Javascript code works again.

Soren

Indeed it was the JavaScript line

if (document.form1.Number.value != '- garder les valeurs d'origine -') {

which caused the trouble.  The "'" character closed the string '- garder les valeurs d', which caused an exception. I changed it to

if (document.form1.Number.value != "- garder les valeurs d'origine -") {

and now it should work fine.

 Thanks a lot for changing that. Now French should work as well.

Soren

I am using eLog ELOG V2.6.1-1681 which has 7 log books under 8 categories. Out of 7 log books, 2 are daily used. It happened that two weeks back. I modified information on two log books which were not used for quite longtime. Hence using CONFIG, I updated these log books, changing text etc. After that eLog in general started giving error. Any time when we click SUBMIT button in any log book, eLog shows page not found. That submit crashes eLog and as a result elogd service stops. Restarting elogd service, eLog operation comes back and the log which I submitted was actualy saved. Difficulty is that this problem is happening with every single submit action. 

I searched forum and learnt that upgrading eLog to newest version 2.7.8 will solve this problem. Upgrade created more problems, I was not able to open any log, authentication was not accepted. I restored that backup and went back to previous version. eLog started working but with submit error.

If any one can help me in fixing this problem

I propose that you get 2.7.8 working. If the authentication fails, try do do password recovery, or recreated the accounts. 

 Thanks for the reply. I found problem with existing version. I opened log book group  without  opening log book details in configuration, that is why at submitting or opening elog was not able to find log book for that group and was getting lost.

Regarding moving to 2.7.8, I want to know that in this new version file location for pwd and log books will remain same or are changed. If changed then I have to change location manually. Also how I can perform password recovery.

Is it possible to create a drop down menu for the last 3 days of log entries. Currently we have the last day, month, 3 month, etc.

Reason being, after a weekend most people would like to view the log entries for the last three days. Can anyone help me out here?

It is a good point, and surprised that this particular number of days was overlooked.

It only needs four lines added into elogd.c to achieve this.  Even with my notorious 
c coding, I did it first time, but as I'm on linux, not a great help for you.  Indeed, 
any other arbitary number of days could be added in, if you have the sources and means 
to recompile.

I think windows versions are only updated on version number, not svn number, so it will 
require a request to the great man himself(*) to produce a new version for windows.

(*)Hint; Stefan likes the occasional beer.


<p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
<tbody>
<tr>
<td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Paul O'Shaughnessy
wrote:</td></tr>
<tr>
<td cellpadding="10px" style="background-color:#FFFFB0;"><p>Is it possible to create a drop down menu for the
last 3 days of log entries. Currently we have the last day, month, 3 month, etc.</p>
<p>Reason being, after a weekend most people would like to view the log entries&nbsp;for the last three days.
Can anyone help me out here?</p></td>
</tr>
</tbody>
</table>
</p><p> </p>

> It is a good point, and surprised that this particular number of days was overlooked.
> 
> It only needs four lines added into elogd.c to achieve this.  Even with my notorious 
> c coding, I did it first time, but as I'm on linux, not a great help for you.  Indeed, 
> any other arbitary number of days could be added in, if you have the sources and means 
> to recompile.

David send me his modification and I put it into the main source code, so it will be contained in the next Windows 
version.

> I think windows versions are only updated on version number, not svn number, so it will 
> require a request to the great man himself(*) to produce a new version for windows.
>
> (*)Hint; Stefan likes the occasional beer.

Yepp ;-)

> David send me his modification and I put it into the main source code, so it will be contained in the next Windows 
> version.

I made an interim 2.7.8-3 version which contains the fix and can be downloaded from the web site.

Hi Stefan,

I have noticed a problem when closing multiple log entries i.e entries which have more than 10 threads. I use Select -> Click the box that appears next to the thread I wish to close -> Edit.

As soon as I click on Edit the elogd service crashes and Windows displays an error message window. The only work around has been opening up all the threads and individually changing the "Status" to Closed. 

Forgive me if this issue has been raised before but I have looked throughout the Forum and could not see anyone experiencing the same problem.

Thanks

Cliff

Unfortunately I cannot reproduce your error. In my test set-up it works fine, so it might be related to your configuration. Can you send me your config file, a zip with the needed logbook entries (xxxxxxa.log files), and a recipe what to click exactly in what order.

 This programing have stoped working, I guess after last update.

Elog is running on Solaris.

Ulf Helmersson

Options Type = Journal Article{1}, Proceeding Article{2}, Book chapter{3}, Book{4}, Patent{5}

{1} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Abbrivated journal name, Volume, First page, Year, Elsevier format, AIP/APS format, IOP format

{2} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Conference name, Place, Country, First page, Year, Month.Days, Volume, Elsevier format Proceeding

{3} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Book Title, Editors, Publisher, Place, First page, Year, Elsevier format Book chapter

{4} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Publisher, Place, First page, Year, Elsevier format Book, IOP format Book

{5} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Patent number, Year, First page, Elsevier format Patent

The option

Show Attributes =

has been changed to

Show Attributes Edit =

to distinguish between normal entry display an edit mask. So please adjust your configuration file and everything will be fine again.

Hi,

I have been trying to get the display mode into threaded by default, it does not work on any of my logbooks. I saw related threads in this forum but none gave me a solution (unless the 2.7.8-2282 is available for download).

Here is a simple example which i can not get working.

thanks for your help

FX

The display mode is taken from the configuration option "Display mode = ..." only the very first time a users accesses a logbook. When the user switches to any other mode (summary, full) by clicking on the according menu option, the new mode is stored in a cookie in the browser and overrides the "Display mode = ..." setting. Maybe that is what you see.