Had the requirement to get the CheckedOutFile collection of a SharePoint List programmatically and it had to include the ItemID for the file (for use in further programmation).
Via PowerShell you can quite easily get the Path Identity information which contains the ItemID:
Notice that the number at the end is the ItemID.
However, via C# CSOM this is a lot harder as the ObjectPathIdentity class is “inaccessible due to its protection level”. You can’t directly get to this info so I created an extension method “GetPath” to get this info:
public static class ClientObjectExtensions
{
public static string GetPath(this ClientObject o)
{
string result = null;
if (o != null)
{
var q = o.GetType().InvokeMember("Path", BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.Public, null, o, null);
var r = q.GetType().InvokeMember("Identity", BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.Public, null, q, null);
result = r.ToString();
}
return result;
}
}
Which can be integrated into the C# CSOM logic
Now you can extract this value from the string and continue to work with it as needed.
The issue
I recently ran into an Office 365 environment where all users were seeing green locks on files and folders synched with the OneDrive For Business client.
If this isn’t expected, in cases where the user should definitely have write access to these files you might want to check the following Library Settings:
Require content approval for submitted items?
Go to Library Settings > Versioning:
If your library has this enabled than OneDrive will only sync in read-only mode. If you disable this setting your sync client should inform you that you now have read-write access and the green lock icon should be gone.
If it doesn’t then please read on.
Require documents to be checked out before they can be edited?
Go to Library Settings > Versioning:
Another feature that’s not compatible with the full OneDrive sync experience. Again as before, you will have to disable this and it should resolve immediately. If not then continue reading…
Required Columns
Go to the Library Settings and check the columns:
Check with the columns on the library, if any of them are “required” this will cause a read-only sync. In the screen this is the case for my ‘Department’ field.
Wait a minute! Does this mean we lose the ability of having required metadata ???
Well, luckily NO. You just have to use a different approach and use Content Types.
The solution
Go to the Library Settings > Advanced Settings:
Content Types are a great way to have different types of content, each with a different set of metadata, workflows, template, and more. You should familiarize yourself with the concept of Site Columns, Site Content Types, List Columns, List Content Types, Content Type Inheritance, etc. It really depends on the use case but in my example I just modified the List-level Column and Content Type, in other cases this may not be the best approach. If you’re looking for more information on Content Types you can easily find this on the web.
To make your field required go into the Content Type (you can click on its name) and configure each field as optional, required or hidden.
The result is that the field/column itself is not configured as Required, but it is configured Required for the Content Type. And when uploading documents of that Content Type the user will still have to provide a value for the field.
Almost there…
If you followed the above steps you’ll still be having the original issue. This is because in the background the field will still be “Required”. And if you have Content Types enabled you won’t be able to change this setting because the UI hides it from the List Column Settings!
Here are a few options to resolve this situation:
- If you are using Site Columns then you can change the “Require” setting and push the change down to lists and libraries. This is quite easy to do but will impact all lists and libraries where this is used. You’ll have to inspect those lists to see if they have Content Types enabled (and that the Content Type requires the field) or users will no longer have to specify a value (= functionality change)
- You can disable Content Types on the Library, change the List Column setting and re-enable Content Types. This is also easy to do from the UI. All Content Types will be preserved during the operation but some users might be impacted during the operation. Afterwards, verify per Content Type which fields should be required.
- Use CSOM or PowerShell to directly manipulate the List Column settings.
Options (2) and (3) are rather similar, but if you prefer the latter here’s a PnP PowerShell script that should assist you. I like PowerShell because it is transparant and can easily be viewed and modified. And I like PnP and its CmdLets because it really abstracts complex operations. Note that you will have to install the PnP CmdLets first.
https://msdn.microsoft.com/en-us/pnp_powershell/pnp-powershell-overview
Script:
cls
## Variables
$userName = "yourusername"
$siteUrl = "yoursiteurl"
$listName = "yourlistname"
## Script start
if (!$cred) {
$cred = Get-Credential $userName
}
Connect-PnPOnline –Url $siteUrl -Credential $cred
###
$web = Get-PnPWeb
$list = Get-PnPList $listName
### QUERY OR CHANGE
$bChangeField = $false
Get-PnPField -List $list | % {
$f = $_
# List all required fields, except the built-in FileLeafRef field which is required but by design
if ($f.Required -and $f.StaticName -ne 'FileLeafRef') {
Write-Host ($f.StaticName) -ForegroundColor Red
if ($bChangeField) {
Set-PnPField -Identity $f -Values @{Required=$false}
Write-Host (" -> updated") -ForegroundColor DarkYellow
}
else {
Write-Host (" -> reporting only") -ForegroundColor DarkYellow
}
}
}
The script has a flag to control the actual field update vs reporting only.
After running (with actual update) it should resolve the issue.
if it doesn’t I’d be interested to hear about it in the comments!
Wrap-up
Some list settings are not compatible with the OneDrive sync experience and make it a read-only sync. You can disable these via the UI or via code/script.