SharePoint Online Document Libraries are missing possibly the two most basic and fundamental functions in the online portal:

- A move/cut function, which is missing altogether, both for folders and files
- A copy function, which although technically exists, is really over complicated for a function which has existed in a much simpler form in every document repository technology since the mid-1980s...

Currently, in order to move a file or folder from within the online portal between different libraries or even different folders within the same library...well the function just doesn't exist. So users need to either sync the site just to simply MOVE something or they need to Open in Explorer (and we all know how badly and slowly that works).

Secondly, in order to copy a file from within the online portal between different libraries or even different folders within the same library, I need to copy the URL of the target folder preemptively, then paste in the copy dialog box...should this be the procedure for simply copy/pasting something? Oh and that function's missing for folders...

So again users need to sync a site library or Open with Explorer just to simply copy paste something easily.

How does a document library product make it into production for years on end without having proper move/copy functionality? How does it even make it out of approval?

Three requested updates to significantly improve the Access Request process:

1) Allow multiple users to receive access requests

Access requests (Site Settings > Site Permission > Access Request Settings) can be sent to anyone with an email address, but it has three critical downsides: 1) you are limited to one email recipient; 2) the field does not accept SharePoint groups; and 3) it’s prone to misspellings of email addresses since the field is not a people picker.

One of the most extreme examples of how this is broken: My company’s CEO needs access to a file s/he has a link to, which s/he is going to display at the board of directors meeting in 15 minutes. The site owner forgot to give access or didn’t realize the CEO lacks access. The CEO requests access after clicking the link. The creator of the site has left the company. The request email gets lost in Exchange somewhere. No one knows the CEO is in need of access and the CEO is unable to present the document to the board of directors. Everyone looks a fool.
The best fix for this is to: a) use the site’s Owners group as the default recipients to start; b) allow for multiple email recipients as a people picker; and c) continue accepting an outside email address for those who have grown used to it.

From what I can tell, this is the only place in SharePoint where I'm limited to one individual and no ability to call out SP groups. The entire point of groups is to ensure permissions and communications work correctly based on a global change at the group level, which keeps things moving smoothly.

2) Display site owners on “Request Access” page

Display the names of the members of the Access Request group on the “Request Access” page so users have context to what they’re seeing, not just a blank box asking them to demand access.

3) Make “Request Access” page customizable

Allow for the “Request Access” page to be configurable by the Access Request group so there’s more context for users. For example, “Please do not contact IT with this request; only the site owners can provide access. Contact them directly if necessary.”

One of the hidden gems in Sharepoint is the new geolocation field. A geolocation field enables you to annotate SharePoint lists with location information. In columns of type Geolocation, you can enter location information as a pair of latitude and longitude coordinates.

For whatever reason, there's no way to add a new geolocation field via the UI. Instead you have to go through some hoops with PowerShell (see: http://zimmergren.net/technical/sp-2013-getting-started-with-the-new-geolocation-field-in-sharepoint-2013) and/or script (see: http://mysharepointinsight.blogspot.com.tr/2013/05/adding-geolocation-field-to-sharepoint.html).

As I understand it, there's an MSI package (SQLSysClrTypes.msi)that must be installed manually on the WFEs in an on premises installation to enable geolocation, but this is already in place in SharePoint Online. Given this, we should be able to add geolocation columns to lists via the UI without PowerShell or admin intervention.

Large list management has to become a priority. Even with the most thought out and careful planning, inevitably something will come up and you need to make a change to a list or library. Once that goes over 5,000 items, it becomes impossible to do anything management related to the list, which actually hinders it's use. Users can continually add files, but you can't do anything to help them.

This has to be addressed in some fashion, whether it is allowing APIs like REST and CSOM to bypass this restriction so they can perform basic administrative operations or giving us a happy hour to perform tasks, something has to be done. Deleting 10s of thousands of files or moving them to temporary storage and back is cumbersome, time consuming, and can impact the userbase because their files go missing.

If nothing can be done, then TechNet NEEDS to indicate that the actual limit of SharePoint Online lists and libraries is 5,000 items, not the current architectural limit of 30 million.

When can we expect these updates?