I'm interested using elog for a lab notebook.  Once entries have been
entered they cannot be changed/edited.
Is it possible for elog to be setup to support something like this?  A write
only mode?

> I'm interested using elog for a lab notebook.  Once entries have been
> entered they cannot be changed/edited.
> Is it possible for elog to be setup to support something like this?  A write
> only mode?

What you need is an entry in the elogd.cfg file:

Manu commands = Back, New, Reply, Find, Config, Logout, Help

As you see, the "Edit" and "Delete" commands are missing here and therefore 
do not get displayed. So you can enter a message with "New", but you cannot 
change it afterwards.

Does this truly disable the edit command or just hide it?

> > I'm interested using elog for a lab notebook.  Once entries have been
> > entered they cannot be changed/edited.
> > Is it possible for elog to be setup to support something like this?  A write
> > only mode?
> 
> What you need is an entry in the elogd.cfg file:
> 
> Manu commands = Back, New, Reply, Find, Config, Logout, Help
> 
> As you see, the "Edit" and "Delete" commands are missing here and therefore 
> do not get displayed. So you can enter a message with "New", but you cannot 
> change it afterwards.

> Does this truly disable the edit command or just hide it?

You're right! In some earlier versions, it did disable it, but in 2.2.5 it 
just hides it. I fixed that bug and from 2.3.0 on it will really disable 
that command again, such that if someone enters manually

http://midas.psi.ch/elogdemo/Forum/202?cmd=Edit

will produce and error if the command is not in the menu list.

do not use confused name in attributes
**************************************
like
Attributes Type, Type2
the info on Type2 will be placed in the Type also
see attachment 1

Never use confused name like '
Attributes PC_Memory, Memory

If Stephan need more info I can send a exemple of the logbooks
Etienne

> do not use confused name in attributes
> **************************************
> like
> Attributes Type, Type2
> the info on Type2 will be placed in the Type also
> see attachment 1
> 
> Never use confused name like '
> Attributes PC_Memory, Memory

I acknowledge the problem. It had to do with the fact that for checkbox 
options, the first checkbox is submitted in the above case as "Type0", the 
second as "Type1", and the third as "Type2" which conficts with the other 
attribute. I fixed that and use now "Type#0" and so on which should be fine.

The fix will be included in V2.2.6.

Stefan

propose to put 
[Submit] [Back] [Submit & Notify] button on top/bottom

new parameter 'shell option' 

[test]
...
Attributes = NotifyMode, Param1....Param10, Adresse, Subject, ...
Options NotifyMode = mail, SMS, Fax, printer...

; this command will invoque a shell command  
; example       
ShellCommand = <my shell command> parameters ...

like in WINDOWS 2000
ShellCommand = START.EXE notify.bat $NotifyMode $Param1, $Param2, $Param3
; in this case no necessity to modify the C source
; in windows I suggest the start.exe with a exit command
; so no necessary to wait the return code from the shell

I put this on the wish list.

- Stefan

From Version 2.2.5 on, the configuration file entries

User = ...
Group = ...

have been changed to

Usr = ...
Grp = ...

in order not to conflict with the new "Group = ..." option which is used by 
hierarchical logbooks.

> From Version 2.2.5 on, the configuration file entries
> 
> User = ...
> Group = ...
> 
> have been changed to
> 
> Usr = ...
> Grp = ...
> 
> in order not to conflict with the new "Group = ..." option which is used by 
> hierarchical logbooks.

not really a bug
works very fine just remarks : with this example
Group Phone & Adress = Whois, Qui_est_Qui
Group Extranet = Aide, Promos_Clients, Qui_est_Qui, Joke

[whois] is a intranet section for us : [qui_est_qui] is public
I add   'copy to = Qui_est_qui' 
so extranet or public can acces to limited information
just remove the attributes and guest user can see only limited info
see example below

small problem : 
****************
Logbook Tabs = 0  in the guest logbook will close the group header
may be create a parameter to solve ?
GroupGuest Extranet = ....

