When you do a find in elog, records per page (some crazy large number - for 
your forum logbook, display 57 entries seem to cause the problem, then 
select last year (1 years worth of logs),(don't select printable)

the results appear way off the screen (the message body looks fine, but the 
title, etc extend way off the screen).

Printable doesn't have this problem.

> When you do a find in elog, records per page (some crazy large number - for 
> your forum logbook, display 57 entries seem to cause the problem, then 
> select last year (1 years worth of logs),(don't select printable)
> 
> the results appear way off the screen (the message body looks fine, but the 
> title, etc extend way off the screen).
> 
> Printable doesn't have this problem.

I could not reproduce this problem. Can you send me the exact URL (the 
address with all the parameters from your browser's address bar like 
http://midas.psi.ch/elogdemo/Forum/?npp=57...) and tell me exactly under 
which browser this happens?

Can you consider implementing the following additions to the functionality

1) Subt on edit <attribute> = xyz 

This would be fantastic for implementing version control so you can see who 
has edited a posted or a db entry.

2) Have a SORT fieldname flag so you can decide which column to sort things 
by on a display listing in conjunction to the display flags, it current 
defaults to the # column and I find i am directly linking to a sorted 
display

3) Have the elogd.conf track actual log entries people have changed 
detailing date and time etc.

4) Ability to export contents of the log books to files on disk for backup 
purposes as all data is contained within a single log file which causes 
problem for command line searches.


Many thanks 

> Can you consider implementing the following additions to the functionality
> 
> 1) Subt on edit <attribute> = xyz 
> 
> This would be fantastic for implementing version control so you can see 
who 
> has edited a posted or a db entry.

Can you give me an example of how you would use that?
 
> 2) Have a SORT fieldname flag so you can decide which column to sort 
things 
> by on a display listing in conjunction to the display flags, it current 
> defaults to the # column and I find i am directly linking to a sorted 
> display

Sorting is not done by the "#" column but by the sequence when messages have 
been entered. You can sort the table differently by clicking on the table 
titles (twice for reverse sort). To sort by default on a column, for example 
sort by the author, you can add

Start page = ?sort=author

into elogd.cfg which does the job.

> 3) Have the elogd.conf track actual log entries people have changed 
> detailing date and time etc.

Revision management is not forseen by the structure of the ELOG database. 
What you can do is if you edit a message you check "Resubmit as new entry", 
then you keep a copy of the old version. 

> 4) Ability to export contents of the log books to files on disk for backup 
> purposes as all data is contained within a single log file which causes 
> problem for command line searches.

Well, you have already all log book files on disk in a simple format:

YYMMDDa.log

(Year/Month/Day) which you can easily backup. By a mask like 02*a.log you 
can backup all data from 2002 and so on. The idea of having separate log 
files for each day is to have this possibility to simply backup various date 
intervals. 

What kind of command line searches are you interested in?

- Stefan

> > Can you consider implementing the following additions to the functionality
> > 
> > 1) Subt on edit <attribute> = xyz 
> > 
> > This would be fantastic for implementing version control so you can see 
> who 
> > has edited a posted or a db entry.
> 
> Can you give me an example of how you would use that?

-----

Lets say you are storing configuration information relating to a customers 
solution, you need the ability to track who has made what changes to the 
config information stored in the log book so you can backtrack who changed 
what and when, for example

If you have a field name called Last Edited by this field is locked and not 
editable using the Lock attributes flag, but if you had Subt on edit 
everytime that entry is updated it places your login name into this field and 
therefore stamps it to say you have edited it, as the field isnt free txt it 
cant be spoofed as the $long_name comes from your login details.

-----
>  
> > 2) Have a SORT fieldname flag so you can decide which column to sort 
> things 
> > by on a display listing in conjunction to the display flags, it current 
> > defaults to the # column and I find i am directly linking to a sorted 
> > display
> 
> Sorting is not done by the "#" column but by the sequence when messages 
have 
> been entered. You can sort the table differently by clicking on the table 
> titles (twice for reverse sort). To sort by default on a column, for 
example 
> sort by the author, you can add
> 
> Start page = ?sort=author
> 
> into elogd.cfg which does the job.
----
Excellent I didnt know what Ill try that tomorrow

----

 

