Allow Site Admins to Disable "Return to Classic Sharepoint" Link
Displaying the "Return to Classic Sharepoint" and "Exit Classic Experience" links, with no option to disable these links, is a terrible idea. When a user switches from the new, modern interface to classic, it allows them to view links that they are not otherwise permitted to view, thereby overriding permissions. I don't want our users to have ability to switch between the two experiences.
Lenny LaRose
shared this idea
18 comments
-
Poli
commented
I hv same issue. I developed some PowerApps to control data input for users and they can avoid the controls by switching to classic mode :(
-
Heinrich Ulbricht
commented
Google lead me here to read that this cannot be disabled. Please make this an option!
-
Nibu Thomas
commented
I filed a bug for this issue, there is a good chance this will be fixed. I do not have an ETA yet.
-
Gerry Brimacombe
commented
Agreed. This should be optionally disabled.
-
Ignacio Ortiz
commented
A couple of years+ later, are there any news on this?
-
santhosh sankaran
commented
PowerApps forms will also not work properly when someone returns to classic sharepoint.
It would be great if we have setting to control this behavior at sitecollection level.
-
Manikandan P
commented
Will this be resolved or not? A lot of confusion comes in Flow and Forms because of the classic view on modern sites.
-
[Deleted User]
commented
it's been a year and not resolved yet? bc....
-
FastTrack
commented
Is there at least any work around with a script editor to disable it? I have really a security issue, as for no obvious reason my PowerApps form is not used in the classic experience anymore...
I currently minimize all web parts in classic experience so users cannot modify a Sharepoint list and have to use PowerApps - Security by obscurity! Good that the majority of my users do not know SharePoint -
Anonymous
commented
This is literally a terrible experience without the control over this annoying link. The modern experience has been in place for so long that few people actually need or are expected to use the classic experience.
-
Hugo
commented
Did anyone get an answer for this issue?
-
Anonymous
commented
Really need this as I am trying to edit code to remove it. Anyone know how to edit the code?
-
Anonymous
commented
This is really needed as I am currently facing an issue where users will be able to see data that they are not supposed to see.
-
Hugo
commented
Did you guys get any comments / resolution back on this?
-
CoryL
commented
As per kapardhi's comments, the ability to remove to option selectively would be very useful.
-
kapardhi
commented
I'd prefer to have both the options available but add an ability to set permissions for them for Site Admins to control users from switching the view.
-
Jacob
commented
This is a MASSIVE problem if PowerApps is intended to replace SharePoint Designer and InfoPath.
Any implementation of a PowerApps form for business operations requires tight controls on form fields. If those controls are placed on field in PowerApps, the User can circumvent those controls by simply returning to the classic SharePoint form.
Therefore, any form that interfaces with a list developed for SharePoint using PowerApps will not pass an internal or external audit.
This renders PowerApps absolutely useless for a plethora of businesses and applications.
-
Ron Verma
commented
Totally Agree on this but have a different perspective of this problem. Based on my talk with the Support person, when a user hit "Return to classic view" from the modern library view, this sets up a cookie in the browser. Now under that same browser session, if the user goes to some different doc lib (that has the modern view settings selected in the library settings) under some different site collection then that library will also have the classic view when the user lands into that library. This happens coz there is a cookie setup at the browser level that overrides the settings of the document library. So unwantedly, it effects other document library experience also. If the cookie has been setup based on the document library URL somehow then this issue would not have been there. Really want this issue to be fixed.