;--------------------  intranet info----------------
[Whois]
Comment = MBA & his Partner all your personal info must be here
Subdir = whoiswho
Menu commands = Back, New, Edit, Find, Help, Copy to
Attributes = Partner, AsTo, YourName, SurName, email1, email2, hotmail,Yahoo, 
GSMmail, Nickname, phone, fax, portable , home , adress, Remarks, birthday, 
QuadroUser, Function, Division
MOptions Partner = Mba, MbaCZ, BusinessCom, Edipax, Ibi, Other
Required Attributes = Parner, CodeName, YourName, email1, phone, birthday
Preset GSMmail = ???@proximus.be
Preset portable = 00 32
Copy to = Qui_est_Qui

Quick filter = Partner, Date, AsTo

;------------------------------------
[Qui_est_Qui]
Comment = MBA et ses collaborateurs à votre service 
Subdir = logbooks/whoiswho/public
Attributes = Partner, YourName, SurName, phone, fax ,portable ,email1 , 
hotmail, GSMmail, Nickname,  Remarks,Function, Division
MOptions Partner = Mba
Date format = %d/%m/%y
Quick filter = Date

;--------------------pas d'acces au autre menu no acces to main menu
Logbook Tabs = 0
Guest menu commands = Find
Guest find menu commands = Find
;-------------- rectriction on edit if not put  1  
Restrict edit = 1
Display mode = full
Help URL = http://www.mba.be







 

> small problem : 
> ****************
> Logbook Tabs = 0  in the guest logbook will close the group header
> may be create a parameter to solve ?
> GroupGuest Extranet = ....

What I would recommend in that case is to run two copies of elogd in 
parallel, one for the public and one for the private section. They can even 
run on differnt ports so the firewall can block the private section. If the 
private logbooks are not defined in the public elogd, they don't show up in 
the logbook tabs, so only the publick logbook tabs are seen. Please note 
that two elogd daemons should not have concurrent write access to the same 
logbook, since there is not locking and the logbook could get messed up that 
way. So only one elogd should have write access to any logbook.

- Stefan

Was wondering if there were any tweaks/suggestions for improving the 
logbooks responsiviness.  Our logbook was started 31 July 01.  Since that 
time we have went from 1 logbook to 4 logbooks.  Logbook 1 having 2651 
entries, logbook 2 having 300 entries, and the last 2 are new logbooks, so 
only a few entries.

When user launches the logbook website, it takes considerable time to bring 
the site up.  It seems to be directly related to the number of entries in 
the logbook.  If I set up a dummy site with a couple logbooks and only a 
few entries, the logbook is very fast coming up as well as saving entries.

