Re: Re: $datetime display, posted by Stefan Ritt on Fri May 19 12:19:38 2006
|
| Fergus Lynch wrote: | Apologies for being so dense but try as I might I cannot get the $datetime display to show only Day, Month , Year,hour and minutes, NOT seconds.
I dont nee the seconds display!
Could you please clarify the systax for me. |
Can you show me the elogd.cfg syntax you try to use? |
|
Re: Re: $datetime display, posted by Fergus Lynch on Fri May 19 14:01:34 2006
|
| Stefan Ritt wrote: |
| Fergus Lynch wrote: | Apologies for being so dense but try as I might I cannot get the $datetime display to show only Day, Month , Year,hour and minutes, NOT seconds.
I dont nee the seconds display!
Could you please clarify the systax for me. |
Can you show me the elogd.cfg syntax you try to use? |
Hi There!
See in bold below (I'm sure this is me being dense, so thanks for quick reply)
Fergus
Theme = default
Comment = Recording work carried out on any core system
Time format = %B %d, %Y, %H:%M
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type, Status |
|
Re: Re: $datetime display, posted by Stefan Ritt on Sat May 20 09:48:52 2006
|
| Fergus Lynch wrote: |
| Stefan Ritt wrote: |
| Fergus Lynch wrote: | Apologies for being so dense but try as I might I cannot get the $datetime display to show only Day, Month , Year,hour and minutes, NOT seconds.
I dont nee the seconds display!
Could you please clarify the systax for me. |
Can you show me the elogd.cfg syntax you try to use? |
Hi There!
See in bold below (I'm sure this is me being dense, so thanks for quick reply)
Fergus
Theme = default
Comment = Recording work carried out on any core system
Time format = %B %d, %Y, %H:%M
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type, Status |
What about
Time format = %B %d, %Y, %H:%M:%S |
|
Re: Re: $datetime display, posted by Fergus Lynch on Mon May 22 10:37:36 2006
|
| Stefan Ritt wrote: |
| Fergus Lynch wrote: |
| Stefan Ritt wrote: |
| Fergus Lynch wrote: | Apologies for being so dense but try as I might I cannot get the $datetime display to show only Day, Month , Year,hour and minutes, NOT seconds.
I dont nee the seconds display!
Could you please clarify the systax for me. |
Can you show me the elogd.cfg syntax you try to use? |
Hi There!
See in bold below (I'm sure this is me being dense, so thanks for quick reply)
Fergus
Theme = default
Comment = Recording work carried out on any core system
Time format = %B %d, %Y, %H:%M
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type, Status |
What about
Time format = %B %d, %Y, %H:%M:%S |
Thanks, did the trick and working perfectly (I was being dense!) |
|
Re: Re-using IDs after move to another Logbook overwrite Entries, posted by David Pilgram on Thu Jan 10 22:07:10 2013
|
| 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..
|
|
Re: Re-using IDs after move to another Logbook overwrite Entries, posted by Stefan Ritt on Fri Jan 11 08:17:37 2013
|
| 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-#####
|
|
Re: Re-using IDs after move to another Logbook overwrite Entries, posted by Barend on Thu Jan 24 10:42:13 2013
|
| 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 |
|
Re: Re-using IDs after move to another Logbook overwrite Entries, posted by Stefan Ritt on Wed Feb 6 13:22:53 2013
|
| 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 |
|