Priority
(Urgent) I can't use the CLI
Description
Originates from Discord member without GitHub account: https://discord.com/channels/1022486301536178246/1113583852586283059
Almost all spo file and spo folder commands suffer from this issue. The command returns weird responses when a file or folder has a # or % sign in its name.
Example:
m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Shared Documents/General/Equipment Data/MiSeq - #0692' --recursive
It always returns an empty result, even where there are child folders.
Even worse, the command is stuck in an endless loop when the parentFolderUrl parameter has a value where a folder starts with a # character (e.g. /Shared Documents/General/Equipment Data/#0692).
Steps to reproduce
Empty result:
- Create a folder with a
# in its name. E.g. Folder#.
- Create a child folder under this folder. E.g.
My subfolder.
- Run
m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Mylibrary/Folder#' --recursive
Endless loop:
- Create a folder with a name starting with
#. E.g. #Folder.
- Create a child folder under this folder. E.g.
My subfolder.
- Run
m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Mylibrary/#Folder' --recursive
Expected results
Expect the command to return all subfolders recursively.
Actual results
Either an empty result, or no result at all because it's in an endless loop.
Diagnostics
No response
CLI for Microsoft 365 version
v6.9.0
nodejs version
v18.16.0
Operating system (environment)
Windows, Linux
Shell
PowerShell, Debian Linux command line
cli doctor
No response
Additional Info
This is because we use GetByServerRelativeUrl endpoint almost everywhere. This endpoint doesn't support # and % characters at all. We should use GetByServerRelativePath to support these characters. This issue has been noticed for the command spo folder list, but nearly all spo folder and spo file commands use the same (bad) endpoint.
Extra info: https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/supporting-and-in-file-and-folder-with-the-resourcepath-api
Agreement
thinking of it... if # is a valid character and we don't support it, then it's a bug that we should fix, in one way or the other. I suggest we don't introduce a new option that we'll remove in 3 months time. That would be introducing unnecessary work. Instead, I suggest we fix it correctly the right way.
We've split the work into 2. This issue is for spo file commands. We'll create another issue for spo folder commands.
Priority
(Urgent) I can't use the CLI
Description
Originates from Discord member without GitHub account: https://discord.com/channels/1022486301536178246/1113583852586283059
Almost all
spo fileandspo foldercommands suffer from this issue. The command returns weird responses when a file or folder has a#or%sign in its name.Example:
m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Shared Documents/General/Equipment Data/MiSeq - #0692' --recursiveIt always returns an empty result, even where there are child folders.
Even worse, the command is stuck in an endless loop when the
parentFolderUrlparameter has a value where a folder starts with a#character (e.g./Shared Documents/General/Equipment Data/#0692).Steps to reproduce
Empty result:
#in its name. E.g.Folder#.My subfolder.m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Mylibrary/Folder#' --recursiveEndless loop:
#. E.g.#Folder.My subfolder.m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Mylibrary/#Folder' --recursiveExpected results
Expect the command to return all subfolders recursively.
Actual results
Either an empty result, or no result at all because it's in an endless loop.
Diagnostics
No response
CLI for Microsoft 365 version
v6.9.0
nodejs version
v18.16.0
Operating system (environment)
Windows, Linux
Shell
PowerShell, Debian Linux command line
cli doctor
No response
Additional Info
This is because we use
GetByServerRelativeUrlendpoint almost everywhere. This endpoint doesn't support#and%characters at all. We should useGetByServerRelativePathto support these characters. This issue has been noticed for the commandspo folder list, but nearly allspo folderandspo filecommands use the same (bad) endpoint.Extra info: https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/supporting-and-in-file-and-folder-with-the-resourcepath-api
Agreement
We've split the work into 2. This issue is for
spo filecommands. We'll create another issue forspo foldercommands.