Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 148 of 807  Not logged in ELOG logo
icon5.gif   hyperlink to file, posted by Diego on Tue Jan 8 20:02:04 2013 

 Hi,

I would like to make an hyperlink to an external file in a messaje. I have writen Allow (HTML = 1) in .cfg file and the hyperlink as

<p><a href="file:\\external_computer\directory">test</a></p>

It did not work. However if I write in the chrome browser:

file:\\external_computer\directory

It works.

Thank you so much!!

 

    icon2.gif   Re: hyperlink to file, posted by Stefan Ritt on Wed Jan 9 10:12:14 2013 

Diego wrote:

 Hi,

I would like to make an hyperlink to an external file in a messaje. I have writen Allow (HTML = 1) in .cfg file and the hyperlink as

<p><a href="file:\\external_computer\directory">test</a></p>

It did not work. However if I write in the chrome browser:

file:\\external_computer\directory

It works.

Thank you so much!!

 

A link to a local file inside a web page does never work on purpose. Malicious web pages could otherwise get access to your local password file for example which would be a huge security hole. You have to copy the link address explicitly into your URL bar of the browser.

    icon2.gif   Re: Main Logbook screen with Multi Grouped Logbooks with unique user permissions, posted by Stefan Ritt on Thu Jan 10 10:52:11 2013 

Hal Proctor wrote:

I have a couple questions on how to configure multiple logbooks with groups.

  1. How can I have a user have permissions to a single logbook that is within a group and jump to it using tabs?
    1. Launching from main/home screen may work, but using tabs from one group to another where the single workbook resides in a group of others, it errors out or asks for login to a logbook you may not have rights to.(always the first book in the group)
  2. How can I force a main login to direct you to the MAIN logbook selection screen?

 

Example: (use images for reference)  A user has permissions to "Punch" and "Maintenance".  Maintenance is a single logbook and Punch is within the group "Dry Room". 

While the user is in Maintenance and without having to jump back to the MAIN selection screen, how can the user select the Tab "Dry Room" as seen in image, without throwing up or redirecting you?

There are several options:

  • Use a bookmark in your browser. Put a link directly "Punch" and "Maintenance" in the link list of your browser and you can directly jump to that logbook. Different users can define different bookmarks in their browsers.
  • Change the order of the logbooks in the group, like put "Punch" to be the first one in your group. But if you have different users with different permissions this will of course not work for all.
  • Give up groups and just keep a linear list of logbooks. 

2. is not possible. Even if you use "Protect selection page", you will always be redirected to the first logbook after logging in. Maybe I should change that.

 

    icon2.gif   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:

  1. The first entry in "Open" get ID "1"
  2. When I move this Item to "Closed", it will keep ID "1" as I have used "Preserve IDs = 1"
  3. A new entry in "Open" gets ID "1" again
  4. When I move this item to "Closed" it will overwrite the previous ID "1" in "Closed"
  5. 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..

 

 

    icon2.gif   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:

  1. The first entry in "Open" get ID "1"
  2. When I move this Item to "Closed", it will keep ID "1" as I have used "Preserve IDs = 1"
  3. A new entry in "Open" gets ID "1" again
  4. When I move this item to "Closed" it will overwrite the previous ID "1" in "Closed"
  5. 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-#####

 

icon1.gif   Dual Time display and entry times, posted by Bruce Weber on Mon Jan 14 03:05:41 2013 

ELog has been installed on our local server which runs on local time (UTC +8) and is working well, however, we work in two time zones.

Our PC's run in local time (IT requirement) but need to save and display one log in UTC and one log in local time - can this be done?

Appreciate anyones help!

Thanks

    icon2.gif   Re: Dual Time display and entry times, posted by Yoshio Imai on Mon Jan 14 13:33:19 2013 
Depending on whether I understand your requirement correctly, the following solution should work:
  • define an additional logbook attribute, say "UTC Date"
  • preset it on entry creation and submission with the UTC timestamp (cf. section "Attributes" of the ELog configuration guide):
    Preset UTC Date = $utcdate
    Subst UTC Date = $utcdate
  • prevent the attribute from being changed manually by adding it to the
    Locked Attributes = < ... >
    and
    Fixed Attributes Edit = < ... >
    lists, respectively.
    You may also have to add it to the
    Remove on reply = < ... >
    list if replies turn out to keep the "UTC Date" value of the original entry.

Regards,
    icon2.gif   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:

  1. The first entry in "Open" get ID "1"
  2. When I move this Item to "Closed", it will keep ID "1" as I have used "Preserve IDs = 1"
  3. A new entry in "Open" gets ID "1" again
  4. When I move this item to "Closed" it will overwrite the previous ID "1" in "Closed"
  5. 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 

ELOG V3.1.5-3fb85fa6