> > > Can you consider implementing the following additions to the 
functionality
> > > 
> > > 1) Subt on edit <attribute> = xyz 
> > > 
> > > This would be fantastic for implementing version control so you can see 
> > who 
> > > has edited a posted or a db entry.
> > 
> > Can you give me an example of how you would use that?
> 
> -----
> 
> Lets say you are storing configuration information relating to a customers 
> solution, you need the ability to track who has made what changes to the 
> config information stored in the log book so you can backtrack who changed 
> what and when, for example
> 
> If you have a field name called Last Edited by this field is locked and not 
> editable using the Lock attributes flag, but if you had Subt on edit 
> everytime that entry is updated it places your login name into this field 
and 
> therefore stamps it to say you have edited it, as the field isnt free txt 
it 
> cant be spoofed as the $long_name comes from your login details.

Ok, I implemented "Subst on edit", it will be contained in Version 2.3.1 
which is supposed to come out next week.

- Stefan

Hi Stefan,

Many users have there email forward to Blackberry devices.  Although I 
wasn't aware, it appears the Blackberry has a limit (or maybe one was set) 
of how big the message can be (still checking for that though).

Previously, a modification was made that addressed the issue of slow ELOG 
response when saving the elog entry.   I think the change was for ELOG to 
generate one email and send to all the users designated to receive the 
notification.  This caused everyone to show up as "TO" addresses.

This change makes the Email header increase in size (length).  I guess the 
Blackberry counts the Header portion as part of the email size limit.

Any ideas?

Thanks, 
Eric

Another Question:  Could ELOG be configured to send notifications as a Blind 
Copy?  Just wondering if that would take care of the problem?

> Hi Stefan,
> 
> Many users have there email forward to Blackberry devices.  Although I 
> wasn't aware, it appears the Blackberry has a limit (or maybe one was set) 
> of how big the message can be (still checking for that though).
> 
> Previously, a modification was made that addressed the issue of slow ELOG 
> response when saving the elog entry.   I think the change was for ELOG to 
> generate one email and send to all the users designated to receive the 
> notification.  This caused everyone to show up as "TO" addresses.
> 
> This change makes the Email header increase in size (length).  I guess the 
> Blackberry counts the Header portion as part of the email size limit.
> 
> Any ideas?
> 
> Thanks, 
> Eric

I just noticed that the notifications I receive from your ELOG system, 
doesn't show anyone in the "TO:" section but myself.  Or is ELOG configured 
to only send myself a message?


> Another Question:  Could ELOG be configured to send notifications as a 
Blind 
> Copy?  Just wondering if that would take care of the problem?
> 
> > Hi Stefan,
> > 
> > Many users have there email forward to Blackberry devices.  Although I 
> > wasn't aware, it appears the Blackberry has a limit (or maybe one was 
set) 
> > of how big the message can be (still checking for that though).
> > 
> > Previously, a modification was made that addressed the issue of slow ELOG 
> > response when saving the elog entry.   I think the change was for ELOG to 
> > generate one email and send to all the users designated to receive the 
> > notification.  This caused everyone to show up as "TO" addresses.
> > 
> > This change makes the Email header increase in size (length).  I guess 
the 
> > Blackberry counts the Header portion as part of the email size limit.
> > 
> > Any ideas?
> > 
> > Thanks, 
> > Eric

> I just noticed that the notifications I receive from your ELOG system, 
> doesn't show anyone in the "TO:" section but myself.  Or is ELOG 
configured 
> to only send myself a message?

This is on purpose. I have many people registered for the Forum. So when a 
notification is sent, it is not a good idea if everybody sees everybody 
else's mail addresses. Therefor I have 

Omit Email to = 1

in the config file. This way the "To:" field is omitted to "hide" the mail 
recipients from each other. Your mail client realizes that and fills in your 
own address automatically, that's why you only see yourself. Maybe you try 
that option, might help with your previous problem as well.

- Stefan

When ELOG is configured for Self-Register=3, is it still possible
to use the Author attribute as a Quick Filter? 

When I try it, the Author drop down box doesn't display anything.

Thanks,
Eric

> When ELOG is configured for Self-Register=3, is it still possible
> to use the Author attribute as a Quick Filter? 
> 
> When I try it, the Author drop down box doesn't display anything.
> 
> Thanks,
> Eric

The "Quick Filter" facility only works for attributes which are avaiable as 
an "Options <attribute> = ..." list. So if you have a "free" attribute like 
the author, the systen would have to scan the whole logbook to find all 
possible authors, which would result in some unacceptable performance 
degradation. Nevertheless, in systems with a limited number of authors one 
can add the "options author = ..." statement to get the selection box. The 
behaviour is independent of the "Self-Register" setting.

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