RE: [Hardhats-members] How to obtain a write access of ^ ?
The use of ^ as a lock is a neat programmer trick to enforce security on a field. It can't be stored in #200 because it will alter the number of pieces in the node (since it is the delimiter, as Kevin noted). It can't even be entered as a lock character through the normal FM field edit functions because it is the abort character when entered at a prompt. And even if you set it into your own DUZ(0), FileMan doesn't honor it. The only way to create it is for a programmer to Set it. Of course a programmer could Kill it or change it but that might have unintended consequences. I suspect that there is a considerable amount of processing associated with entering a provider that is hard coded into the routines and a decision was made that it should not be bypassed no matter what the security level of the user. If that is the case, altering ^DD(2,.104,9) would let you use the field through FM but might cause data integrity issues down the road. It would be nice if the Input Transform, the Triggers and all of the other cross references in the DD covered every business rule associated with a field but that is not the case. Some of the rules are so complex and so dependant on the data entry situation that whole sets of routines are required to carry out the appropriate data updates and linkages. tjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ(AG)=O DUZ(AUTO)=1 DUZ(BUF)=1 DUZ(LANG)=1 GTMd ^XUP Setting up programmer environment Terminal Type set to: C-VT102 Select OPTION NAME: diedit INPUT TO WHAT FILE: NEW PERSON// 2 PATIENT (69454 entries) EDIT WHICH FIELD: ALL// Provider?? EDIT WHICH FIELD: ALL// .104?? EDIT WHICH FIELD: ALL// .1041?? EDIT WHICH FIELD: ALL// Is there something else wrong that I am doing? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: Actually, the @ is a superaccess that should be sufficient for any situation, no matter what the file DD, read, write, delete access code is. In other words, you should not have any difficulty doing anything in any file. Are you having difficulty or are you just anticipating having difficult,
Re: [Hardhats-members] How to obtain a write access of ^ ?
BUFFER ERROR That should have been 'it is a way', not 'it was a
want'. If only I could keep my typing buffer in sync with my thinking
buffer ;-)
Greg Kreis wrote:
Has this been changed? It used to be that you could set DUZ(0)="^" and
it would permit the edit. As mentioned here, it was a want to 'write
protect' a field so that only a trigger could enter the data (a trigger
asks if you want to write protect a field).
Holloway, Thomas (EDS) wrote:
The use of "^" as a lock is a neat programmer trick to enforce
security on a field. It can't be stored in #200 because it will alter
the number of pieces in the node (since it is the delimiter, as Kevin
noted). It can't even be entered as a lock character through the normal
FM field edit functions because it is the "abort" character when entered
at a prompt. And even if you set it into your own DUZ(0), FileMan
doesn't honor it. The only way to create it is for a programmer to Set
it. Of course a programmer could Kill it or change it but that might
have unintended consequences.
I suspect that there is a considerable amount of processing
associated with entering a provider that is hard coded into the routines
and a decision was made that it should not be bypassed no matter what
the security level of the user. If that is the case, altering
^DD(2,.104,9) would let you use the field through FM but might cause
data integrity issues down the road. It would be nice if the Input
Transform, the Triggers and all of the other cross references in the DD
covered every business rule associated with a field but that is not the
case. Some of the rules are so complex and so dependant on the data
entry situation that whole sets of routines are required to carry out
the appropriate data updates and linkages.
tjh
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Chris
Richardson
Sent: Monday, February 14, 2005 2:34 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Stephen;
Then that sounds like the loading of this field is programatic (data
loaded
at the time of the action being recorded) and doesn't use Fileman to
Fill
the field. That would keep most users (except for programmers) from
changing the data. Interesting business rule. I see the value of it.
- Original Message -
From: "steven mcphelan" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 7:50 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
If a field is write protected with the "^" then no DUZ(0) will allow
you
to
edit that field using Fileman enter/edit.
- Original Message -
From: "Nancy Anthracite" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 9:57 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Maybe it is because you don't have a patient who has been admitted!
Note
that
it says inpatient below.
On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote:
I noted that only active providers are allowed, so do your docs
have
the
PROVIDER key and the only thing I could see that might have to do
with
that
and show activity was the PERSON CLASS, in file 200, which has an
expiration date which I believe you can leave blank. Do your docs
have
a
person class of physician or one of those variants?
2,.104PROVIDER .104;1 POINTER TO NEW PERSON
FILE
(#200)
INPUT TRANSFORM: S DIC("S")="I
$$SCREEN^DGPMDD(Y,DA,DT)"
D
^DIC K DIC S DIC=DIE,X=+Y K:Y0 X
LAST EDITED: DEC 07, 1994
HELP-PROMPT: The provider currently assigned to
this
inpatient applicant.
DESCRIPTION: From the available listing select
the
provider who is currently treating this patient.
SCREEN: S DIC("S")="I
$$SCREEN^DGPMDD(Y,DA,DT)"
EXPLANATION: Allow only active providers.
EXECUTABLE HELP: D HELP^DGPMDD(DA,DT)
CROSS-REFERENCE: 2^APR
1)= S ^DPT("APR",$E(X,1,30),DA)=""
2)= K
RE: [Hardhats-members] How to obtain a write access of ^ ?
Greg asked: "Has this been changed?"
I don't know Greg. I just tested it by putting a ^ in
DUZ(0) and that stilldidn't allow me to select the field. Based on
that result,it was an assumption on my part that FileMan doesn't honor
that particular character as a key to unlock the lock. Possibly there was
a flaw in my test?
tjh
"It's a philosophy of life - - go whole hog and
accept the consequences.", Robert Fulghum
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Greg
KreisSent: Monday, February 14, 2005 10:22 AMTo:
hardhats-members@lists.sourceforge.netSubject: Re: [Hardhats-members]
How to obtain a write access of "^" ?
BUFFER ERROR That should have been 'it is a way', not 'it was
a want'. If only I could keep my typing buffer in sync with my thinking
buffer ;-)Greg Kreis wrote:
Has this
been changed? It used to be that you could set DUZ(0)="^" and it would
permit the edit. As mentioned here, it was a want to 'write protect' a
field so that only a trigger could enter the data (a trigger asks if you want
to write protect a field).Holloway, Thomas (EDS) wrote:
The use of "^" as a lock is a neat programmer trick to enforce
security on a field. It can't be stored in #200 because it will alter
the number of pieces in the node (since it is the delimiter, as Kevin
noted). It can't even be entered as a lock character through the normal
FM field edit functions because it is the "abort" character when entered
at a prompt. And even if you set it into your own DUZ(0), FileMan
doesn't honor it. The only way to create it is for a programmer to Set
it. Of course a programmer could Kill it or change it but that might
have unintended consequences.
I suspect that there is a considerable amount of processing
associated with entering a provider that is hard coded into the routines
and a decision was made that it should not be bypassed no matter what
the security level of the user. If that is the case, altering
^DD(2,.104,9) would let you use the field through FM but might cause
data integrity issues down the road. It would be nice if the Input
Transform, the Triggers and all of the other cross references in the DD
covered every business rule associated with a field but that is not the
case. Some of the rules are so complex and so dependant on the data
entry situation that whole sets of routines are required to carry out
the appropriate data updates and linkages.
tjh
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Chris
Richardson
Sent: Monday, February 14, 2005 2:34 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Stephen;
Then that sounds like the loading of this field is programatic (data
loaded
at the time of the action being recorded) and doesn't use Fileman to
Fill
the field. That would keep most users (except for programmers) from
changing the data. Interesting business rule. I see the value of it.
- Original Message -
From: "steven mcphelan" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 7:50 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
If a field is write protected with the "^" then no DUZ(0) will allow
you
to
edit that field using Fileman enter/edit.
- Original Message -
From: "Nancy Anthracite" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 9:57 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Maybe it is because you don't have a patient who has been admitted!
Note
that
it says inpatient below.
On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote:
I noted that only active providers are allowed, so do your docs
have
the
PROVIDER key and the only thing I could see that might have to do
with
that
and show activity was the PERSON CLASS, in file 200, which has an
expiration date which I believe you can leave blank. Do your docs
have
a
person class of physician or one of those variants?
2,.104PROVIDER .104;1 POINTER TO NEW PERSON
FILE
(#200)
INPUT TRANSFORM: S DIC("S")="I
$$SCREEN^DGPMDD(Y,DA,DT)"
D
^DIC K DIC S DIC=DIE,X=+Y K:Y0 X
LAST EDITED: DEC 07, 1994
HELP-PROMPT: The provider currently assigned to
this
inpatient applicant.
DESCRIPTION: From the available listing select
the
provider who is currently treating this patient.
SCREEN: S DIC("S")="I
$$SCREEN^DGPMDD(Y,DA,DT)"
RE: [Hardhats-members] How to obtain a write access of ^ ?
Does this trick offer any advantages over using the Uneditable Data option in Fileman to make the field uneditable? The effect is basically the same: Fileman disallows writes and deletes. --- Holloway, Thomas (EDS) [EMAIL PROTECTED] wrote: The use of ^ as a lock is a neat programmer trick to enforce security on a field. It can't be stored in #200 because it will alter the number of pieces in the node (since it is the delimiter, as Kevin noted). It can't even be entered as a lock character through the normal FM field edit functions because it is the abort character when entered at a prompt. And even if you set it into your own DUZ(0), FileMan doesn't honor it. The only way to create it is for a programmer to Set it. Of course a programmer could Kill it or change it but that might have unintended consequences. I suspect that there is a considerable amount of processing associated with entering a provider that is hard coded into the routines and a decision was made that it should not be bypassed no matter what the security level of the user. If that is the case, altering ^DD(2,.104,9) would let you use the field through FM but might cause data integrity issues down the road. It would be nice if the Input Transform, the Triggers and all of the other cross references in the DD covered every business rule associated with a field but that is not the case. Some of the rules are so complex and so dependant on the data entry situation that whole sets of routines are required to carry out the appropriate data updates and linkages. tjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ(AG)=O DUZ(AUTO)=1 DUZ(BUF)=1 DUZ(LANG)=1 GTMd ^XUP Setting up programmer environment Terminal Type set to: C-VT102 Select OPTION NAME: diedit INPUT TO WHAT FILE: NEW PERSON// 2 PATIENT (69454 entries) EDIT WHICH FIELD: ALL// Provider?? EDIT WHICH FIELD: ALL// .104?? EDIT WHICH FIELD: ALL// .1041?? EDIT WHICH FIELD: ALL// Is there something else wrong that I am doing? Thanks Kevin
RE: [Hardhats-members] How to obtain a write access of ^ ?
Here's an example of what happens when you try to edit an uneditable field. (TEST is both the field name and the .01 field of the record with ien 1, which is a little confusing.) Select MESSAGE TEMPLATE NAME: `1 TEST TEST: U Select MESSAGE TEMPLATE NAME: `1 TEST TEST: U// (No Editing) Select MESSAGE TEMPLATE NAME: --- Greg Woodhouse [EMAIL PROTECTED] wrote: Does this trick offer any advantages over using the Uneditable Data option in Fileman to make the field uneditable? The effect is basically the same: Fileman disallows writes and deletes. --- Holloway, Thomas (EDS) [EMAIL PROTECTED] wrote: The use of ^ as a lock is a neat programmer trick to enforce security on a field. It can't be stored in #200 because it will alter the number of pieces in the node (since it is the delimiter, as Kevin noted). It can't even be entered as a lock character through the normal FM field edit functions because it is the abort character when entered at a prompt. And even if you set it into your own DUZ(0), FileMan doesn't honor it. The only way to create it is for a programmer to Set it. Of course a programmer could Kill it or change it but that might have unintended consequences. I suspect that there is a considerable amount of processing associated with entering a provider that is hard coded into the routines and a decision was made that it should not be bypassed no matter what the security level of the user. If that is the case, altering ^DD(2,.104,9) would let you use the field through FM but might cause data integrity issues down the road. It would be nice if the Input Transform, the Triggers and all of the other cross references in the DD covered every business rule associated with a field but that is not the case. Some of the rules are so complex and so dependant on the data entry situation that whole sets of routines are required to carry out the appropriate data updates and linkages. tjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)=
RE: [Hardhats-members] How to obtain a write access of ^ ?
You've got me, Greg. I was curious about Kevin's issue and just tried a few things. What I wrote is just my observation, I didn't have anything to do with the design, and the things that I work on don't generally require the use of this technique. tjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Monday, February 14, 2005 10:58 AM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] How to obtain a write access of ^ ? Does this trick offer any advantages over using the Uneditable Data option in Fileman to make the field uneditable? The effect is basically the same: Fileman disallows writes and deletes. --- Holloway, Thomas (EDS) [EMAIL PROTECTED] wrote: The use of ^ as a lock is a neat programmer trick to enforce security on a field. It can't be stored in #200 because it will alter the number of pieces in the node (since it is the delimiter, as Kevin noted). It can't even be entered as a lock character through the normal FM field edit functions because it is the abort character when entered at a prompt. And even if you set it into your own DUZ(0), FileMan doesn't honor it. The only way to create it is for a programmer to Set it. Of course a programmer could Kill it or change it but that might have unintended consequences. I suspect that there is a considerable amount of processing associated with entering a provider that is hard coded into the routines and a decision was made that it should not be bypassed no matter what the security level of the user. If that is the case, altering ^DD(2,.104,9) would let you use the field through FM but might cause data integrity issues down the road. It would be nice if the Input Transform, the Triggers and all of the other cross references in the DD covered every business rule associated with a field but that is not the case. Some of the rules are so complex and so dependant on the data entry situation that whole sets of routines are required to carry out the appropriate data updates and linkages. tjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69
Re: [Hardhats-members] How to obtain a write access of ^ ?
I suspect something else must be going on. I tried setting the write protection to ^ (BTW, you can do this because the field sits by itself on a global node in the DD) and, sure enough, DUZ(0)=@ does trump ^, just as Marianne said. If yhou were using DIC, I'd think perhaps you had a pre-selection action. Does the file have a special lookup routine? --- Greg Kreis [EMAIL PROTECTED] wrote: Has this been changed? It used to be that you could set DUZ(0)=^ and it would permit the edit. As mentioned here, it was a want to 'write protect' a field so that only a trigger could enter the data (a trigger asks if you want to write protect a field). Holloway, Thomas (EDS) wrote: The use of ^ as a lock is a neat programmer trick to enforce security on a field. It can't be stored in #200 because it will alter the number of pieces in the node (since it is the delimiter, as Kevin noted). It can't even be entered as a lock character through the normal FM field edit functions because it is the abort character when entered at a prompt. And even if you set it into your own DUZ(0), FileMan doesn't honor it. The only way to create it is for a programmer to Set it. Of course a programmer could Kill it or change it but that might have unintended consequences. I suspect that there is a considerable amount of processing associated with entering a provider that is hard coded into the routines and a decision was made that it should not be bypassed no matter what the security level of the user. If that is the case, altering ^DD(2,.104,9) would let you use the field through FM but might cause data integrity issues down the road. It would be nice if the Input Transform, the Triggers and all of the other cross references in the DD covered every business rule associated with a field but that is not the case. Some of the rules are so complex and so dependant on the data entry situation that whole sets of routines are required to carry out the appropriate data updates and linkages. tjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing.
RE: [Hardhats-members] Adding / Editing patients
Thurman, This will only help you edit them after you have added them. If you want help doing a batch upload, let me know off list. Kevin --- Thurman Pedigo [EMAIL PROTECTED] wrote: This should be a great help to me. I have around 18,000 file I need to convert. Will move me a long way toward complete conversiontx/t -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Nancy Anthracite Sent: Sunday, February 13, 2005 7:21 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Adding / Editing patients Nice going, Kevin! The VistA Office folks might like this once you get your last problem solved. On Sunday 13 February 2005 08:03 pm, Kevin Toppenberg wrote: Hey all, I have some code to offer othes here (if they want it), and some thoughts and questions. First, I wrote some custom code that bulk-created patient records in the PATIENT file. I ported over around 70,000 patients. Now, as I use these patients, I am finding that some tweeking needs to be done... ie. completing the records etc. So I have been trying to decide how best to edit this data. I am comfortable now doing it directly in Fileman. But that wouldn't be good for my receptionists. So I looked at the DG REGISTER... menus. And there I ran into the same problem that Nick was having about the system trying to connect to the MPI. Plus, it was getting to way too many questions (i.e. it was getting ready to admit a patient into the hospital), rather than just editing the patient record. So I have cut, pasted, and trimmed down this code (originally from DGREG.m) to make the following function. It can be called with a parameter=1 if adding new patients is to be allowed. Here is the code. And FYI, it uses a standard VistA screenman based system of editing. (Questions below) EDITPT(AddOK) ;Purpose: Ask for patient name, and allow editing ;Input: AddOK: if 1, adding new patients allowed ;Result: none do LO^DGUTL set DGCLPR= new DGDIV set DGDIV=$$PRIM^VASITE if DGDIV0 set %ZIS(B)=$piece($get(^DG(40.8,+DGDIV,DEV)),U,1) kill %ZIS(B) if '$data(DGIO),$piece(^DG(43,1,0),U,30) do . set %ZIS=N,IOP=HOME . do ^%ZIS A do ENDREG^DGREG($get(DFN)) do if (Y0) goto EditDone . W !! . if $get(AddOK)=1 do . . set DIC=2,DIC(0)=ALEQM . . set DLAYGO=2 . else do . . set DIC=2,DIC(0)=AEQM . . set DLAYGO=0 . kill DIC(S) . do ^DIC . kill DLAYGO . if Y0 quit . set (DFN,DA)=+Y . set DGNEW=$P(Y,^,3) . new Y . do PAUSE^DG10 . do BEGINREG^DGREG(DFN) . if DGNEW D NEW^DGRP if +$get(DGNEW) do . ; query CMOR for Patient Record Flag Assignments if NEW patient and . ; display results. . if $$PRFQRY^DGPFAPI(DFN) do DISPPRF^DGPFAPI(DFN) set (DGFC,CURR)=0 set DA=DFN set DGFC=^1 set VET=$select($data(^DPT(DFN,VET)):^(VET)'=Y,1:0) set %ZIS=N,IOP=HOME do ^%ZIS set DGELVER=0 ;do EN^DGRPD ;if $data(DGRPOUT) do goto A ;. do ENDREG^DGREG($G(DFN)) ;. do HL7A08^VAFCDD01 ;. kill DFN,DGRPOUT ;do HINQ^DG10 if $D(^DIC(195.4,1,UP)) if ^(UP) do ADM^RTQ3 do REG^IVMCQ($G(DFN)) ; send financial query set DGRPV=0 do EN1^DGRP EditDone quit OK, the next issue I need to solve is the actual addition of a NEW patient (i.e. LAYGO). If I supply a new name of a patient, it asks if I want to add a new patient. If I say YES, it goes into roll and scroll mode, asking many more questions than my setting needs, and only comes back to the screenman (nicer) editing screens after aborting with a ^ (and, oh by the way, you have to know how many questions you have to answer before jumping out, or the record is not created). So It seems that an input template might help here. But how would I tell ^DIC to use an input template in event of Laygo? Thanks Kevin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list
