ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66599
|
Fri Nov 13 14:25:52 2009 |
| Steve Williamson | StephenWilliamson@Barnsley.gov.uk | Request | Linux | 2.7.7-2264 | List View: Attachments icon |
It is occasionally convenient to be able to put the Edit button at the beginning of the line in list view, e.g. when pages are wider than the screen it saves having to scroll across to find it. Would it be possible to do something similar with the Attachments button?
regards
Steve |
66598
|
Fri Nov 13 10:57:03 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 2.7.7-2252 | Re: Paper clip showing attachment not always present |
I may have made this sound as if the issue occurs if the first entry in a thread has an attachment; in fact it
happens whether or not there is an attachment to the first entry.
Hope this makes matters a bit clearer.
> Hi Stefan,
>
> I must have seen this before, but only just "noticed" it.
>
> If you attach a picture or pdf to the first entry in a tread, there is then a paperclip after the thread display
> line. This shows up in threaded view or collapsed threaded view.
>
> If you then attach a picture or pdf to a subsequent entry, the paperclip icon does not show up in threaded
> display, (it is still there on the initial entry) but if the attachment is to the latest entry it shows up in
> treaded collapsed display (collapse on last=1, of course). If collapse on last=0, then initial entry shows on
> threaded, collapsed, and that has the icon as expected.
>
> When the icon does show, you can click on it and get the correct attachment to show/launch reader or whatever.
>
> It would appear to be a bug that the attachment icon does not appear in the threaded display (for any entry
> other than the initial one).
>
> (sorry about the first posting, hit the wrong key sequence in error)
>
> Regards,
>
> David Pilgram. |
66597
|
Wed Nov 11 19:53:57 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 2.7.7-2252 | Paper clip showing attachment not always present |
Hi Stefan,
I must have seen this before, but only just "noticed" it.
If you attach a picture or pdf to the first entry in a tread, there is then a paperclip after the thread display
line. This shows up in threaded view or collapsed threaded view.
If you then attach a picture or pdf to a subsequent entry, the paperclip icon does not show up in threaded
display, (it is still there on the initial entry) but if the attachment is to the latest entry it shows up in
treaded collapsed display (collapse on last=1, of course). If collapse on last=0, then initial entry shows on
threaded, collapsed, and that has the icon as expected.
When the icon does show, you can click on it and get the correct attachment to show/launch reader or whatever.
It would appear to be a bug that the attachment icon does not appear in the threaded display (for any entry
other than the initial one).
(sorry about the first posting, hit the wrong key sequence in error)
Regards,
David Pilgram. |
66596
|
Wed Nov 11 19:45:19 2009 |
| David Spindler | dsspindler@gmail.com | Bug report | Windows | 2.7.7 2246 | Re: 2.7.6 and 2.7.7 crash upon opening logbook that runs on 2.7.5 |
Stefan Ritt wrote: |
David Spindler wrote: |
I upgraded 2.7.5 rev 2175 to 2.7.7 rev 2246 last Thursday. I tested it with several logbooks with no problems. However I received a rep[ort today that it was down. I discovered whenever I tried to open a logbook entitled "Equipment Reservation" in the folder "EquipmentReservations" Elog would crash. I checked the elog.log file with no entries in it other than showing when it was restarted. I backed up to 2.7.5 and had no porblems with the same logbook. I repeated the upgrade to 2.7.7 with the crash problem returning. I am now back on 2.7.5 with no problems.
I just decided to try 2.7.6 rev 2239 and had the same results as 2.7.7.
This is running under Win2K with SP4 as an automatic service on port 80.
I am also running Elog V2.7.4-2118 on a different port (8080) simultaneously with no problems.
If you wish I will send the elog.cfg file. Anything else I can do to help, please let me know.
|
I need to reproduce your problem. Therefore I need the configuration and the xxxxxxa.log file containing the offending entries. You can strip it down to the minimum needed to do the crash.
|
In the process of trying to reduce it to a minimum I discovered that the entry that appears to be causing the crash is this:
|
66595
|
Tue Nov 10 21:36:21 2009 |
| soren poulsen | soren.poulsen@cern.ch | Question | Linux | 2.7.7 | Re: Automatically generated incrementing tags (#) |
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. |
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. |
66593
|
Tue Nov 10 14:56:07 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.7.6-2236 | Re: Elog & SSL Export to CSV , Problem |
Chuck Brost wrote: |
Stefan, would it be possible to make the following change so that the document is not cached and at the same time it is possible to save it.
The change would entail replacing the "Pragma: no-cache" directive with an "Expires: " <HTTP-date> where <HTTP-date> is the same as Date header value. Please see section 14.21 of http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Hopefully there are no other side effects to this change.
|
ok, so I removed the "Pragma: no-cache". With IE it looks fine now, and if I repeat it two times it always gets is from elog and not from the cache due to the "Expires:" statement. The "no-cache" came from old days when some browsers did not yet support the "Expires" tag. I hope that this is better now, so let's see when we get the first complaints. The modification is in SVN revision 2265. |
66592
|
Tue Nov 10 14:42:11 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.7 | Re: Automatically generated incrementing tags (#) |
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. |