DEV Community: Ole Kristian Mørch-Storstein

blog moved to GitHub pages

Ole Kristian Mørch-Storstein — Mon, 14 Dec 2020 00:53:51 +0000

I've moved the blog over to GitHub pages the new url is https://okms.github.io/

the few posts I have here have been migrated, but im leaving them here as well.

Lookup field not returned in SharePoint REST

Ole Kristian Mørch-Storstein — Sun, 29 Nov 2020 22:52:00 +0000

Recently I reviewed a strange issue where a SharePoint document library had a Person/User field "Originator" which was impossible to access through REST.

TLDR

if you add a person/user/lookup field named Originator, you there will be no name collision when creating the field since there are no other field with the same internal name, but accessing this field through REST cannot be done since SP REST will have a name collision with an internal field due to the <internal name>Id convention used by the API.

Details

Here is my simple test case, a list with only two manually configured user (person) fields Orignator as well as AnotherUserField. The same user has been added both places

First a bit of background. I assume the original field was created through the UI, with the title Originator. This means the internal name aka static name for this field would be the same, i.e. Originator. This does not conflict with any OOB fields, so creating it is straight forward.

As this was a user field, its internally handled like any other lookup field. What this means is that the field is returned as OriginatorId when you do a rest query. Well, that's the theory anyway. Lets have a look

I can find my item title as well as AnotherUserField which here is returned as AnotherUserFieldId as expected. But no OriginatorId. On a whim we pulled out the SchemaXml for the list, like so (my test list is aptly called 'test')

(Get-PnPList -Identity test -Includes SchemaXml).SchemaXml | clip

If we search through that text (preferably pretty printed) we find our Originator field

    <Field Type="User" DisplayName="Originator" List="UserInfo" Required="FALSE" EnforceUniqueValues="FALSE" ShowField="ImnName" UserSelectionMode="PeopleOnly" UserSelectionScope="0" ID="{ef9f5a10-56dd-41e8-9e22-bfd095095ae0}" SourceID="{4fb24039-a619-44e7-a2cf-2be13e015f4b}" StaticName="Originator" Name="Originator" ColName="int4" RowOrdinal="0"/>

But searching further for the word Originator we found this internal hidden field which is added automatically to any list and required by some internal functionality in SPO, thus impossible to delete

<Field ID="{14ee99cd-bed9-474a-bf99-8f753fbad6b4}" Name="OriginatorId" DisplaceOnUpgrade="TRUE" Hidden="TRUE" ReadOnly="TRUE" ShowInFileDlg="FALSE" Type="Lookup" DisplayName="Originator Id" List="Docs" FieldRef="ID" ShowField="OriginatorId" JoinColName="DoclibRowId" JoinRowOrdinal="0" JoinType="INNER" SchemaVersion="16.0.77.0" RecreateIfMissing="TRUE" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="OriginatorId" FromBaseType="TRUE"/>

This means, if you add a person/user/lookup field named Originator, you there will be no name collision when creating the field since there are no other field with the same internal name, but accessing this field through REST cannot be done since SP REST will have a name collision with an internal field due to the <internal name>Id convention used by the API.

There's a bunch more of these names that are valid, but should be avoided, here are some which have names that do not start with underscore:

Prog
Scope
Unique
ComplianceAsset
SyncClient

Conclusion

The simplest way to avoid this issue is to prefix internal names of your field. E.g. could the Originator field have been created like this

    <Field Type="User" DisplayName="Originator" List="UserInfo" Required="FALSE" EnforceUniqueValues="FALSE" ShowField="ImnName" UserSelectionMode="PeopleOnly" UserSelectionScope="0" ID="{ef9f5a10-56dd-41e8-9e22-bfd095095ae0}" SourceID="{4fb24039-a619-44e7-a2cf-2be13e015f4b}" StaticName="OKMSOriginator" Name="OKMSOriginator" />

This is, however, something you only would do if you created this field programmatically. Using the UI it is possible to create a field using the internal name you would like it to have, and then rename it, but this is not something regular users would ever do.

Office Online 'The file is locked for shared use' error

Ole Kristian Mørch-Storstein — Wed, 15 Jan 2020 15:18:52 +0000

Short breakdown

After editing files in Office Online (Office 365 and OnPrem) in a chromium based browser you might experience the following:

The file is locked for shared use by ...

Background

chromium based browsers all have the flag allow-sync-xhr-in-page-dismissal. This flag can be found under

Edge chromium: edge://flags
Chrome: chrome://flags

Recently it seems the default value for ths flag has been changed to "disabled". Furthermore this flag will be removed from both Chrome and Edge. If this functionality is disabled, users will frequently experience issues where recently edited office documents are locked for editing by other users and metadata cannot be changed by the current user from the web interface.

Office Online seems to rely on this functionality to unlock documents when you navigate away from the document editor interface. If not able to unlock a document, an exclusive lock will remain on the document until it expires after 30 minutes.

If you cannot reproduce the error currently, you can try to change the flag to "disabled" and you should be able to consistently reproduce the error.

How to reproduce

Note: use a chromium based browser

1) in a document library, create a new document

2) edit the document if you like, return to the document library when done

3) now try to add a title to your document

4) the file is locked for editing. Note that other users will not be able to edit the document at all since the current user will have an exclusive lock

How to make the teamify dialog re-appear in Office 365

Ole Kristian Mørch-Storstein — Tue, 26 Mar 2019 15:38:38 +0000

Here's a quick tip for those who have permanently dissmissed the "Teamify" site dialog in an Office365 group site.

PnP PowerShell snippet

$siteUrl = "<full url to your site collection>"
# Show Teamify prompt again
$site = Get-PnPTenantSite -url $siteUrl 
# Temporarily disable NoScript
$site.DenyAddAndCustomizePages = [Microsoft.Online.SharePoint.TenantAdministration.DenyAddAndCustomizePagesStatus]::Disabled
$site.Update()
$site.Context.Load($site)
$site.Context.ExecuteQuery()

Connect-PnPOnline -Url $siteUrl
Remove-PnPPropertyBagValue -Key TeamifyHidden

# re-enable NoScript
$site.DenyAddAndCustomizePages = [Microsoft.Online.SharePoint.TenantAdministration.DenyAddAndCustomizePagesStatus]::Enabled
$site.Update()
$site.Context.ExecuteQuery()

The short version of what this script does is that it temporarily removes the NoScript limitation enforced on all group sites in Office 365. This is done so we can remove the "TeamifyHidden" propertybag value which is what controls whether or not the dialog should be visible. Finally we re-enable NoScript.

For those who don't know, the teamify dialog allows you to create an Office 365 team attached to your existing group site. There are of course other ways of doing this, the most common being to attach your existing group site to a new Team through the Teams interface