Marc D Anderson
My feedback
-
48 votes
-
4 votes0 comments · SharePoint Administration » Office 365 SharePoint Tenant Admin · Flag idea as inappropriate… · Admin →
As part of the future roadmap for the SharePoint Framework, we are looking into doing something similar as explained in here. Stay tuned, more public information hopefully soon.
-
8 votes
-
79 votes
We have been working on providing navigation parity on classic pages – including ability to reflect structured and managed navigation on modern pages in classic team sites where publishing feature is activated. Check out this community post for more details: https://techcommunity.microsoft.com/t5/SharePoint/UPDATE-Support-for-Structured-Managed-Navigation-enabled-on/m-p/67436
-
100 votes
-
16 votes
This is part of a larger issue around testing and forewarning about upcoming changes. A canary tenant is a nice idea, but having a change log to go along with it would be even better.
-
179 votes13 comments · SharePoint Dev Platform » SharePoint APIs (CSOM/REST/Server-side) · Flag idea as inappropriate… · Admin →
Thanks for your feedback! We’re reviewing your suggestion.
@André, I've found the behavior you saw in some circumstances. Maybe it's libraries versus lists? My error above is with a list, which for me is at least as common a situation as libraries.
Either way, the behavior is not as expected, at least for me. I want to be able to get both the ID and Lookup value, just as I can with SOAP.
Bitten by this again today. Argh!!!
Whenever I run into this, I fall back to SOAP calls, which Just Plain Work.
-
189 votes
Thank you for the suggestion. We recognize the importance of better auditing around content type usage. We have a few ideas in this area though they are in too early a stage to share publicly.
-
2,167 votes
CustomActions that deploy script, JSLinks, and additional web parts on the page are currently not supported in the new experience. Environments that require these unsupported features should continue using classic mode for the time being.
Throughout this year, we will be addressing critical scenario gaps to make the new document library experience support custom processes, commands, and other functionality required for complex, business-critical workflows in complex organizations. Specific capabilities we are investigating building include the ability to host web parts on the page, the ability to define custom view layouts and conditional formatting, and the ability to be visually customized and branded with client-side design pacakages. In the coming weeks we’ll share additional information surrounding these extensibility opportunities across lists and libraries.
I do think the "Working on it" message here should give some hope. Microsoft knows these are issues. If they can't address them and others like them, the flow to O365 will reverse back to on premises.
Document Library default views are often built into what amounts to an application, or at least a launch pad into one. It can be anything from simply adding some explanatory text in a CEWP at the top of the page (which is, after all, a Web Part Page) to full fledged functionality provided by additions of DVWPs, JavaScript, CSS, etc. in many cases, the view page ends up looking little like what it started out as.
There simply has to be a way to keep these view pages in the mix, as considerable investment of time and money have gone into them. One would hope "telemetry" will show many people *choosing* to stick with "classic" (in this case meaning "functional" and "useful") mode pages, even if all the "Working on it" stuff happens.
Change can be good, but not if it undoes past investment and successful implementation.
-
1,115 votes
The 5,000 item threshold is likely here to stay. We are aware that it takes awareness on both sides to get past this limitation: list owners have to build the right fields, indices, and indexed views so that end user queries can run successfully in large lists. And then, end users have to run the correct queries – they can’t just open the root of the list, they have to use a filtered, indexed view.
We want to pursue work that helps on both these ends – for example, proactively indexing more lists, making suggestions to list owners for views to create that will help end users, and helping end users at query time pick filters that will unblock their queries. Additionally, we want to increase our support for running more types of queries in large lists when an index is present – for example, instead of requiring an indexed…
Many times the only reason we need 5000+ items is to do some counts or sums. If those capabilities were there, it would cover a lot of ground. Other times we simply need more than 5000 items. Period.
This has always felt like an artificial limitation. In SharePoint 2007, there's no limit and I've built applications that retrieve 20000, 30000+ items using the SOAP services because I truly need to. This is the second decade of the 21st century. If the limit was 100,000 it might make more sense. 5000 is simply way too low. This is especially true since you guys tell us that lists con contain millions of items. If we stuff millions of items into a list and can't retrieve them, then it really defeats the purpose.
This is something I often add so-called "arbitrary JavaScript via injection" to do in existing list forms. If it were a built-in capability, that would be another reason for script in list forms to be off the table.