Since I'n not a programmer I's like to be very carefulls with bug  
reports, but after testing for a while, I belive this my be a bug or  
something else:  
  
I have 2 systems running ELOG 2.5.1:   
1. uSE Linux 8.2, KDE 3.2 = NO problems at all! ELOG work's in every  
function quiet well!  
2. The Internet Server (of my friend): Windows 2003 Server, All MS paches  
installed, Running IIS 6.0 Port 80) and ELOG 2.5.1 (Port 8080) under  
FireDeamon 1.6GA (actual release) as a Service (Deamon).   
  
Problem under Win 2k3:  
This works very well, even with several users on the system and on ELOG  
as long as there is not msg. threaded! Is a Msg. Treaded ELOG produces  
the msg. showen in the attached Jepg-file below on Win 2k3.  
The problem occurs as soon as Elog would change to the threaded display 
or by clicking "Repaly" in the menu. Rights etc. are aleady checked on 
the file system and are looking well. Everithing will work well as 
nothing is thraded or testing locally under Linunx. 
 
Does anybody  
have an idea??? It my by a bog on Elog as well as from Microsoft or a  
problem produced by a dummy user (me...!). Since Linux don't have the  
problem and the same cfg-file and log-files are working well if I don't  
use mode=threaded as well as Display mode = threaded I believe it my be a  
realchance not to be the personal factor of the dummy user...   
  
ThankX for every hint!  
  
  

Good Morning,

I would like to limit the ability to edit certain attributes in an ELOG logbook, depending on the user who is logged in.  I.e. if "guest" or a standard "login user" is logged in, I only want to allow the user to edit "attribute1" & "attribute2" of say, 5 attributes.  However, if an Admin user or specific user, say "Terry" or "Bob" is logged in, I want to allow ALL 5 attributes to be editable.  To expand on this, I may want to even limit the visibility of the attributes as well.

I've read though "Condition Attributes" section of the help page, but it is not clear to me how/if I can do this?  Is that section even relevant to what I want to accomplish?

Can anyone provide some guidance?

Thank you for your time & help!

Sincerely,

Terry

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined.  (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.)  When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise.

Hi there. Just started recently set up the application and think its very usable and easily configured - great stuff

I'm looking to roll it out to the masses but have a slight logistical problem in that we work on 2 separate networks - NET1 with connection to the internet, and NET2 physically isolated from NET1 and the internet.

It would be desirable to allow users to add/update/delete logs from both NET1 and NET2 with periodic synchronisation.

I believe the mirroring facility is what should be used, and think the following setup and synchronisation steps may be workable:

Setup:

• elog installed on node of NET1
• elog installed on 2 nodes of NET2
• elog server running on NET1 and node1 of NET2 both using a common elogd.cfg

Performing Synchronisation:

1. Stop the server on NET1
2. copy logbook directories from NET1 to node2 of NET2
3. start server on node2 of NET2 using the -M option
4. once above complete, copy logbook directories from node 2 NET2 to NET1
5. Start the server on NET1

Am I on the right track?

Would very much appreciate your comments and advice on the above.

Cheers Dougie

I couldn't find an obvious solution to the problem. I'd like to suppress email

notification to the author of a message. I've had some people complaining

that when they use elog they don't want to get an email about what they wrote

since they wrote it.

Is it possible?

Regards,

Mike

The way I have ELOG configured it sends an email to supervisors based on which "Department " (attribute) was selected. Problem is that when the supervisor replies the department

is still selected and it sends a second email to the supervisor. Is there any way to supress the emails (automatically) on "Reply"?