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]> 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]] *On Behalf Of *LJ LongWing > *Sent:* Friday, April 10, 2015 11:17 AM > > *To:* [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]> > 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]> 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]> > 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]> 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]] *On Behalf Of *Andrew Hicox > *Sent:* Friday, April 10, 2015 11:37 AM > *To:* [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]> 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]> 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]> 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+[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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
