ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66594
|
Tue Nov 10 15:00:15 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.5 | Re: Dynamic attribute values |
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. |
66600
|
Fri Nov 13 14:28:25 2009 |
| Steve Williamson | StephenWilliamson@Barnsley.gov.uk | Question | Linux | 2.7.5 | Re: Dynamic attribute values |
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! |
1883
|
Mon Jul 17 13:49:37 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | Linux | 2.6.2-1706 | Re: Duplicate of a reply should be a reply |
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. |
65800
|
Tue Apr 1 08:01:02 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | All | | Re: Duplicate entry suggestion |
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. |
65802
|
Tue Apr 1 20:31:26 2008 |
| Dennis Seitz | dseitz@berkeley.edu | Request | All | | Re: Duplicate entry suggestion |
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.
|
68581
|
Thu Mar 16 16:11:02 2017 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 2.9.2-2475 | Re: Duplicate entries | I've seen exact;y this effect, even though I have branching = 0 in my config file - so ordinarily no chance to have two
replies to an entry. My pointer aka mouse (I'm on Linux) is a bit dodgy, and sometimes disconnects/reconnects, so in effect gives a very fast double click. I've always assumed that was the cause of the problem. The two replies have incremental IDs, and both those IDs are listed in the "Reply to" header section of the entry. I'm not sure how this overcomes the branching = 0 detail, though.
That is what I have assumed, but if others see this on occasion, perhaps it's got a different cause.
Alan Grant wrote: |
Periodically (rarely) on manually adding a record into Elog it generates a duplicate record with its own incremented ID and I don't know why. I just delete the duplicate in the meantime but would like to know if anyone else has seen this and whether their is a answer/fix for it. Thanks.
|
|
69266
|
Wed Dec 2 04:07:57 2020 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 2.9.2-2475 | Re: Duplicate entries | I find that I can reply to a message ("original" message, if you will) without doing anything to the reply message (the "copy" of the original message, if you will). If I then submit it, it gets saved as a new message, identical to the one I replied to.
I read through the options at the end of the docs. I did not see anything about a way to suppress identical messages, or a way to force the user to make some kind of change to make the reply different from the original.
David Pilgram wrote: |
I've seen exact;y this effect, even though I have branching = 0 in my config file - so ordinarily no chance to have two
replies to an entry. My pointer aka mouse (I'm on Linux) is a bit dodgy, and sometimes disconnects/reconnects, so in effect gives a very fast double click. I've always assumed that was the cause of the problem. The two replies have incremental IDs, and both those IDs are listed in the "Reply to" header section of the entry. I'm not sure how this overcomes the branching = 0 detail, though.
That is what I have assumed, but if others see this on occasion, perhaps it's got a different cause.
Alan Grant wrote: |
Periodically (rarely) on manually adding a record into Elog it generates a duplicate record with its own incremented ID and I don't know why. I just delete the duplicate in the meantime but would like to know if anyone else has seen this and whether their is a answer/fix for it. Thanks.
|
|
|
69268
|
Wed Dec 2 15:57:25 2020 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 2.9.2-2475 | Re: Duplicate entries | I'm not sure if this is what you want.
If you want to prevent "accidental" replies being identical to the original message, you can force a situation where the user will be alerted that they have to do something if they really want to make a reply.
An example. I have an attribute "Action". In order to make a reply. I have set up that I must select an Action attribute every time. If I forget, I get an error message screen, and can click to go back to the entry and have another attempt (nothing is deleted if you have added to the reply).
In the elog.cfg file, I have the lines
Required Attributes = Action
Preset on reply Action =
This hopefully would remind them that they are making a reply to an entry, and either make a reply, or abort the attempt.
Harry Martin wrote: |
I find that I can reply to a message ("original" message, if you will) without doing anything to the reply message (the "copy" of the original message, if you will). If I then submit it, it gets saved as a new message, identical to the one I replied to.
I read through the options at the end of the docs. I did not see anything about a way to suppress identical messages, or a way to force the user to make some kind of change to make the reply different from the original.
David Pilgram wrote: |
I've seen exact;y this effect, even though I have branching = 0 in my config file - so ordinarily no chance to have two
replies to an entry. My pointer aka mouse (I'm on Linux) is a bit dodgy, and sometimes disconnects/reconnects, so in effect gives a very fast double click. I've always assumed that was the cause of the problem. The two replies have incremental IDs, and both those IDs are listed in the "Reply to" header section of the entry. I'm not sure how this overcomes the branching = 0 detail, though.
That is what I have assumed, but if others see this on occasion, perhaps it's got a different cause.
Alan Grant wrote: |
Periodically (rarely) on manually adding a record into Elog it generates a duplicate record with its own incremented ID and I don't know why. I just delete the duplicate in the meantime but would like to know if anyone else has seen this and whether their is a answer/fix for it. Thanks.
|
|
|
|
|