ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68297
|
Sat Apr 2 17:56:04 2016 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | latest | Re: Read Validation | 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..
|
|
68298
|
Sat Apr 2 21:21:04 2016 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Windows | latest | Re: Read Validation | 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..
|
|
|
68299
|
Mon Apr 4 13:05:55 2016 |
| Ed Strohak | estrohak@gmail.com | Question | Windows | latest | Re: Read Validation | 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..
|
|
|
|
1936
|
Mon Sep 18 18:19:44 2006 |
| Steve Jones | steve.jones@freescale.com | Question | All | 2.6.2-1714 | Re: Re: Why are Preset fields blanked out? |
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.
|
|
1941
|
Tue Sep 19 17:32:28 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | 2.6.2-1714 | Re: Re: Why are Preset fields blanked out? |
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? |
1942
|
Tue Sep 19 19:22:31 2006 |
| Steve Jones | steve.jones@freescale.com | Question | All | 2.6.2-1714 | Re: Re: Why are Preset fields blanked out? |
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.
|
|
1943
|
Tue Sep 19 20:28:15 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | 2.6.2-1714 | Re: Re: Why are Preset fields blanked out? |
Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date"  |
1945
|
Tue Sep 19 20:38:49 2006 |
| Steve Jones | steve.jones@freescale.com | Question | All | 2.6.2-1714 | Re: Re: Why are Preset fields blanked out? |
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"  |
Quote: |
Yuk! Thanks!

|
|
|