ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66557
|
Wed Oct 7 16:17:34 2009 |
| Steve Williamson | StephenWilliamson@Barnsley.gov.uk | Question | Linux | 2.7.5 | Dynamic attribute values | Hi
I'm doing something wrong but can't work out what!
I've created a new logbook with some date attributes that need to keep in step, e.g. one date ("receipt date") is set to the date the new record is created and another ("response required") to 7 days later. The logbook doesn't use threaded messages, just a single page for each log entry with Submin/Preview/Back. The dates are set with:
Preset Receipt Date = $date
Preset Response Required = $shell(gawk 'BEGIN{ print $Receipt Date + 86400 * 7}')
"receipt date" and "response required" are set correctly when the log is written but if I change "receipt date" then "response required" is not altered - presumably because Preset only works on "New". Tho I haven't found a way to make this dynamic with Subst.
When the log is updated later a third date may be entered ("proposal submitted") and this should calculate a fourth date ("proposal expires"). Again, I thought I could do this with some sort of "Subst" but can't work out how. If I use Subst then the value of "proposal expires" isn't changed at all and if I use Subst On Edit then the value isn't changed until I go in to edit the log when the correct "proposal expires" date gets calculated and displayed, e.g.:
Subst On Edit Proposal Expires = $shell(gawk 'BEGIN{ if ($Proposal Sumbitted > 0) {print $Proposal Submitted + 86400 * 30}}')
Am I trying to do the impossible, and is there a document that will help me to understand when different updates (Preset, Subst, Subst On..., Change etc) happen and comparing their use?
A great piece of software - though I sometimes find it hard to get my head round all that it can be bent to do!
regards
Steve
|
66558
|
Wed Oct 14 16:31:46 2009 |
| soren poulsen | soren.poulsen@cern.ch | Question | Linux | 2.7.7 | Automatically generated incrementing tags (#) | 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
|
66559
|
Wed Oct 14 16:46:57 2009 |
| soren poulsen | soren.poulsen@cern.ch | Question | Linux | 2.7.7 | Re: Automatically generated incrementing tags (#) |
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". |
66560
|
Fri Oct 16 12:17:15 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.7.7 | Re: User authorization file corruption |
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. |
66561
|
Fri Oct 16 12:21:45 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Linux | 2.7.7 | Re: Option list length |
soren poulsen wrote: |
Hi,
I use the following attribute definition:
Options <attribute> = <list>
However, I am being limited by the list length limit of 100. I have 103 items, but I only see 100.
Could the limit be extended (to 200 for instance) ?
Thanks a lot for your help
Soren
|
You can change that yourself. Just find following line in elogd.c:
#define MAX_N_LIST 100
and change it to 200, then recompile. But you are there on your own, at some point you will get a stack overflow and elogd will crash, but I don't know exactly where this limit is.
Anyhow I would propose that if you have so many options in an attribute, that you better go and group these options somehow. Like using two attributes, where the first defines the group, and the second gets different list for each option of the first attribute using conditional attributes. Have a look here.
|
66564
|
Mon Oct 26 10:13:54 2009 |
| soren poulsen | soren.poulsen@cern.ch | Request | Linux | 2.7.7 | Re: Option list length |
Stefan Ritt wrote: |
soren poulsen wrote: |
Hi,
I use the following attribute definition:
Options <attribute> = <list>
However, I am being limited by the list length limit of 100. I have 103 items, but I only see 100.
Could the limit be extended (to 200 for instance) ?
Thanks a lot for your help
Soren
|
You can change that yourself. Just find following line in elogd.c:
#define MAX_N_LIST 100
and change it to 200, then recompile. But you are there on your own, at some point you will get a stack overflow and elogd will crash, but I don't know exactly where this limit is.
Anyhow I would propose that if you have so many options in an attribute, that you better go and group these options somehow. Like using two attributes, where the first defines the group, and the second gets different list for each option of the first attribute using conditional attributes. Have a look here.
|
Thanks. This is a good explanation. It might indeed be better to re-group the options to have a shorter list.
Soren |
66565
|
Mon Oct 26 10:15:20 2009 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.7 | Re: User authorization file corruption |
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 |
66566
|
Mon Oct 26 15:43:55 2009 |
| soren poulsen | soren.poulsen@cern.ch | Question | Linux | 2.7.7 | Re: Automatically generated incrementing tags (#) |
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 |
|