Hello once again! Do you come here often…No? Ok fine, enough with the cheesy chat up lines, now my fellow technology followers, enthusiasts of all things digital and seekers of modern workplace wisdom. It’s time for another byte sized chapter, documenting the modern day cloud computing world via submission of another hard fought solution into the IT consulting annals. Today, I present to you the tale of my latest dalliance with SharePoint PnP aka (Patterns and Practices) and its enigmatic ability to add permissions to SharePoint document libraries something one thought would be so simple, however even this created a narrative so convoluted it could rival a telenovela plot.
The Premise
So as with any replatforming or mass migration of SharePoint data, no matter how well architected (if I do say so myself) there will always be an end user requirement that will come out of left field and smash it’s way into your consiousness like the italian flanker Sebastian Negri on the first match of the six nations (as you may be able to tell I am currently watching Six Nations: Full Contact on netflix). The user requirement always starts off looking like a simple recursive script will solve it, and in a world where technology operates as smoothly as a well-oiled machine, where every click is met with precision, and every command executes flawlessly it would be. However forget that utopia because my reality was about to become alot more chaotic, much like Italy’s descent into recieving the Wooden Spoon again in 2023 (here’s hoping they manage to avoid it this year).
The Quest
So with the imbued confidence as a lord of the digital relm, I donned my protective armoured suit, and set out to embark on my quest to script my way out of an otherwise hideously repetitive task. With my trusty toolbox of SharePoint PnP by my side, armed with nothing but my trusty code Copilot and the spells of PowerShell. This script would be written in a matter of minutes and the 180 SharePoint document set permission dragons slayed, My mission seemed simple: update all the required directory permissions within these document sets using the fabled SharePoint PnP “Set-PnPListItemPermission” feature.
The Encounter
Alas lo and behold, these dragons they were tricksters, a magical band of shape shifters, that proved they would not be vanquished by a simple script, the battlefield proved a complex affair with the SharePoint PnP documentation a labyrinthine scroll proven to be filled with riddles. The first blows were delt, the test script was run and dutifully failed, however this was as one would expect, it’s a test run after all if it didn’t fail I would have been surprised.
As every battle hardened script guru knows, if it doesn’t run first time, then you fall back to your sidearm, I opened Google and worked my searching magic. After what seemed like many moons had passed in a stroke of genius—or perhaps sheer luck—I stumbled upon a beacon of hope. A GitHub issue thread, like a message in a bottle, washed up on the shores of my frustration. There, a fellow SharePoint PnP traveller had documented their own challenges with the Set-PnPListItemPermssion statement, providing the key to unlock the permissions puzzle.
Set-PnPListItemPermission -List "<ListName>" -Identity $folder.Id -User "c:0t.c|tenant|<group object id>" -AddRole 'Contribute'The Eureka Moment
As it turns out the Set-PnPListItemPermssion “-Group” parameter as documented was a red herring, and the true path to victory lay hidden behind the “-User” parameter, which is used to disguise our group. As you can imagine it was a plot twist not even J. K. Rowling could have foreseen. As I navigated this maze to victory, I encountered more twists and turns than a politician’s speech. The script command line mocked me with error messages, each one a riddle wrapped in a mystery inside an enigma. It was a test of patience, a trial by fire, a… well, you get the picture.
The Potter Twist
The path to defeating the dragons however was not as simple, as just a mere switch in parameter it was also how we presented ourselves to the Powers of SharePoint PNP. You see avid adventurers, you cannot just simply pass a group reference, or even an object id, you must trick SharePoint PnP through the use of an invisibility cloak, an action even Harry Potter would be proud of. It turns out that instead of just passing a direct reference you have to translate the group into a user through a form of parceltongue
-User "c:0t.c|tenant|<group object id>"So, to conquer the basilisk we have to change to house Slytherin, this is because we were trying to give access using an Active Directory group and unfortunately the PnP PowerShell hadn’t been to Hogwarts and didn’t have the code for supporting AD Groups. PnP can only support SharePoint Groups using the -Group parameter so by using the above wizarding magic we pass in an AD Group as a user and let SharePoint PnP translate it into the AD Group, Hagrid would be proud, turns out you are a wizard Harry after all.
The Encore
On reflection as I recount this epic saga and meld the boundaries of Harry Potter, Rugby and Dragons, I can’t help but chuckle at the absurdity of it all. The world of cloud computing consulting is a stage, and we, its actors, must sometimes improvise our lines when the script falls short, in the case of this problem get a bit Harry Potter. Until our paths cross again in the hallowed halls of Hogwarts, now where is my wand…
Gary
P.S. To SharePoint PnP and all the other tools in my arsenal: let’s make our next potion a symphony, not a cacophony. And to the wider tech community: keep those GitHub threads coming; you’re the real MVPs.
