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:[email protected]] On Behalf Of Misi Mladoniczky Sent: Tuesday, March 08, 2016 1:30 PM To: [email protected] 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:[email protected]] On Behalf Of Misi Mladoniczky > Sent: Tuesday, March 08, 2016 1:22 AM > To: [email protected] > 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"
