Thank you Misi, For detail Clarification.
Best Regads, Kanhu Mohapatra. On Mon, Apr 13, 2015 at 4:25 PM, Misi Mladoniczky <m...@rrr.se> wrote: > Hi Andrew, > > Nothing much has been said about row level access in this thread. The > initial > question actually has nothing to do with row level access, it only > concerned > permissions affecting all records: > > A. If group_a/b has change/read access to Field 1, members can search all > records in your database (not row level access). > > B. To modify records, each individual field has to be granted change-access > for the group in question (not row level access). > > During Submit, as said earlier, you need to have Change access to a field, > or > the field needs to be set to "Allow Any User to Submit". > > Row level type groups like Submitter, Assignee, AssigneeGroup and the 60xxx > groups DOES NOT APPLY AT ALL during Submit operations. > > Another interesting thing is RREAD, READ or FLOATING-READ users, is that if > such a user has been assigned to group_a, which can change a field, this > does > not grant access to do so during creation time... To allow a READ* user to > submit data to a field, the field needs to be set to "Allow Any User to > Submit". > > If we go back to row level access. The Request ID is used to show/hide > records > completely for the row level groups Submitter, Assignee, AssigneeGroup and > the > 60xxx. > > You can then use these row level groups for individual fields to grant > Read or > Change permissions for that field. This is row level access on a field by > field level, as opposed to the Request ID that is only used to show/hide > rows > completely. > > Finally we have the "Submitter Mode Locked" discussion that controls two > things: > 1. It controls if the Submitter-fields can be changed with a > Modify-Operation. > 2. It controls if a READ or FLOATING-READ user can modify records under the > condition that his/her login name occupies the Submitter-field. > > Maybe these things should be posted as a document on BMC Communities? > > 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. > > > 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 > > > > > _______________________________________________________________________________ > > 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"
