Re: E-log crash, posted by Stefan Ritt on Thu May 14 17:59:04 2009
|
| soren poulsen wrote: |
|
Hi
I am having a little problem with e-log that I can easily reproduce.
I have defined a number of constraints on my e-log fields and I am testing what happens when the user does not respect them.
So this only happens when I am not observing the input formats or the mandatory fields.
This is the GDB trace. This is not very verbose, so I must learn to use the other tracers, I guess.
Server listening on port 8079 ...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000414077 in is_script (
at src/elogd.c:5414
5414 for (i = 0; script_tags[i][0]; i++) {
(gdb)
Soren
|
It would be best if I could reproduce your problem. So can you start from a very simple configuration file, add your constraints until the problme happens, and then send me the config file? |
|
Re: E-log crash, posted by soren poulsen on Tue May 19 15:19:16 2009
|
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
Hi
I am having a little problem with e-log that I can easily reproduce.
I have defined a number of constraints on my e-log fields and I am testing what happens when the user does not respect them.
So this only happens when I am not observing the input formats or the mandatory fields.
This is the GDB trace. This is not very verbose, so I must learn to use the other tracers, I guess.
Server listening on port 8079 ...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000414077 in is_script (
at src/elogd.c:5414
5414 for (i = 0; script_tags[i][0]; i++) {
(gdb)
Soren
|
It would be best if I could reproduce your problem. So can you start from a very simple configuration file, add your constraints until the problme happens, and then send me the config file?
|
Hi
The problem is not exactly what I thought, but I did track it down. Here is a logbook definition that reliably creates a segmentation fault in e-log. This logbook's only useful purpose is in fact to create a segmentation fault:
You select "New", then "Select", without entering anything.
--------------
Login user = Admin
Attributes = Link
Change Link = <a href="https://$Link"">$Link</a>
---------------
I would be able to create some more debugging information of course, if needed.
Regards
Soren
|
|
Re: E-log crash, posted by Stefan Ritt on Thu Jun 4 14:05:58 2009
|
| soren poulsen wrote: |
|
Hi
I am having a little problem with e-log that I can easily reproduce.
I have defined a number of constraints on my e-log fields and I am testing what happens when the user does not respect them.
So this only happens when I am not observing the input formats or the mandatory fields.
This is the GDB trace. This is not very verbose, so I must learn to use the other tracers, I guess.
Server listening on port 8079 ...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000414077 in is_script (
at src/elogd.c:5414
5414 for (i = 0; script_tags[i][0]; i++) {
(gdb)
Soren
|
I had finally the same problem. This is due to a bug indeed inside is_script(). It has been fixed in revision 2201. |
|
Re: Dynamic attribute values, posted by Stefan Ritt on Tue Nov 10 15:00:15 2009
|
| Steve Williamson wrote: |
|
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?
|
Just try with the current version, where I reworked the "Subst" commands. See elog:66592. "Subst" work now only on "New", and "Subst on Edit" only works when editing an entry. |
|
Re: Dynamic attribute values, posted by Steve Williamson on Fri Nov 13 14:28:25 2009
|
| Stefan Ritt wrote: |
|
| Steve Williamson wrote: |
|
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?
|
Just try with the current version, where I reworked the "Subst" commands. See elog:66592. "Subst" work now only on "New", and "Subst on Edit" only works when editing an entry.
|
Thanks for that - it works perfectly. Another success for elog! |
|
Re: Duplicate of a reply should be a reply, posted by Stefan Ritt on Mon Jul 17 13:49:37 2006
|
| Gerald Ebberink wrote: | Hello everybody
This weekend I found that if I duplicate a reply it does not become a reply it self.
Is this on purpouse?
I have been through the source a little (not much time for that) and I can not find a reason where the "in reply to" value is dropped.
Could anyone give me an pointer? |
This is on purpuse. The Duplicate functionality is ment to "clone" an existing entry, to save some typing work if an existing entry contains most of what one wants in a new entry. If one duplicates a reply, it is detached from the original thread, so there is not entry to attach the duplicate to. I guess you want to make a new reply to an existing entry, and then have another existing reply as a template for that, but this is not possible. If I would not drop the "in reply to" value, the duplicate would point to the wrong entry. |
|
Re: Duplicate entry suggestion, posted by Stefan Ritt on Tue Apr 1 08:01:02 2008
|
| Dennis Seitz wrote: |
|
We have configured several logbooks to allow users to duplicate an entry in another logbook, which is very useful for entries which apply to more than one category.
However, once the entry is duplicated, subsequent revisions to the original entry are not copied to the duplicate entries.
I can see where implementing that would add a lot of code to ELOG. Rather than do that, would it be possible to add a configuration option to duplicate only the attributes, and place a link to the original entry in the body of the duplicated entry instead of the full text?
|
I don't know if you are aware, but you can put links to other entries manually into the text. Just enter them in the form elog:65799. You can click on that link which takes you the entry you reference. Unfortunately there is at the moment no automatic way to generate this back link automatically. |
|
Re: Duplicate entry suggestion, posted by Dennis Seitz on Tue Apr 1 20:31:26 2008
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
We have configured several logbooks to allow users to duplicate an entry in another logbook, which is very useful for entries which apply to more than one category.
However, once the entry is duplicated, subsequent revisions to the original entry are not copied to the duplicate entries.
I can see where implementing that would add a lot of code to ELOG. Rather than do that, would it be possible to add a configuration option to duplicate only the attributes, and place a link to the original entry in the body of the duplicated entry instead of the full text?
|
I don't know if you are aware, but you can put links to other entries manually into the text. Just enter them in the form elog:65799. You can click on that link which takes you the entry you reference. Unfortunately there is at the moment no automatic way to generate this back link automatically.
|
Thanks, I was not aware of that - usually I have copied and pasted the entire path from my browser.
In any case, can you consider my request for possible future implementation? I think it's a useful function. For now, it's really no big deal to simply copy the url before selecting the Copy To: menu and then replacing the body text with the copied link. But I think it would be more useful to make this happen automatically, so I don't have to ask users to comply voluntarily.
Thank you.
|
|