Associate
Hi all, I know this isn't exactly "server" stuff, but I would assume that most people in this forum work in the same kind of environment where they might be able to help me with this! If anyone can suggest a better sub forum please advise! 
Anyway..
I've recently done some development work for a customer who needed a bespoke approval workflow. I'll built a workflow with a document library and an approval library. A "contributor" uploads a document to 'Documents' library - the workflow triggers on item creation; it sends an email notifying them the upload was successful, notifying a moderator that an item needs approving, makes a copy of the document in the approval library and sets the status of the original in 'Documents' as pending.
All of the above runs inside an impersonation step, as it involves copying the document to the approval library (which the contributor does not have access to for security and audit policy reasons and needs to stay locked down to all but the moderators).
When the moderator approves or rejects said item, it contacts the contributor informing them of the decision, adds a time/date and moderator name stamp to the document (in the original documents library) and sets it's status to the relevant decision. The copied document is then deleted from the approval library.
All of this works just fine but today I've been asked to remove the annoying "EDIT" button which is visible on pages to the contributors. What enables them to see the EDIT button is the following permission:
Top level site settings -> Site Permissions -> Permission Levels -> Contribution Group Final (custom group for the contributors) -> Edit Items - Edit items in lists, edit documents in document libraries, and customise Web Part Pages in document libraries.
If I remove this permission then the EDIT button does indeed disappear, however for some reason it also stops the workflow from proceeding. It gives some message about no permissions to perform task or access resource - its strange because the impersonation step should prevent this kind of issue from happening and run the workflow with full access permissions.
I can be sure that the impersonation step is doing something because before I implemented it, if a user with no permissions on "approval library", tried to run the workflow (by creating an item and triggering it), the workflow would end up being stuck due to missing permissions for that user to modifying items in the approval library. However with the impersonation step, the workflow runs as a full control system account and encounters no errors.
Is anyone able to offer an idea towards either:
A) Is there an alternative way to hide the EDIT button without having to change group permissions and cause the workflow errors?
or
B) Why is the workflow experiencing permissions issues when triggered by a contributor, despite the fact it is running with FullAccess permissions on the site?
TL;DR - removing edit permissions from a permissions group stops a workflow that should run as system admin from proceeding due to it not being allowed access to resources/locations.
Note: Impersonations steps are also known as App Step's within SharePoint designer (to avoid confusion).
A full copy of the workflow I've created and more details is available here: https://www.dropbox.com/s/kyjp1o177q42zww/RGW Final Workflow V4.5.docx?dl=0
Looking forward to hearing from someone soon!
Jamie
Anyway..I've recently done some development work for a customer who needed a bespoke approval workflow. I'll built a workflow with a document library and an approval library. A "contributor" uploads a document to 'Documents' library - the workflow triggers on item creation; it sends an email notifying them the upload was successful, notifying a moderator that an item needs approving, makes a copy of the document in the approval library and sets the status of the original in 'Documents' as pending.
All of the above runs inside an impersonation step, as it involves copying the document to the approval library (which the contributor does not have access to for security and audit policy reasons and needs to stay locked down to all but the moderators).
When the moderator approves or rejects said item, it contacts the contributor informing them of the decision, adds a time/date and moderator name stamp to the document (in the original documents library) and sets it's status to the relevant decision. The copied document is then deleted from the approval library.
All of this works just fine but today I've been asked to remove the annoying "EDIT" button which is visible on pages to the contributors. What enables them to see the EDIT button is the following permission:
Top level site settings -> Site Permissions -> Permission Levels -> Contribution Group Final (custom group for the contributors) -> Edit Items - Edit items in lists, edit documents in document libraries, and customise Web Part Pages in document libraries.
If I remove this permission then the EDIT button does indeed disappear, however for some reason it also stops the workflow from proceeding. It gives some message about no permissions to perform task or access resource - its strange because the impersonation step should prevent this kind of issue from happening and run the workflow with full access permissions.
I can be sure that the impersonation step is doing something because before I implemented it, if a user with no permissions on "approval library", tried to run the workflow (by creating an item and triggering it), the workflow would end up being stuck due to missing permissions for that user to modifying items in the approval library. However with the impersonation step, the workflow runs as a full control system account and encounters no errors.
Is anyone able to offer an idea towards either:
A) Is there an alternative way to hide the EDIT button without having to change group permissions and cause the workflow errors?
or
B) Why is the workflow experiencing permissions issues when triggered by a contributor, despite the fact it is running with FullAccess permissions on the site?
TL;DR - removing edit permissions from a permissions group stops a workflow that should run as system admin from proceeding due to it not being allowed access to resources/locations.
Note: Impersonations steps are also known as App Step's within SharePoint designer (to avoid confusion).
A full copy of the workflow I've created and more details is available here: https://www.dropbox.com/s/kyjp1o177q42zww/RGW Final Workflow V4.5.docx?dl=0
Looking forward to hearing from someone soon!
Jamie