Support .NET Core with CSOM

The recommended list option is ONLY 5000, the structure has been indicated to hold up to 30 Million items. but I had a list over the 5000 and experienced issue with IE and MS will not resolve. We cant be the only company that would like lists with over 5000 items. The idea would be a special list page - the list page could handle over 5000 item, but the requirement is the information be hosted as an external list.

Currently term store operations are only available via JSOM. It would be nice to see this added to the REST API as well.

Provide option to enable\disable event firing from Remote Event Receivers in SharePoint Online (CSOM/API) similar to SSOM - EventFiringEnabled

There's currently no better way to configure search indexed and managed properties than export/import configuration. It's a huge pain when building search related apps and a black box, we need something better

You cannot currently use CSOM to publish content types in a content type hub in O365. Right now you must imitate the page post back to do it.

The only way to expand SharePoint events from a calendar is using CAML. There should be a way to retrieve the recurring events fully expanded using REST.

Now we can update UP properties via CSOM in O365, but not on premises. I would appreciate if this can be included on-prem, my customers 80% of the time are still on-prem

As provisioning process, we would love to either add apps from app catalog or store directly using CSOM APIs. This should include the 'I Trust it' model as well. This will help in automating the entire site/sub-site provisioning and making sure apps are available after site is created.

At the moment it does not seem possible to create WebPart connections via the Client Side Object Model.

List items that have an Audience field attached should be audience filtered when retrieved via the REST API.

For example, a list that has link items with the Audience field attached to target particular items at particular groups of people. If the REST APIs are used to retrieve items from this list, then the identity of the requesting user should be optionally used to filter the results based on audience.

Right now there is no API to check that. If you add a security group into a SharePoint group, there is no way to check if the current user is a part of the SharePoint group: The user is not listed in the group.Users and the SharePoint group is not listed in the user.Groups. The 3 APIs that allowed to do this in full trust code are missing from CSOM so we need an alternative.

App-only policy in the SharePoint App Model is very restricted regarding Taxonomy operations. Even if an app is granted full control over the tenant, it lacks the permission to do anything but read operations on Taxonomy. Please provide the ability to create Groups, Term Sets and terms using app-only policy.

Add support for managing information management policies, and especially retention policies, on content types and in libraries using CSOM. These are the objects largely in the Microsoft.Office.RecordsManagement.InformationPolicy assembly, such as the Policy, PolicyItem objects, etc.

Currently it's not possible to set the List.NavigateForFormsPages property through CSOM as it is in the server API.

Some list/library settings are available via CSOM. Others are available via the list property bag (although that approach is not desirable). However, there are even other advanced settings that don't appear to be accessible (read or write) via CSOM/REST. In particular, the advanced settings for "open documents in the browser" (open in the client application, etc.) or allow "quick edit" (yes/now).

I'm looking at SharePoint 2013 when trying to do this, but I suspect the same problem occurs for SharePoint Online and SharePoint 2016.

The latest version of the SharePoint Framework Yeoman generator contains a mix of features that are GA and preview features (for example connecting to MS Graph, web part connections, extensions). Whether the generated solution can be run in production depends on the features used to build the web part. With that, when bundling the project, the toolchain should warn of any experimental features being used in the project which would prevent the solution from being deployed to production tenants. This would help developers avoid deploying solutions depending on experimental features to production tenants, only to see the deployment fail.

It's currently possible to identify the features that are activated at the Site and Web level using CSOM, it isn't however possible to determine which features are present but not activated using CSOM. It would be great if this feature could be added!