ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67435
|
Wed Feb 13 16:27:18 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.9.1 | Re: Locking a Thread |
Hal Proctor wrote: |
How can I set up the admins or manager group with the ability to Lock a Thread? I don't wish to keep two log books.
|
With
allow <command> = <user list>
deny <command> = <user list>
you can prevent certain users to use certain commands (like delete a message). If you only allow admins to issue the "edit" command, that would in principle do it, but then normal users cannot edit their entries any more. Unfortunately this command cannot be restricted to certain attributes, like the thread "status". So I guess what you want is not exactly possible with the current implementation. |
67434
|
Wed Feb 13 15:39:07 2013 |
| Hal Proctor | hproctor2@gmail.com | Question | Windows | 2.9.1 | Locking a Thread | How can I set up the admins or manager group with the ability to Lock a Thread? I don't wish to keep two log books. |
67433
|
Mon Feb 11 14:21:05 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.9.2-2475 | Re: elog's image manipulation of .png file generated from a pdf/jpg | > Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
> But, this is elog v2.9.0-2435, and I am using v2.9.2-2475. And I remember there was a recent issue about the image manipulation at some point, so I went to the
> download section to read the subversion listing to find where this occurred. But you've changed subversion! I couldn't find my way around it, so I not only could
> I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.
>
> As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it. Do you know when this was? Could it be relivent?
I upgraded to V2.9.2, so please try again.
/Stefan |
67432
|
Sat Feb 9 15:11:19 2013 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 2.9.2-2475 | Re: elog's image manipulation of .png file generated from a pdf/jpg | > > Hi all,
> >
> > Is it just my system or do others have this odd issue.
> >
> > I have a pdf file which is 'upside-down', I attached it to an elog entry, and the .png image thumbnail was
> > generated. Now this too was upside-down, so I tried to use the left (or right) rotation buttons along the top
> > of the image in elog to do a 180 degree rotation.
> > The first 90 degree rotation was fine, but the second attempt just made a smaller image.
> > It happens with various pdf files generated by various software (in case).
> > I also tried it with a jpg file, in that case the second attempt enlarged the image.
> >
> > I could not find any way to actually invert the .png image using elog; but I was surprised that a second
> > rotation ddid something different (change magnification) rather than nothing at all if it could only cope with a
> > 90 degree rotation.
> >
> > It's not a vital fix for me, but I have found the thumbnail (png) manipulation functions have a few rough edges,
> > so when necessary I use xv or gimp on the .png file to get what I want.
> >
> > Or is this just my system?
>
> I just tried on the demo logbook:
>
> https://midas.psi.ch/elogs/Linux+Demo/14
>
> and it worked fine in rotating the image twice. Can you try yourself and find out if it's related to your installation if ImageMagic, or the actual image file?
>
> /Stefan
Hi Stefan,
Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
But, this is elog v2.9.0-2435, and I am using v2.9.2-2475. And I remember there was a recent issue about the image manipulation at some point, so I went to the
download section to read the subversion listing to find where this occurred. But you've changed subversion! I couldn't find my way around it, so I not only could
I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.
As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it. Do you know when this was? Could it be relivent? |
67431
|
Wed Feb 6 18:18:24 2013 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Windows | 2.9 | Re: Re-using IDs after move to another Logbook overwrite Entries |
Stefan Ritt wrote: |
Barend wrote: |
I have tried to use the "Ticket ID" approach and with each new entry this Ticket ID is indeed increased automatically...
But when the last Entry (with the highest Ticket ID i.e. ID-0009) is move to another Logbook, the Ticket ID in the next new entry will be "ID-0009" again (based upon the last previous entry "ID-0008").
So this appraoch will also re-produce duplicate Ticket IDs.
Is it possible to have the Ticket ID preset with value based upon the Date & Time of the entry? Instead of holding a Date/Time format, use a calculated numeric format?
This way, each new entry will have a truely unique Ticket ID.
Thanks & Regards, Barend
|
Why do you move the last ticket in a logbook at all? The move functionality was more meant as an archive option, where you can archive old entries on an annual basis or so. If you just want to "close" a ticket for example, an attribute "Status" with options "open" and "close" will do it. Together with a quick filter you can easily show only open entries in an logbook that way.
Stefan
|
In the documentation:
>In addition to the #'s one may specify format specifiers which are passed to the strftime function. This allows to create tags wich contain the current year, month >and so on. Once the date part of the attribute changes, the index restarts from one. The statement
>Subst Number = XYZ-%Y-%b-###
>results in automatically created attributes
"Number"
of the form
>XYZ-2005-Oct-001
>XYZ-2005-Oct-002
>XYZ-2005-Oct-003
A little playing around with the %[Alpha character] s of strftime probably will generate a format that will suit your requirement - to the second if needs be.
For example I've checked that
Preset Ticket = T%y%m%d%H%M%S#
Generates a ticket number T1302061705141 at that particular moment.
Unfortuately for this to work, you have to have the "#" suffix, which will add a trailling "1" at the end of every ticket (unless you generate two new entries within a second of each other). There are plenty of ways to format all this available in strftime, and unless you keep changing the clock on your computer (which I am guilty of), the ticket numbers can be as unique as you care to make them, and sequentially increasing.
Having said that, I share the view with Stefan that the problem is moving a thread or entry to another logbook rather too early. Personally I keep a thread in the current log book for at least a month after it is "closed" before I move it, although partly that's because sometimes these threads come back to life. Although also because I ran into the same issue (moving the latest entry and finding the ID duplicated), and, realising the problem, then took the "wait" option to solve it.. |
67430
|
Wed Feb 6 13:25:33 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.9.2-2475 | Re: elog's image manipulation of .png file generated from a pdf/jpg | > Hi all,
>
> Is it just my system or do others have this odd issue.
>
> I have a pdf file which is 'upside-down', I attached it to an elog entry, and the .png image thumbnail was
> generated. Now this too was upside-down, so I tried to use the left (or right) rotation buttons along the top
> of the image in elog to do a 180 degree rotation.
> The first 90 degree rotation was fine, but the second attempt just made a smaller image.
> It happens with various pdf files generated by various software (in case).
> I also tried it with a jpg file, in that case the second attempt enlarged the image.
>
> I could not find any way to actually invert the .png image using elog; but I was surprised that a second
> rotation ddid something different (change magnification) rather than nothing at all if it could only cope with a
> 90 degree rotation.
>
> It's not a vital fix for me, but I have found the thumbnail (png) manipulation functions have a few rough edges,
> so when necessary I use xv or gimp on the .png file to get what I want.
>
> Or is this just my system?
I just tried on the demo logbook:
https://midas.psi.ch/elogs/Linux+Demo/14
and it worked fine in rotating the image twice. Can you try yourself and find out if it's related to your installation if ImageMagic, or the actual image file?
/Stefan |
67429
|
Wed Feb 6 13:22:53 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.9 | Re: Re-using IDs after move to another Logbook overwrite Entries |
Barend wrote: |
I have tried to use the "Ticket ID" approach and with each new entry this Ticket ID is indeed increased automatically...
But when the last Entry (with the highest Ticket ID i.e. ID-0009) is move to another Logbook, the Ticket ID in the next new entry will be "ID-0009" again (based upon the last previous entry "ID-0008").
So this appraoch will also re-produce duplicate Ticket IDs.
Is it possible to have the Ticket ID preset with value based upon the Date & Time of the entry? Instead of holding a Date/Time format, use a calculated numeric format?
This way, each new entry will have a truely unique Ticket ID.
Thanks & Regards, Barend
|
Why do you move the last ticket in a logbook at all? The move functionality was more meant as an archive option, where you can archive old entries on an annual basis or so. If you just want to "close" a ticket for example, an attribute "Status" with options "open" and "close" will do it. Together with a quick filter you can easily show only open entries in an logbook that way.
Stefan |
67428
|
Thu Jan 24 10:42:13 2013 |
| Barend | office@amtc2.com | Question | Windows | 2.9 | Re: Re-using IDs after move to another Logbook overwrite Entries |
Stefan Ritt wrote: |
David Pilgram wrote: |
Barend wrote: |
Hi Stefan,
I have observed following behavior when I move entries from one logbook to another:
- The first entry in "Open" get ID "1"
- When I move this Item to "Closed", it will keep ID "1" as I have used "Preserve IDs = 1"
- A new entry in "Open" gets ID "1" again
- When I move this item to "Closed" it will overwrite the previous ID "1" in "Closed"
- A new entry in "open" gets ID "1" again....
Every new entry in "Open" will get the next higher ID Number related to the highest available ID number/entry in "Open".
Upon "move to Closed", the previous entries in "Closed"will be overwritten.
Is there a way to prevent the usage of a previously used ID Number when entering a new ID?
I.e. If an entry with ID "1" has been used in "Open" and moved to "Closed", have the next entry in "Open" use ID "2"?
Kind regards,
Barend
|
Hi Barend,
The counting of entries, or even "tickets", only works within a particular logbook. If you archive a set of entries to another [archive] logbook, the archived set disappears from view of the original logbook. Should that entry, from logbook to archive, be the *latest* thread, then there is the danger of over-writing message ID, Ticket No and the like.
My policy to prevent the problem is to archive only threads that are say (depending upon use) a month after last entry..
|
I generally consider using the ID as ticket number a bad idea. The ID is the "primary key" (in terms of database language), and must be unique inside a logbook. So when moving entries between logbooks, there will be always problems.
Why don't you define an attribute "Ticket ID" and use that one? That won't change when you move the entry between logbooks:
Attributes = Ticket ID, Subject, ...
Preset Ticket ID = ID-#####
|
Hi All,
I have tried to use the "Ticket ID" approach and with each new entry this Ticket ID is indeed increased automatically...
But when the last Entry (with the highest Ticket ID i.e. ID-0009) is move to another Logbook, the Ticket ID in the next new entry will be "ID-0009" again (based upon the last previous entry "ID-0008").
So this appraoch will also re-produce duplicate Ticket IDs.
Is it possible to have the Ticket ID preset with value based upon the Date & Time of the entry? Instead of holding a Date/Time format, use a calculated numeric format?
This way, each new entry will have a truely unique Ticket ID.
Thanks & Regards, Barend |
|