Re: Standard login Screen - bottom text, posted by Barend on Thu Oct 30 21:14:32 2008
|
Stefan Ritt wrote: |
Barend wrote: |
Hi Stefan.
I have been "playing" around with this great tool and found an interesting "issue" ...
I use multiple logbooks and have both "Protect Selection page = 1" and "Expand Selection Page = 1".
When I open my elog, I get a Standard Login Screen with the Standard Bottom Text "ELOG V2.7.5-2130" which will link to your this website.
When I "Logout" and "Login" again from the Logbook page, I get another Login Screen with my own "Bottom text login" which will link to my own elog page.
How can I apply my own Bottom Text to the Standard Login Screen ?
Thanks & Regards, Barend
|
By using the configuration option "Bottom Text Login = ..."
|
Stefan,
I have defined the "Bottom Text Login = ..." in each Logbook Configuration section. But when I use this option in the Global Section, ELOG fails to start.
Barend
|
Re: Standard login Screen - bottom text, posted by Barend on Mon Dec 29 17:27:13 2008
|
Stefan Ritt wrote: |
Barend wrote: |
Stefan,
I have defined the "Bottom Text Login = ..." in each Logbook Configuration section. But when I use this option in the Global Section, ELOG fails to start.
Barend
|
That's strange. I just tried myself following configuration file:
[global]
port = 8080
Bottom text = Hello
Bottom text login = Login Hello
Password file = passwd
[demo1]
Comment = General linux tips & tricks
Attributes = Author, Type, Category, Subject
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
Page Title = ELOG - $subject
[demo2]
Comment = General linux tips & tricks
Attributes = Author, Type, Category, Subject
and everything works fine as can be seen from the login screen:

so can you check if above file works for you?
|
Hi Stefan,
Hope you have enjoyed the Christmas week.
Sorry for the delay.... I have tested your configuration and it worked for me as well.
In order to determine, which of my settings is causing the problem, I had to activate each individual entry "one by one" and check if the error re-occured. I finally identified following entry "Protect Selection page = 1"
The error also occurs if I change your configuration into:
[global]
port = 8080
Bottom text = <center>Hello</center>
Bottom text login = <center>Login Hello</center>
Password file = passwd
Protect Selection page = 1
[demo1]
Comment = General linux tips & tricks
Attributes = Author, Type, Category, Subject
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
Page Title = ELOG - $subject
[demo2]
Comment = General linux tips & tricks
Attributes = Author, Type, Category, Subject
Can you advise if I'm missing an entry in order for "Protect Selection page = 1" to work?
"Schönen Rutsch ins neue Jahr".
Regards,
Barend |
Hide/Un-hide Commands based on Attribute Option value, posted by Barend on Wed Jan 2 14:04:41 2013
|
Hi Stefan,
Happy New Year!
I ran several searches thru the forum but I could not detect a suitable entry on the following:
Is it possible to hide/un-hide the Commands, like "Edit", "Reply", "Duplicate", from the Menu based upon an Option of an Attribute?
E.g. Attributes = Status, .. | Options Status = Open, Closed
When Status = "Open"; the Menu Commands "Edit", "Reply" and "Duplicate" are available.
When Status = "Closed"; the Menu Commands "Edit", "Reply" and "Duplicate" are hidden/not available.
-or-
Can this only be accomplished using 2 Logbooks (Open / Closed) and move an entry from "Open" to "Closed" where the Logbook "Closed" is not using the Commands "Edit", "Reply", "Duplicate".
Kind regards,
Barend |
Re-using IDs after move to another Logbook overwrite Entries, posted by Barend on Wed Jan 2 15:38:19 2013
|
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 |
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 |
Importing XML/CSV, posted by Barend on Tue Oct 8 18:14:20 2013
|
Hi Stefan,
I'm experiencing problems importing XML (.csv is not working at all for me).
My logbook contains 3 date-attributes besides the system DATE (entry time), date-format is defined as %d %b %y.
The XML file hold the date format "DD.MM.YYYY"
- During "preview" I see that all entries are listed.
- During the import I get the "wrong date format" error.
- When I review the Summary, I see that only the first XML entry (all 3 date-attributes hold a date) was imported.
- When I try to re-import the XML from the second entry (after removing the 1st entry from XML - this second entry hold NO date-value on one of the date-attributes) the elogd.exe crashes and I get the "Service Temporarily Unavailable" error page.
- When I try to re-import the XML from the modified second entry (after removing the 1st entry from XML - this second entry holds date-value on all of the date-attributes) the elogd.exe crashes and I get the "Service Temporarily Unavailable" error page.
Any suggestion what could be wrong? Is it the missing date-value? |
Re: Importing XML/CSV, posted by Barend on Sun Oct 13 16:32:05 2013
|
Andreas Luedeke wrote: |
Barend wrote: |
Hi Stefan,
I'm experiencing problems importing XML (.csv is not working at all for me).
My logbook contains 3 date-attributes besides the system DATE (entry time), date-format is defined as %d %b %y.
The XML file hold the date format "DD.MM.YYYY"
- During "preview" I see that all entries are listed.
- During the import I get the "wrong date format" error.
- When I review the Summary, I see that only the first XML entry (all 3 date-attributes hold a date) was imported.
- When I try to re-import the XML from the second entry (after removing the 1st entry from XML - this second entry hold NO date-value on one of the date-attributes) the elogd.exe crashes and I get the "Service Temporarily Unavailable" error page.
- When I try to re-import the XML from the modified second entry (after removing the 1st entry from XML - this second entry holds date-value on all of the date-attributes) the elogd.exe crashes and I get the "Service Temporarily Unavailable" error page.
Any suggestion what could be wrong? Is it the missing date-value?
|
Can you post your elog configuration file (elog.cfg)?
⇄
Detect language » English
|
Hi Andreas,
I had to filter-out some other logbook. Please find attached the configuration section for the affected logbook "UMOWY".
Looking forward to your review.
Regards, Barend |
Error: Attribute <date> not supplied., posted by Barend on Mon Oct 14 12:08:16 2013
|
Stefan/Andreas,
When I reply to an existing Logbook entry, I get the error page "Error: Attribute Audit Date not supplied. Please go back and enter the Audit Date field."
The configuration file uses:
Required Attributes = Audit No, Audit Date, Audit Type, Finding No, Finding Level, Section, MOE Procedure, Finding Details, Auditor, Deadline, Responsibility
Fixed Attributes Reply = Audit No, Audit Date, Audit Type, Finding No, Finding Level, Section, MOE Procedure, Finding Details, Auditor, Deadline, Responsibility
Type Audit Date = date
Type Deadline = date
The combination "Required Attributes" and "Fixed Attributes Reply" does not work for date-fields.
As soon as I disclose the date fields from either "Required Attributes" or "Fixed Attributes Reply" the error is no longer evident.
But I want the "Audit Date" and "Deadline" to entered during a new Record and they shall not be changed during a reply.
Is this a bug -or- do I have to change the configuration?
Thanks & regards, Barend |
|