Another thing that seems to slow the site down, is the number of users in 
the elog notification list (those who've subscribed).  When you save a log 
entry, it takes around 30sec or longer for it to actually complete the 
save.  If I remove the list of users from the notification list and just 
have a few, the save is very fast.


Thanks in advance,

Eric

> Was wondering if there were any tweaks/suggestions for improving the 
> logbooks responsiviness.  Our logbook was started 31 July 01.  Since that 
> time we have went from 1 logbook to 4 logbooks.  Logbook 1 having 2651 
> entries, logbook 2 having 300 entries, and the last 2 are new logbooks, so 
> only a few entries.
> 
> When user launches the logbook website, it takes considerable time to bring 
> the site up.  It seems to be directly related to the number of entries in 
> the logbook.  If I set up a dummy site with a couple logbooks and only a 
> few entries, the logbook is very fast coming up as well as saving entries.
> 
> Another thing that seems to slow the site down, is the number of users in 
> the elog notification list (those who've subscribed).  When you save a log 
> entry, it takes around 30sec or longer for it to actually complete the 
> save.  If I remove the list of users from the notification list and just 
> have a few, the save is very fast.
> 
> 
> Thanks in advance,
> 
> Eric

2600 entries is too much for this application as it load the all files 
in computer memory
expand the server memory
Are you running on linux or Windows ? I suggest linux (faster)
We are working on the C source to move all data from flat to database like 
SQL or mysql
when a parameter flag like 'status' = "OK" for instance
I suggest also to split in several logbook
but this is depend on your 'ELOG' parametrisation and logics

If your data are not 'sensitive' I can check on my linux server

Etienne

> Another thing that seems to slow the site down, is the number of users in 
> the elog notification list (those who've subscribed).  When you save a log 
> entry, it takes around 30sec or longer for it to actually complete the 
> save.  If I remove the list of users from the notification list and just 
> have a few, the save is very fast.

This problem will be fixed in version 2.2.5. Prior to 2.2.5, individual 
emails were sent to all recipients. Since each email takes 0.5-1 sec., this 
procedure can be very long. From 2.2.5 on, only one email is sent, but to 
all recipients. The disadvantage of this method is that the "Mail to:" field 
contains the email addresses of all recipients, so each recipient knows the 
addresses of the other, which is maybe not always what you want. I put a new 
option to discard the "Mail to:" field, but some systems the consider the 
mail with a missing "Mail to:" field as spam mail. 2.2.5 will be released in 
a couple of days.

> 2600 entries is too much for this application as it load the all files 
> in computer memory
> expand the server memory
> Are you running on linux or Windows ? I suggest linux (faster)
> We are working on the C source to move all data from flat to database like 
> SQL or mysql
> when a parameter flag like 'status' = "OK" for instance
> I suggest also to split in several logbook
> but this is depend on your 'ELOG' parametrisation and logics
> 
> If your data are not 'sensitive' I can check on my linux server
> 
> Etienne

It is not correct that all files are loaded into memory. Only the index 
resides in memory, the data stays on disk. In my environment, I see no speed 
difference between Windows and Linux. Moving to SQL will certainly not speed 
up the responsiveness in my opinion. So before working on that, create a SQL 
database with your 2600 entries and see how fast you can make queries on 
them.

The problem with the slow response is new to me. Other users mentioned no 
problem with logbooks with several throusand entries (except for the "find" 
command). But I will have a look myself in the next feature and see if I can 
make things better.

- Stefan

> Was wondering if there were any tweaks/suggestions for improving the 
> logbooks responsiviness.  Our logbook was started 31 July 01.  Since that 
> time we have went from 1 logbook to 4 logbooks.  Logbook 1 having 2651 
> entries, logbook 2 having 300 entries, and the last 2 are new logbooks, so 
> only a few entries.

In Version 2.2.5, the responsiviness to large (>1000 entries) logbooks has 
been improved dramatically. If no filtering is applied, a page from the 
logbook listing should be displayed with a response time independent of the 
logbook size (I tried 8000 entries). Only when a filter or sort option is 
applied, all entries have to be searched which takes ~5sec for 8000 entries 
on a 1.2 GHz Windows XP Laptop, which is the same speed as before.

> Was wondering if there were any tweaks/suggestions for improving the 
> logbooks responsiviness.  Our logbook was started 31 July 01.  Since that 
> time we have went from 1 logbook to 4 logbooks.  Logbook 1 having 2651 
> entries, logbook 2 having 300 entries, and the last 2 are new logbooks, so 
> only a few entries.

Another trick for large logbooks is to divide them into a logbook with 
recent entries and one with old entries (archive), like I did now in this 
forum. One can enable the "copy to" command for the administrator, who then 
can copy regularly old entries to the archive, keeping the recent logkook 
reasonable small with a good responsiviness. If one wants to search then the 
old messages, one can still go to the archive, but then the search command 
takes longer.

if you are guest in the find option  

select 'all logbook'

it will display all 'attributes' from other logbook 
with no option  'guest command ...'
but having the same 'attribute' name

Solution :
**********
I use the copy to command to make a copy to other logbook
with option 'guest command' enabled

in this section I remove some field so the guest user can't no see all field

I suggest to give acces to 'guest' on a second run of elog to another
port or other computer ?

> if you are guest in the find option  
> 
> select 'all logbook'
> 
> it will display all 'attributes' from other logbook 
> with no option  'guest command ...'
> but having the same 'attribute' name
> 
> Solution :
> **********
> I use the copy to command to make a copy to other logbook
> with option 'guest command' enabled
> 
> in this section I remove some field so the guest user can't no see all field
> 
> I suggest to give acces to 'guest' on a second run of elog to another
> port or other computer ?

I see your problem. I could either disable the "Search all logbooks" switch 
for certain logbooks (like the guest one), or restrict the search to logbooks 
which have a "guest command" option. What would you prefer?

- Stefan

> > if you are guest in the find option  
> > 
> > select 'all logbook'
> > 
> > it will display all 'attributes' from other logbook 
> > with no option  'guest command ...'
> > but having the same 'attribute' name
> > 
> > Solution :
> > **********
> > I use the copy to command to make a copy to other logbook
> > with option 'guest command' enabled
> > 
> > in this section I remove some field so the guest user can't no see all 
field
> > 
> > I suggest to give acces to 'guest' on a second run of elog to another
> > port or other computer ?
> 
> I see your problem. I could either disable the "Search all logbooks" switch 
> for certain logbooks (like the guest one), or restrict the search to 
logbooks 
> which have a "guest command" option. What would you prefer?
> 
> - Stefan

may be add a parameter

Restrict Search all logboog = 1 or 0
if 1 the switch will not appear 

> may be add a parameter
> 
> Restrict Search all logboog = 1 or 0
> if 1 the switch will not appear 

The flag "Search all logbooks" is already there! (I forgot about it!). So 
just set it to "0" and you should be fine.

- Stefan

> > may be add a parameter
> > 
> > Restrict Search all logboog = 1 or 0
> > if 1 the switch will not appear 
> 
> The flag "Search all logbooks" is already there! (I forgot about it!). So 
> just set it to "0" and you should be fine.
> 
> - Stefan

I do and it work fine

Starting from version 2.2.5 on, an new directory scheme has been 
implemented. The idea is to separate the config file from the theme/icon 
and the logbook directories. This can now be achieved by specifying the 
configuration file via the "-c" flag and the directories with the "-d" flag 
for the logbook root and the "resource directory" with the "-s" flag.

Alternatively, the resouce and logbook directories can be specified in the 
configuration file with

Resource dir = ...
Logbook dir = ...

The old "Data dir" statement is still possible but deprecated. Instead, the 
statement "Subdir = ..." should be used which is taken relative to 
the "Logbook dir". If no "Subdir" is given, the logbook name itself is used 
as the subdir. For this demo logbook I use now:

[global]
...
Resource dir = /usr/local/elogdemo
Logbook dir = /usr/local/elogdemo/logbooks

and no "Data dir" statements any more. The logbooks "Linux", "Database" 
and "Forum" are then located at

/usr/local/elogdemo/logbooks/Linux
/usr/local/elogdemo/logbooks/Database
/usr/local/elogdemo/logbooks/Forum

respectively. The help, theme and icon files are located at their old 
position ("themes" is automatically added to the "resource dir" as it was 
before).

I have some problem with email notification
for some logbooks I would like to notify only to specific adress
I try
Email All = adress1, adress2

Elog send well at 'adress1' and 'adress2' 
but also to all of other users ?
how to restric these only to 'adress1 and adress2 ?

is it possible to notify according to attribue value like

Attributes = Test1, Test2
Email All = $Test1

or concatenation of  $Test1 + '@mba.be' for example

Thanks

this is a wonderfull tools !
to improve documentation : true example are missing too much 'theorie'
but when I'm finish I'll put true sample on the net 

> I have some problem with email notification
> for some logbooks I would like to notify only to specific adress
> I try
> Email All = adress1, adress2
> 
> Elog send well at 'adress1' and 'adress2' 
> but also to all of other users ?
> how to restric these only to 'adress1 and adress2 ?

Some implementations rely on the fact the email is sent to all users plus a 
few other addresses. What I can do is put in another flag like "Supress 
email to users = 1" which would satisfy both requirements.

> is it possible to notify according to attribue value like
> 
> Attributes = Test1, Test2
> Email All = $Test1
> 
> or concatenation of  $Test1 + '@mba.be' for example

This is not possible right now, but I can put it on the wishlist.

> to improve documentation : true example are missing too much 'theorie'
> but when I'm finish I'll put true sample on the net 

I fully agree, so if someone has nice examples, I'm delighted to put them 
into an "examples" section of the documentation.

- Stefan