Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 123 of 238  Not logged in ELOG logo
icon5.gif   Automatically generated incrementing tags (#), posted by soren poulsen on Wed Oct 14 16:31:46 2009 

Hi,

I am using the # character to generate automatically incrementing numbers for new messages.

My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".

So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.

Maybe someone has a solution to this ?

Soren Poulsen

 

 

    icon2.gif   Re: Automatically generated incrementing tags (#), posted by soren poulsen on Wed Oct 14 16:46:57 2009 

soren poulsen wrote:

Hi,

I am using the # character to generate automatically incrementing numbers for new messages.

My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".

So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.

Maybe someone has a solution to this ?

Soren Poulsen

 

 

The solution is to use "Subst" instead of "Preset".

       icon2.gif   Re: Automatically generated incrementing tags (#), posted by soren poulsen on Mon Oct 26 15:43:55 2009 

soren poulsen wrote:

soren poulsen wrote:

Hi,

I am using the # character to generate automatically incrementing numbers for new messages.

My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".

So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.

Maybe someone has a solution to this ?

Soren Poulsen

 

 

The solution is to use "Subst" instead of "Preset".

 This is not really resolved, since "Subst" creates a new number on both "New" and "Reply". I would like "Subst" to create a new number only on "New" and preserve this number through replies throughout the thread. I would like to be able to say "Subst thread = #" to make a new number for the thread and combine it with "Subst on reply thread = $thread" to preserve the number on replies, but this does not work. Maybe someone has already done this ?

Soren

          icon2.gif   Re: Automatically generated incrementing tags (#), posted by soren poulsen on Sun Nov 8 23:29:35 2009 

soren poulsen wrote:

soren poulsen wrote:

soren poulsen wrote:

Hi,

I am using the # character to generate automatically incrementing numbers for new messages.

My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".

So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.

Maybe someone has a solution to this ?

Soren Poulsen

 

 

The solution is to use "Subst" instead of "Preset".

 This is not really resolved, since "Subst" creates a new number on both "New" and "Reply". I would like "Subst" to create a new number only on "New" and preserve this number through replies throughout the thread. I would like to be able to say "Subst thread = #" to make a new number for the thread and combine it with "Subst on reply thread = $thread" to preserve the number on replies, but this does not work. Maybe someone has already done this ?

Soren

 This can be solved with something like "Subst <attr> = $shell(cmd...) where cmd calculates a new value of attr, as a function of #, when attr does not already have a value. This thread is closed.
 

Soren

 

          icon2.gif   Re: Automatically generated incrementing tags (#), posted by Stefan Ritt on Tue Nov 10 14:42:11 2009 

soren poulsen wrote:

soren poulsen wrote:

soren poulsen wrote:

Hi,

I am using the # character to generate automatically incrementing numbers for new messages.

My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".

So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.

Maybe someone has a solution to this ?

Soren Poulsen

 

 

The solution is to use "Subst" instead of "Preset".

 This is not really resolved, since "Subst" creates a new number on both "New" and "Reply". I would like "Subst" to create a new number only on "New" and preserve this number through replies throughout the thread. I would like to be able to say "Subst thread = #" to make a new number for the thread and combine it with "Subst on reply thread = $thread" to preserve the number on replies, but this does not work. Maybe someone has already done this ?

Soren

I just reworked the "Subst" command to make it more consistently. Now "Subst on Edit" and "Subst on Reply" are executed after the entry submission,  and they are mutually exclusive. So all you need right now is

Subst Tag = #

and it will not increment when editing or replying to an existing entry. The fix is in SVN revision 2264.

             icon2.gif   Re: Automatically generated incrementing tags (#), posted by soren poulsen on Tue Nov 10 21:36:21 2009 

Stefan Ritt wrote:

soren poulsen wrote:

soren poulsen wrote:

soren poulsen wrote:

Hi,

I am using the # character to generate automatically incrementing numbers for new messages.

My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".

So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.

Maybe someone has a solution to this ?

Soren Poulsen

 

 

The solution is to use "Subst" instead of "Preset".

 This is not really resolved, since "Subst" creates a new number on both "New" and "Reply". I would like "Subst" to create a new number only on "New" and preserve this number through replies throughout the thread. I would like to be able to say "Subst thread = #" to make a new number for the thread and combine it with "Subst on reply thread = $thread" to preserve the number on replies, but this does not work. Maybe someone has already done this ?

Soren

I just reworked the "Subst" command to make it more consistently. Now "Subst on Edit" and "Subst on Reply" are executed after the entry submission,  and they are mutually exclusive. So all you need right now is

Subst Tag = #

and it will not increment when editing or replying to an existing entry. The fix is in SVN revision 2264.

 Thanks a lot for doing this change.

icon1.gif   Reply on item not allowed moving item to other logbook, posted by Eddy Berends on Mon Nov 9 11:50:05 2009 

After I moved an item from one logbook to another one I cannot reply on this item anymore.

When the submit button is clicked it returns: Submit not allowed

This eLog server running Linux is sync'd with an server running Windows XP.

On the windows server the funcionality is working perfect(so no Submit is not allowed on a reply)

    icon2.gif   Re: Reply on item not allowed moving item to other logbook, posted by Stefan Ritt on Tue Nov 10 14:24:26 2009 

Eddy Berends wrote:

After I moved an item from one logbook to another one I cannot reply on this item anymore.

When the submit button is clicked it returns: Submit not allowed

This eLog server running Linux is sync'd with an server running Windows XP.

On the windows server the funcionality is working perfect(so no Submit is not allowed on a reply)

Check your configuration file for the destination logbook, probably you have only restricted rights there ("Guest menu", "Login user" ???) 

icon5.gif   Export Text to a csv File, posted by Michael Dannmeyer on Tue Nov 10 12:50:48 2009 

Hello,

is it possible to export the Text Field and the entries in this field to a csv file? If yes, what are the settings to do this?

Regards

Michael

 

 

    icon2.gif   Re: Export Text to a csv File, posted by Stefan Ritt on Tue Nov 10 12:54:47 2009 

Michael Dannmeyer wrote:

Hello,

is it possible to export the Text Field and the entries in this field to a csv file? If yes, what are the settings to do this?

Regards

Michael

A CSV file is by definition one line per entry. So if you have several lines in your Text Field, how will you be able to squeeze this into one line?

Alternatively you can export to XML, which contains the Text Field, then do a manual conversion to something else. 

       icon2.gif   Re: Export Text to a csv File, posted by Michael Dannmeyer on Tue Nov 10 13:06:26 2009 

Stefan Ritt wrote:

Michael Dannmeyer wrote:

Hello,

is it possible to export the Text Field and the entries in this field to a csv file? If yes, what are the settings to do this?

Regards

Michael

A CSV file is by definition one line per entry. So if you have several lines in your Text Field, how will you be able to squeeze this into one line?

Alternatively you can export to XML, which contains the Text Field, then do a manual conversion to something else. 

 Thanks for your fast answer.

icon5.gif   width of the Text column in the summary list view, posted by Fabio Rossi on Fri Nov 6 12:49:22 2009 

I have "Summary lines = 1" in the config file. The first line visualized in the summary list, in the Text column, is truncated. I'm using the default style.

Which is the way to set the number of character displayed?

    icon2.gif   Re: width of the Text column in the summary list view, posted by Stefan Ritt on Fri Nov 6 13:46:38 2009 

Fabio Rossi wrote:

I have "Summary lines = 1" in the config file. The first line visualized in the summary list, in the Text column, is truncated. I'm using the default style.

Which is the way to set the number of character displayed?

I added a new parameter

Summary line length = x

for you. This is included in SVN revision 2262 (if you can compile it yourself) and will be contained in the next release.

       icon2.gif   Re: width of the Text column in the summary list view, posted by Fabio Rossi on Fri Nov 6 18:08:20 2009 

Stefan Ritt wrote:

Fabio Rossi wrote:

I have "Summary lines = 1" in the config file. The first line visualized in the summary list, in the Text column, is truncated. I'm using the default style.

Which is the way to set the number of character displayed?

I added a new parameter

Summary line length = x

for you. This is included in SVN revision 2262 (if you can compile it yourself) and will be contained in the next release.

I have already tested your patch backporting the change to 2.7.7.1. It works like a charm.

Thank you very much!

icon5.gif   Access control, group level, posted by Niklas on Mon Nov 2 11:17:20 2009 

Hi elog experts =)

 

Anyone know if it's possible to have access control per group-level?

For instance:

Group A = B,C   

Group B = LogA   

Group C = LogB, LogC      

Group C: Read password = abc

 

?

 

//NH

    icon2.gif   Re: Access control, group level, posted by Stefan Ritt on Tue Nov 3 09:24:15 2009 

Niklas wrote:

Hi elog experts =)

 

Anyone know if it's possible to have access control per group-level?

For instance:

Group A = B,C   

Group B = LogA   

Group C = LogB, LogC      

Group C: Read password = abc

 //NH

I added your vote to the wishlist

https://midas.psi.ch/elog/wishlist.html 

icon5.gif   Emails generated by *this* discussion forum, posted by David Pilgram on Mon Nov 2 11:52:08 2009 
Hi Stefan,

After 21.Oct, all the emails sent out by this discussion form now are addressed to

ELOG@ananke.jtan.com
the name of the server my mails are sent to.

Before that the emails were addressed to 

ELOG@emix.psi.ch

Obviouisly my real email address is there, in the headers (as it would appear for a BCC)

The only consequence for me was these emails turned up in the wrong mailbox, but perhaps it has wider implications?
    icon2.gif   Re: Emails generated by *this* discussion forum, posted by Stefan Ritt on Tue Nov 3 09:14:14 2009 
> Hi Stefan,
> 
> After 21.Oct, all the emails sent out by this discussion form now are addressed to
> 
> ELOG@ananke.jtan.com
> the name of the server my mails are sent to.
> 
> Before that the emails were addressed to 
> 
> ELOG@emix.psi.ch
> 
> Obviouisly my real email address is there, in the headers (as it would appear for a BCC)
> 
> The only consequence for me was these emails turned up in the wrong mailbox, but perhaps it has wider implications?

Indeed on Oct. 21st the SMPT server sending out emails from this forum has been changed. I checked my own mails coming 
from the forum, but I could not find any hint of what you describe above. The "From:" header contains "noreply@psi.ch" 
and the "To:" header is my email address. The "Received:" header contains our SMTP server, but you should not that field 
for filtering your email.

- Stefan
icon13.gif   elog crashes with a long thread., posted by David Pilgram on Thu Oct 29 20:48:41 2009 
Hi Stefan,

I have a thread of 70 entries.  I added another entry, which was saved, but elog crashed.
It would restart, but crash every time I then tried to access that 71 entry thread.

By editing the yymmdda.log files to remove the latest entry, all was well again.
Add a test new entry (much smaller) also crashed elog as before.

If it is any help, this is the error message I caught on a console:

src/elogd.c:703: xrealloc: Assertion `*((unsigned int *) (temp + old_size)) == 0xdeadc0de' failed.
./log: line 1:  3123 Aborted    

Now I have got around this, by ending that thread with reference to a new one to continue, but is this to be
expected?  

If this is something (like memory allocation) that would have been in hiding from the start, I cannot imagine
that it is likely to be hit often enough to actually "bug fix" - it might, in any case, cause problems elsewhere.
icon4.gif   User authorization file corruption, posted by soren poulsen on Fri Sep 18 07:39:02 2009 

Hi,

Here is what happens (I think) if E-log encounters a full file system where it keeps the user authorization file:

1. When a user connects, E-log will make a backup of the file. The backup will be corrupt since the file system is full.

2. E-log will modify the contents of the original file, and write it back. The file will be corrupt since the file system is full.

3. Now, both the backup and the normal file are corrupt and you cannot log on, until someone cleans up the file system and restores a valid copy of the file.

Would it be possible to fix this ? Like abort if step 1 is not successful. And restore the backup file if step 2 is not successful.

Thanks a lot for you help 

Soren

    icon2.gif   Re: User authorization file corruption, posted by Stefan Ritt on Fri Oct 16 12:17:15 2009 

soren poulsen wrote:

Hi,

Here is what happens (I think) if E-log encounters a full file system where it keeps the user authorization file:

1. When a user connects, E-log will make a backup of the file. The backup will be corrupt since the file system is full.

2. E-log will modify the contents of the original file, and write it back. The file will be corrupt since the file system is full.

3. Now, both the backup and the normal file are corrupt and you cannot log on, until someone cleans up the file system and restores a valid copy of the file.

Would it be possible to fix this ? Like abort if step 1 is not successful. And restore the backup file if step 2 is not successful.

Thanks a lot for you help 

Soren

Ok, I finally found some time (I'm pretty busy these days) to add a check for a potential full file system in SVN revision 2258. So before the password file would get corrupted, elog shows an error message about the full file system and just stops to work until space is freed up. 

       icon2.gif   Re: User authorization file corruption, posted by soren poulsen on Mon Oct 26 10:15:20 2009 

Stefan Ritt wrote:

soren poulsen wrote:

Hi,

Here is what happens (I think) if E-log encounters a full file system where it keeps the user authorization file:

1. When a user connects, E-log will make a backup of the file. The backup will be corrupt since the file system is full.

2. E-log will modify the contents of the original file, and write it back. The file will be corrupt since the file system is full.

3. Now, both the backup and the normal file are corrupt and you cannot log on, until someone cleans up the file system and restores a valid copy of the file.

Would it be possible to fix this ? Like abort if step 1 is not successful. And restore the backup file if step 2 is not successful.

Thanks a lot for you help 

Soren

Ok, I finally found some time (I'm pretty busy these days) to add a check for a potential full file system in SVN revision 2258. So before the password file would get corrupted, elog shows an error message about the full file system and just stops to work until space is freed up. 

Great. We fully appreciate that your are busy (with other things than E-log).

Thanks for the resolution.

Soren

ELOG V3.1.5-3fb85fa6