9

Background

I have a site which will have a number of Lists and a Document Library deployed as part of an SPFx application. The Document Library will have a folder hierarchy which must be strictly controlled by the application. When a customer creates a new item in one list (via a UI in an SPFx Web Part - they won't access the list directly), the system should create appropriate folders in the folder hierarchy. The user must then be able to add / edit / delete files in the specific folder they have been provided, but must not be able to add / rename / delete the folders themselves. Later in the lifecycle, a user will be able to mark an item in the list as 'destroyed', at which point the folder and its contents need to be deleted.

Problem

After lots of looking around, via Stack Overflow, the various SharePoint GitHub repositories, the SharePoint UserVoice page and many (many!) hours of Googling, it appears that what I'm trying to do with SPFx is not possible.

There were several ways to achieve this with SharePoint on-prem, but SPFx seems to be significantly deficient in this area.

What I've considered already

  • Workflow with AppOnlySequence steps:
    • Discounted because we cannot deploy workflows with SPFx, and Microsoft seems to consider classic workflow as deprecated in favour of Microsoft Flow.
  • Using SharePoint PnP for separate deployment of classic workflow:
    • Discounted because it's a separate deployment from the main app, and as noted above, Microsoft consider classic workflow deprecated in favour of Flow. [updated added based on comments for clarity].
  • Microsoft Flow:
    • Discounted because the Flow cannot be kept under source control, and does not have independent DEV, UAT and Production environments, so is absolutely not an option for enterprise development.
  • A small server-side .NET app hosted on Azure:
    • Discounted because this incurs unnecessary complexity and additional cost for something which is a common requirement and should simply be part of the modern development framework.
  • Simply hiding the Document Library from the user and from search:
    • Discounted because the user also needs to be able to use the OneDrive Sync Client to sync specific sub-folders in the hierarchy to their PC's during the item lifecycle.

Question

What options, if any, exist for elevation of permissions in a SharePoint Framework Web Part, to allow for creation / deletion of folders in a document library outwith the context of the currently logged-in user?

Supplemental Questions

If it's not currently possible at all, then:

  • Is this anywhere on the roadmap? There are plenty of people asking similar questions, so it's obviously not an uncommon requirement.
  • Is there anything on the roadmap which will allow greater Admin control of Microsoft Flow? Particularly source control, and automated deployment alongside SPFx Apps.
  • According to this, you can use PnP. Have you looked into this yet? – wjervis Jan 22 '18 at 14:29
  • I've looked at PnP as well - but discounted provisioning a classic workflow using that method because Microsoft are focusing development effort on Flow, and this app will be around for a long time - I'd rather do something that's got a longer term future if at all possible. I'd also prefer to do something that can be deployed with the SPFx app, not separately. – Mike Insch Jan 22 '18 at 14:44
  • 1
    have you taken a look at azure functions ? Compared to Provider-hosted app which uses app service, Azure functions are comparatively cheaper. Check this detailed blog. By default, the SPFx uses OOTB SharePoint REST APIs to communicate with lists. There is no way you elevate permission from client side only components since it runs with the access rights of current user only. You need to implement either a custom web api or azure function as mentioned previously. – Gautam Sheth Jan 22 '18 at 15:14
  • @GautamSheth Interesting option, and one I'll take a closer look at - still doesn't solve the need to be deployable as part of the SPFx solution however. This is a very common requirement, and shouldn't have such a disjoint 'solution' (it's more like a MacGuyver duct-tape and chewing gum workaround to me!). – Mike Insch Jan 22 '18 at 16:02
  • That doesn't mean PnP is going to be dropped. There will always be an option for custom development, and so far, PnP is that option. – wjervis Jan 22 '18 at 18:05
8

The thing with SPFx is that it is 100 % client side solution. It will always run in the context of the current user. There is no OOTB way to elevate permissions.

To elevate privileges, you will have to build a hybrid solution.

So, besides the options that you have mentioned in the question, you are left with (IMHO) 2 options:

1) Azure Functions

Its basically a small piece of code that you can run on Azure cloud. Its comparatively cheaper than a provider-hosted app. You can configure it to run on an HTTP request only instead of "Always On".

To integrate it with SPFx, you can refer the blogs mentioned below.

The blog mentioned a step-by-step way to create, configure and integrate azure function with SPFx.

Running a SharePoint framework web part with elevated privileges – Focus on Azure Functions – Part 1

Running SPFx webpart

2) PnP JS running on Node.js

PnP JS contains a fluent API for working with SharePoint APIs as well as utility and helper functions. Its basically a wrapper over the OOTB SharePoint REST APIs. It can not only be run inside a browser but also inside a Node.js environment.

You can use the same concept (App-only) of client id and secret but in Node.js environment to elevate privileges.

You can refer to Sergei's excellent blog - Using PnP JS core in Node.js environment.

Other Node.js references -

Using PnP JS Core outside a browser (Node.js environment)

Using PnP JS Core and node-sp-auth

3) Using Custom Web API

Create a Custom Web API with App-only permissions to elevate privileges for interacting with SharePoint.

GitHub sample - React-SP-elevateprivileges

The sample is a little bit old and needs to be upgraded, but you get the general idea of how to go about doing stuff.

4) Graph API for SharePoint (currently in Beta)

Strictly not recommended for production use.

Graph API to interact with SharePoint is still in beta. It works on lists, listitems (read-write support) and sites(read-only support). Richer support for Graph API is coming to SPFx in the near future with AadHttpClient and MSALHttpClient. Once the SharePoint graph endpoints moves out of beta, you will be able to elevate privileges easily in a united solution.

Working with SharePoint in Microsoft Graph

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.