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.
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.
140 votes8 comments · SharePoint Dev Platform » SharePoint APIs (CSOM/REST/Server-side) · Flag idea as inappropriate… · Admin →
@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.
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.
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.
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.
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 filter for every query, maybe an indexed could suffice.
No guarantees or timelines yet, but that’s the way we’re thinking about the problem. Does that sound reasonable?
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.
219 votes16 comments · SharePoint Dev Platform » SharePoint APIs (CSOM/REST/Server-side) · Flag idea as inappropriate… · Admin →
Working on it and first release is in the Preview, like mentioned in the comments – See more details from SharePoint development center under dev.office.com – http://dev.office.com/sharepoint/docs/spfx/sharepoint-framework-overview
I’m totally with you that this type of “non-app” approach needs to be a supported option. The reality is that apps/add-ins are overkill for smaller n, and are out of reach for citizen developers. An approach *like this* would be a step in the right direction if it were "supported".