Ho Doug,
To me this seems like a very good solution.
You do it only if a permission issue is encountered.
Best Regards - Misi, RRR AB, http://rrr.se
> Misi,
>
> I don't remember the exact version this was introduced in, but it was by 8.1
> timeframe I am pretty sure.
>
> Yes, it does involve an extra DB fetch to see if the values are correct. But,
> you WANT me to do that.
>
> Let me go through the old and new scenario....
>
> OLD
>
> Receive a Set call
> See if you are setting a value to a field you don't have permission to.
> If no, continue.
> If yes, ERROR and terminate the operation so that the user cannot proceed.....
>
> New
>
> Receive a Set call
> See if you are setting a value to a field you don't have permission to.
> If no, continue
> If yes,
> Retrieve the record from the DB
> Check values to see if they are different
> If no, continue
> If yes, ERROR and terminate the operation so that the user cannot
> proceed....
>
>
> So, the extra DB call is ONLY if you have entered the error state -- so no
> overhead for other processing. Now, yes, there is extra overhead on the check
> but previously, you got an ERROR and now there is logic that covers for
> sending an unchanged value that you don't have write access to. It does an
> extra (unique indexed) lookup to allow no error to be generated. Of course,
> if you don't send the unchanged values, no lookup, but if you do, you don't
> error any more.
>
> So, I don't consider that a performance issue as you only do something on what
> is already an ERROR condition and we are allowing success on that error
> condition if you have not done anything unsafe so no longer an error....
>
>
> We could always go back and just error without the extra lookup.....
>
> Doug
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
> Sent: Tuesday, March 08, 2016 1:30 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: ARERR[331] You do not have write access to this record
>
> Hi,
>
> Very good information. I presume this to be a server side change. I would love
> to know exactly when it was introduced.
>
> I also presume that it affects only permission type things, and not for
> example TR-values?
>
> In theory this seems like it would need to do an extra fetch to the database
> to know all TR values corresponding DB value. Possibly affecting performance
> slightly?
>
> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>
> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
>> Misi,
>>
>> Correct as usual... But, note that if you change a field you don't
>> have write access to to the same value as it originally had, there was
>> logic put into I think it was 8.1 and later (although it could have
>> been before that) that actually checks this and if you are not
>> changing the value, it will not issue the error. This is to handle
>> clients that just send all data even if changing only one field. So,
>> you should not get an error if the value is not being changed.
>>
>> All other notes you have mentioned here are correct and are things to look
>> at.
>>
>> Doug
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
>> Sent: Tuesday, March 08, 2016 1:22 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Re: ARERR[331] You do not have write access to this record
>>
>> Hi,
>>
>> But if Assignee and Submitter (and Public) has Read access to the
>> fields #1 and #2, no one except and Administrator can change that field.
>>
>> The fields could be set by filters or have "allow anyone to submit" enabled.
>>
>> So do you change these fields manually?
>>
>> It can also be a an Active Link that sets the values of these field.
>> The fields will be treated as changed even if the Active Link sets it
>> to the same value as it originally had.
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>> 2011)
>>
>> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
>> Find these products, and many free tools and utilities, at http://rrr.se.
>>
>>> Assignee and Submitter groups have Read permission (View) for those fields.
>>> Assigned To field is never getting set even after modifying the record.
>>>
>>> There are two records with the same submitter,and assigned to fields
>>> but only the summary field differs.
>>> If it is a permission issue, why it occurs on only one record? Any idea?
>>>
>>> Thanks!
>>> Kaur
>>>
>>> _____________________________________________________________________
>>> _ _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> "Where the Answers Are, and have been for 20 years"
>>>
>>
>> ______________________________________________________________________
>> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> "Where the Answers Are, and have been for 20 years"
>>
>> ______________________________________________________________________
>> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> "Where the Answers Are, and have been for 20 years"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers
> Are, and have been for 20 years"
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
