There is a very annoying bug where the file/folder, "right-click", 'Move to" pop up interface blocks navigation at the shared drive level even though a user has the write rights to move files to a lower level folder in that shared drive. There is no reason for this since they have the ability to move, google does the check at move time, and also they can do a "drag and drop" moved from any file on the main window file list to an allowable location on the left hand file tree navigation pane.
The reason this is particularly annoying is that there are scenarious where you cannot get the destination in the left hand file tree navigation pane because we are setting up shadow hiarchies to compensate for the lack of inherited rights filters.
P.S. there is also hack/kludge where you make a shortcut in your 'My Drive' and navigate that way but that's not really scalable solution.
Series of screen captures below. In this example I am in the group <PII removed by staff> and user "****harris@edmonton.ca" is *not* me.
Right-click 'Move to' popup:
Blocked navigation to "Nharris Test" shared drive:
You can see the group I'm in has 'Viewer' access at the Shared Drive level :
And 'Content Manger' access at the subfolder level in that Shared Drive :
Now I do a 'Drag and Drop' from the right hand file list to the left hand file tree navigation pane:
And of course it works fine:
@daryle_tilroe a very thorough explanation of the bug. Recommend you open a support ticket. If they deem that this is expected behavior (though I agree with you), the work around I use is to star the folder in the shared folder and then use that. -KAM
A starred folder is indeed another partial workaround. Trouble with both is that you cannot, to my knowledge, create a shortcut to, or directly star, a shared drive. Yes one could create another shadow index of shortcuts to sub folders or something but really this is a simple bug that should be fixed ASAP. Sigh...