do you have configured list permissions so that only members of the specific group (apart from admins/full control) have read/edit permissions granted?

Thank you for your reply and question.

Yes, I did create permissions so that only group members can enter/edit certain controls on the form.

This issue is a bit complex as there are multiple variables that seem to affect the outcome (undesired results)

1)  Created a SP column Person or Group "Change Manager Assigned" that references a SP group OpRisk Change Managers containing 5 members

• Purpose was to have group members names, addresses, etc from the Active Directory available for tasks, emails, etc.

2) Used the SP People control (not the Nintex People control) on my form.

• The control "Change Manager Assigned" is connected to the SP Person or Group column

3) Once the person (Change Manager) is selected for its own control, I then use that value to manage who can enter values in several other controls, using a Rule that disables the control when any user other than the Change Manager is the Current User.

4) When the form is complete, the form and connections back to the SP list all work as intended.

5) WFs use those value effectively

6) The problem arises when attempting to Edit/View the records (items) from SP.

• Certain unintended behaviors occur "when a user who is not a member of the Group goes to Edit or View the item
• When attempting to View the item, SP returns an Access Denied message

• When opening the item in Edit mode, the field that contains the "Change Manager" value  is presented with a representation of the value from the Active Directory that is related to the person, but is their corporate user code (that is to say, it's not their name which is normally represented in that value.

This is the way the value is presented (same item) when the item is opened to Edit by a member of the Group.

7) After much trial and error experimentation, the problem is remedied when the SP Column is changed to "All Users"

8) That solves the Edit/View problem, but now I cannot restrict the selection of the persons in the form to only that group of 5 persons.  That exposes the risk of selecting persons in the Active Directory who have similar names.

9)  I've been experimenting with the Nintex People control thinking I should not be using the SP People control, but have not finished that testing yet.  One problem with the Nintex People control - if I want to use the SharePoint Group setting under Advanced, the control cannot be connected (bound) to the SP column, thereby rendering the control useless for anything other than displaying the value on the form.

Another note on the above.

Before I built the Rule to Disable the control if the Current User was not the Change Manager, I controlled enablement of the Control to only the Group (not the specific member of the Group) by using the Control's Appearance Setting and

"fn-IsMemberOfGroup"  runtime in the formula.  That worked well also, but the problems with Edit/View function in SP still presented itself. Changing the SP Person or Group setting to "All Users" was again, the only way around that. I tried to Rule approach as an attempt to solve the problem.

I appreciate any assist that knowledgeable folks might offer.

Also, meant to mention earlier, the permissions assigned to the group are similar to the generic "Contribute", which I have named "Contribute (No delete - Personal Views enabled). I have removed permissions for deleting items and versions and managing web parts, and couple of site permissions.

.

could you as well post configuration of 'Change Managers" SP group?

I'm specially concerned on who can enumerate group membership setting. if you have it set to group members only it may cause this behaviour.

Marian

Thank you for looking at this with me.  Below is a screen shot (3) of the Group Permissions in question.  The screen shots above are from my own spreadsheet matrix of all the permissions I've created or using for various lists/libraries.  In order to keep users from inadvertently deleting records or versions, and lock down public views, I used the OTB "Contribute" permissions and then modified it slightly.  The setting for "Enumerate Permissions  -  Enumerate permissions on the Web site, list, folder, document, or list item" was unchecked in the "Contribute" permission, so I thought I would be safe in continuing that in my new customized permission setting.

this is setting of (your custom) Contribute permission level.

I've meant setting of Change Managers" SP group.

go to site settings >> people & groups >> select group >> group settings

Of course - thank you.  Here you are:

as I suspected, you have configured the option " Who can view the membership of the group?" to "Group members" only.

try to change it to Everyone. I believe it will solve your problems.

Marian

Made the changes and tested - Thank you! Thank you!

I could not see that as a potential issue.  Mistakenly assumed it was related to being able to view group membership or something like that,  Nagging at me for 3 months.

 I have 3 lists being used for 3 different change tracking and/or employee submissions and each one had the same problem as I was using the different User Groups to manage a range of controls, rules permissions, etc.

A virtual cup of coffee or dinner to you at the least

Mark

a mug of beer would be very fine

consider marking as correct answer the post that answers original question/problem, so that others can easily match the two.

This was exactly what I needed! Thank you Marian Hatala‌

one another mug of beer  

Just wanted to drop a thank you for this answer! I was so stuck on how to resolve and this was the key. Adding another virtual beer for you @emha!