Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 337 of 808  Not logged in ELOG logo
    icon2.gif   Re: Read Validation, posted by Stefan Ritt on Sat Apr 2 17:56:04 2016 

Unfortunately a read confirmation is not foreseen in the Elog system. You would have to define one attribute for each shift worker, like "John has read", "Steve has read" and so on. Then each of the shift workes has to "Edit" each message an check his/her checkmark manually.

Stefan

Ed Strohak wrote:

 I'm looking for config examples of a shift log book where operators have to check a box or select their name from a list to prove they have read the latest entries in the log, can anyone help.

 

  Thanks for your time.

 

Ed..

 

    icon2.gif   Re: Read Validation, posted by David Pilgram on Sat Apr 2 21:21:04 2016 

As a variant of what Stefan has suggested:

Perhaps a simple comment is set up as the pre-loaded reply - perhaps including date and time.  Maybe include the author's name in the comment, but all that is available anyway (see documentation for that).  This bit isn't vital.

Then each user simply has to *reply* to the message concerned, and you then get the list of who has read it, available in threaded view of the comment and replies.

Of course this works best with small numbers of users, and where threads are never very long.  Also, it means that you can lock the original message (prevent it being edited) which may be a particular concern depending on what you are using elog for.

You might also want to define an attribute that a reader can tick to say that they have taken action if it is important that someone has to take further action (as opposed to just reading) - and maybe that changes the colour of the background or the icon in front of the topic.  Then there would be a record as to who has done the necessary, and later readers will know the matter is for information rather than needing attention.   For example,. who kicked the power supply to the ion source on Monday morning to "wake it up" (this is true, but pre-elog, so was a paper record).  John kicked it last Monday, and the power supply respects John, may be a statistic one could find from such information recorded as suggested here.

You may want a second attribute people have to explicity select so as to show they understand what they've read, rather than just reply/submit without having read... e.g. they have to select a digit of the ticket number, or some auto-generated number (or letter, I'm not characterist) that is within the original comment.

We all know people who click on things they've never read, and come on, we've all done it at times...

 

David.

Stefan Ritt wrote:

Unfortunately a read confirmation is not foreseen in the Elog system. You would have to define one attribute for each shift worker, like "John has read", "Steve has read" and so on. Then each of the shift workes has to "Edit" each message an check his/her checkmark manually.

Stefan

Ed Strohak wrote:

 I'm looking for config examples of a shift log book where operators have to check a box or select their name from a list to prove they have read the latest entries in the log, can anyone help.

 

  Thanks for your time.

 

Ed..

 

 

    icon2.gif   Re: Read Validation, posted by Ed Strohak on Mon Apr 4 13:05:55 2016 

Appreciate the help..

Thanks

David Pilgram wrote:

As a variant of what Stefan has suggested:

Perhaps a simple comment is set up as the pre-loaded reply - perhaps including date and time.  Maybe include the author's name in the comment, but all that is available anyway (see documentation for that).  This bit isn't vital.

Then each user simply has to *reply* to the message concerned, and you then get the list of who has read it, available in threaded view of the comment and replies.

Of course this works best with small numbers of users, and where threads are never very long.  Also, it means that you can lock the original message (prevent it being edited) which may be a particular concern depending on what you are using elog for.

You might also want to define an attribute that a reader can tick to say that they have taken action if it is important that someone has to take further action (as opposed to just reading) - and maybe that changes the colour of the background or the icon in front of the topic.  Then there would be a record as to who has done the necessary, and later readers will know the matter is for information rather than needing attention.   For example,. who kicked the power supply to the ion source on Monday morning to "wake it up" (this is true, but pre-elog, so was a paper record).  John kicked it last Monday, and the power supply respects John, may be a statistic one could find from such information recorded as suggested here.

You may want a second attribute people have to explicity select so as to show they understand what they've read, rather than just reply/submit without having read... e.g. they have to select a digit of the ticket number, or some auto-generated number (or letter, I'm not characterist) that is within the original comment.

We all know people who click on things they've never read, and come on, we've all done it at times...

 

David.

Stefan Ritt wrote:

Unfortunately a read confirmation is not foreseen in the Elog system. You would have to define one attribute for each shift worker, like "John has read", "Steve has read" and so on. Then each of the shift workes has to "Edit" each message an check his/her checkmark manually.

Stefan

Ed Strohak wrote:

 I'm looking for config examples of a shift log book where operators have to check a box or select their name from a list to prove they have read the latest entries in the log, can anyone help.

 

  Thanks for your time.

 

Ed..

 

 

 

    icon2.gif   Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Mon Sep 18 18:19:44 2006 

Stefan Ritt wrote:

Steve Jones wrote:
The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date


I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate

Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date

and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:



which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour?




Quote:

I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date

In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
    icon2.gif   Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 17:32:28 2006 elogd.cfg

Steve Jones wrote:

I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date

In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.


No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that?
    icon2.gif   Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 19:22:31 2006 

Stefan Ritt wrote:

Steve Jones wrote:

I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date

In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.


No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that?



Quote:

Stefan, when I try that config in a demo logbook in my installation *but with all other items in [global] I get the same field-blanking behavior. I am going to try going back to a completely pristine .cfg, but I suspect this will work fine. I will need to add back in configuration items until I run into the culprit.

Ok, I found it. Try this config:
[global]
port = 8080


[demo]
Comment = Test
Attributes = Author, CRState, ApprovedDate, CompletedDate
Locked Attributes = ApprovedDate, CompletedDate
Type CompletedDate = date
Type ApprovedDate = date

Format CompletedDate = 1
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date

Setting the "Type" to "date" causes the blanking to occur.
    icon2.gif   Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 20:28:15 2006 

Steve Jones wrote:

Setting the "Type" to "date" causes the blanking to occur.


Ok, then don't set the "Type" to "date" Wink
    icon2.gif   Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 20:38:49 2006 

Stefan Ritt wrote:

Steve Jones wrote:

Setting the "Type" to "date" causes the blanking to occur.


Ok, then don't set the "Type" to "date" Wink




Quote:

Yuk! Thanks!

Big grin
ELOG V3.1.5-3fb85fa6