As the data-interception propagate is getting more and more deployed in the out of the box components (navigation, quick links, ...). The idea is to add or querystring to the target URL set on the navigation or in the Link (in quick links) so the target page ignores the data-interception when loading (like the data-interception was off).
Example:
- I add a link in navigation to [Site]/Lists/SomeList/AllItems.aspx?DataInterception=Off
- The allitems.aspx page (the view page) will ignore the data received from the source page and load completely.

It's really needed, this data-interception is causing a lot of problems in the navigation (pages containing spfx not refreshing), in view webparts (clicking on see all the view target view loads then goes back to the calling page then goes again to the default view of the list), in some links on quicklink webpart (i have a quicklink to create a page in another sitecollection and it's causing a lot of problems due to data-interception)

Thanks in advance

I really need the SharePointOnlineCredentials class to work in Dot Net Core under CSOM. It is so simple to use, and your work around(s) are complicated and not possible for me. I work for a large company with a large online SharePoint site. The corporation refuses to give out application codes to work around my security, but I can create a user and password to login to the SharePoint site and update files. Why can I not automate this in Dot Net Core? The work around(s) for this one feature are crazy. Days of coding to run into brick walls that are not necessary. I'm very frustrated...

We currently have the necessity to (quite) immediately do some work (adding related items in other list, setting permissions connected to Field Values) after an Item is added/updated.
Therefore we are stuck on EventReceivers, because they are the only option to to it nearly in real-time. Webhooks have a 1 minute timeperiod, that is far too long for our cases (as it connects to user interface/experience and security of course).
So i would ask for an option to configure the timespan for the webhooks or have any other way for more/less immediate notifications.

As the EventReceiver-Namespace is no longer part of the .Net Core-CSOM-API this is also preventing us to switch to that and use advanced techniques of Azure.

As mentioned here

https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/add-in-permissions-in-sharepoint

and here

https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/app-only-elevated-privileges-sharepoint-add-in

it ist stated, that using AppOnly Permissions is restricted for UserProfile and TaxonomyStore (whereas Taxonomystore is unclear).

However, as now CSOM supports .Net core, but only with AddIn-Model authentication, we have no possibility to use that to update UserProfiles or TaxonomyStore in an automated way in the backend using .Net Core.

At least if that documention is still correct.

Currently we have to use a service user and .Net Framework CSOM to do that tasks. But this on the other way prevents us to use new technologies for example in Azure, which is moving to .Net Core (eg. Functions support .Net Framework only in oldest v1-Version).

So I have been doing a lot of digging into which version of office-ui-fabric-core SharePoint uses. Turns out that it uses office-ui-fabric-core V-9.6.1 which if you are aware was released before Fluent Design Language was a thing. Now I get that sharepoint doesn't fully use Fluent Design Language, but because all documentation on Fluent points to UI Fabric Core and the documentation for SPFx does too it leads to a lot of confusion since a lot was added starting with version 10.0.0 of office-ui-fabric-core. Now I get that we could simply clarify the documentation for SPFx so that it mentions that the version of Fabric UI core used is 9.6.1 but this version was released in 2018 and the current version was released in January 2020. That is almost a 2 year age difference and both versions are now so different and the documentation mostly lines up with V-10 and above that it makes working with Fabric Core tedious and it also goes against the promise that sp-office-ui-fabric-core would be updated along new versions of office-ui-fabric-core. I am aware that Fabric UI React is the solution for most when making SPFx solutions but my use case is not a SPFx solution, I want to use Fabric Core's CSS classes with view formatting!

I don't know if this is possible currently (depending on whether or not SPO relies on Fabric Core) but it would certainly be a good idea to update @microsoft/sp-office-ui-fabric-core so that it uses office-ui-fabric-core V-10 or abobe.

...Come to think of it, maybe it's time SPO updates it's UI so that it is in line with Fluent Design System!!!