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
|
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". |
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 |
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
|
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. |
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. |
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) |
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" ???) |
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
|
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. |
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. |
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? |
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. |
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! |
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 |
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 |
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? |
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 |
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. |
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 |
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. |
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 |