No. The other criteria are used to find the record but any value of the entry ID field is ignored when it is setting all the field values (unless it is a new record in which case the entry ID is used based on the criteria you specify in the merge operation – create a new, retain old.
Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: Friday, April 10, 2015 1:01 PM To: [email protected] Subject: Re: Row - level permissions ** Purely from a academic point of view, can the value of field 1 be change by a merge operation? For example importing an arx and using another field to identify a match. I haven't tried but was just wondering if that is an exception where the value can be changed. On Fri, Apr 10, 2015 at 11:26 AM, Mueller, Doug <[email protected]<mailto:[email protected]>> wrote: ** Just to confirm what has been discussed here. For row level security, having access to field 1 simply makes that row visible to the user. Whether the permission setting is view or change is not important and not considered and not significant to row level security. Just that you have access so you can see the row. You then need to have appropriate permissions to fields where you can define that some fields are accessible and others are not even if you can see the row and you can separately control read and change access to each field. It has ALWAYS been this way. Permissions of a field are for that field. Row level security and access to field 1 are simply controlling whether you can see a record, not what fields you can see or whether you can view or change them. About what does view or change access to field 1 mean? Well, there is no difference. Field 1 is a field you cannot change at the system level. So, giving it change access is really meaningless. Rather than have a special handling and special functionality and messing up the ability to bulk set field permissions and the like, we take the approach of “a field is a field” and you can define whatever permission you want. Then, there may be other things that control or limit or manage the permissions. So, for field 1, if you say change, we just ignore that and don’t allow the change. Or for some other field, you could say change is allowed, but have workflow that prevents changes. The idea is to have consistency of definitions and capabilities and then to have special limits rather than try and encode all the special limits that may exist in all interfaces and interactions. So, this note is just to confirm the responses that have been given about this topic and to address the final question about what Change access to field 1 means and why it is allowed to be set. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of LJ LongWing Sent: Friday, April 10, 2015 11:17 AM To: [email protected]<mailto:[email protected]> Subject: Re: Row - level permissions ** Kanhu, Row Level Security is exactly that, by assigning permissions to field 1, you are defining who has access to a row...it's not limited to submitter/assignee, it's any group that you want to be able to see the row, this includes implicit/regular/dynamic/etc Yes...if they have a 'write' license, and access to the form/row, AND they have change access to a field they can modify a record/field. Now...in Andrew's situation, he asked for group_a to be able to change, but group_b he wanted to only be able to create, and view. So, what he needs to do is Set 'allow any user to submit' to yes, thus allowing all users to create records He then needs to set A as a change user on all fields and B as a view user on all fields That should provide him with his requirements....row level permissions don't define an ability to view/change a record, only 'view' a record. On Fri, Apr 10, 2015 at 12:05 PM, kanhu mohapatra <[email protected]<mailto:[email protected]>> wrote: ** Hello Folks, What I understood, Row level security is, only submitter and assignee can able to see and modify request they created and assigned respectively. I.e at database level a single row which is a request in ARS. So I may have been wrong on submitter mode. But if user have fixed or floating license they can modify ticket, if they have permission on fields and of course on the form. So in Andy use case, user of both group have access to the form and fields And also allow all user to submit, if yes. We are explicitly allowing any use to submit. So I believe it should be No. And I would request all folks correct me if I am wrong. Best regards, Kanhu. On Apr 10, 2015 11:07 PM, "Andrew Hicox" <[email protected]<mailto:[email protected]>> wrote: ** Thanks everyone! I was aware of "allow any user to submit" (in fact was using this feature, which may have contributed confusion). We're using locked submitter mode, but I don't think that applies here ... we're not using assignee perms at all on this form, but are using assignee group. I guess I just misunderstood the functionality. Since you can set change perm on field 1, I just presumed that's what it was for, and I guess I must have gotten randomly lucky all these years that other access control methods must have handled business for me. So on that note: why can I set change permission on field 1? What does that mean, if not "let members of this group write to the record?" ... - Andy On Apr 10, 2015 12:23 PM, "kanhu mohapatra" <[email protected]<mailto:[email protected]>> wrote: ** Hello Andrew, Can you please check the "Submitter Mode" whether it is locked or changeable. Row level security depends upon this value keep the value to locked and also give field 1 to submitter and assigne group permission and check Best regards, Kanhu. On Apr 10, 2015 10:32 PM, "Lucero, Michelle" <[email protected]<mailto:[email protected]>> wrote: ** Hi, Andrew: One more thing. In your sample form, are any of the implicit groups listed as having write permission? For Example: • Public • Submitter • Assignee • Assignee Group For Advanced Interface forms we build for SRM, we assign Submitter write permission to everything. For more information about row-level permission, read Controlling access by using implicit groups--Row-level security<https://docs.bmc.com/docs/display/public/ars201401/Controlling+access+by+using+implicit+groups--Row-level+security;jsessionid=59EE45C5A6391DFCCC99E804A01A6D4A> It also includes info about using dynamic groups. Hope this helps, Michelle From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Andrew Hicox Sent: Friday, April 10, 2015 11:37 AM To: [email protected]<mailto:[email protected]> Subject: Re: Row - level permissions ** Good grief! Has it always been this way or have I just misunderstood the feature this whole time? I could swear you used to be able revoke row-level write access by setting assignee group write on field 1 then changing the assignee group. Thanks again, everyone Andy On Apr 10, 2015 11:34 AM, "Jason Miller" <[email protected]<mailto:[email protected]>> wrote: ** Correct, view vs. change permission on field 1 does not have an impact on other fields or the records as a whole. All field will need their permissions individually set to view or change. Fortunately this is pretty easy to do with multiple fields at once in Dev Studio. Jason On Fri, Apr 10, 2015 at 9:26 AM, Andrew Hicox <[email protected]<mailto:[email protected]>> wrote: ** This is not related to multi-tennancy, in the ITSM sense of the term (multiple companies). This is simply row-level access on a form. My (probably inaccurate) understanding, was that setting or revoking change perms for a given group on field 1 set or revoked change permission to that record. As far as I can tell, setting change permission on field 1 is meaningless? I can find nary a mention of setting change perms on field 1 in the documentation for 8.1 (which is what I'm using). Can someone confirm? Thanks, Andy On Apr 10, 2015 11:17 AM, "Raj" <[email protected]<mailto:[email protected]>> wrote: ** Well, I believe what we are talking about is multi-tenancy and multi-tenancy means if a particular user can “see” the data or not – not related to whether the user can modify the data or not. Request Id is not something that end user can modify, well, not unless one turns naughty.. at least that’s the way I see it. Thoughts? -Raj From: Andrew Hicox [via ARS (Action Request System)] [mailto:ml-node+<mailto:ml-node%2B>[hidden email]<http://user/SendEmail.jtp?type=node&node=121312&i=0>] Sent: Friday, April 10, 2015 21:19 To: Hiremath, Raj Subject: Row - level permissions ** I feel like a real dummy asking this question, because it's so basic. My understanding of row - level permissions up to now has been that it is controlled via permissions on field 1 (request id). If a group has read permission, that group can view the request, but not change it. If the group has change access, the group can change the record (presuming the user has access to all of the individual fields they try to change). However, this does not appear to be the case. I created two groups: * group_a * group_b I created two users: * scoob (member of group_a) * shaggy (member of group_b) I created a regular form where group_a and group_b have change permission on all fields, except 'Request ID'. On 'Request ID', group_a has change and group_b has view. So .. I thought shaggy should be able to submit, but not modify. However that's not the case. Shaggy can both submit and modify! So ... ARS seems to only check row level access in a binary manner. You have access or you dont, and write access is controlled at the field level? If this is the case, what does setting change permission on the Request ID signify? Either I've been seriously confused about how this works for the past 18 years, and it's just never been an issue, or maybe something changed along the way ... I dunno. Any comments y'all? -Andy _ARSlist: "Where the Answers Are" and have been for 20 years_ ________________________________ If you reply to this email, your message will be added to the discussion below: http://ars-action-request-system.1.n7.nabble.com/Row-level-permissions-tp121311.html To start a new topic under ARS (Action Request System), email [hidden email]<http://user/SendEmail.jtp?type=node&node=121312&i=1> To unsubscribe from ARS (Action Request System), click here. NAML<http://ars-action-request-system.1.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> -rAJ ________________________________ View this message in context: RE: Row - level permissions<http://ars-action-request-system.1.n7.nabble.com/Row-level-permissions-tp121311p121312.html> Sent from the ARS (Action Request System) mailing list archive<http://ars-action-request-system.1.n7.nabble.com/> at Nabble.com. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ ________________________________ This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "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"
