Joel Chmiel
My feedback
-
354 votes14 comments · SharePoint Dev Platform » SharePoint Framework · Flag idea as inappropriate… · Admin →Joel Chmiel
supported this idea
·
-
593 votesthinking about it · 24 comments · SharePoint Mobile App for iOS · Flag idea as inappropriate… · Admin →Joel Chmiel
supported this idea
·
-
29 votesJoel Chmiel
supported this idea
·
-
9 votesJoel Chmiel
supported this idea
·
-
4,131 votes
Thank you everyone for your feedback on this item. We recognize this is a valuable feature and are looking at ways we can address it. We do not have a timeline to share at this point.
Joel Chmiel
supported this idea
·
-
164 votes
An error occurred while saving the comment Joel Chmiel
supported this idea
·
-
5,755 votesworking on it ·
AdminSharePoint UserVoice Admin
(SharePoint UserVoice Admin, Microsoft SharePoint)
responded
Providing the ability to scale from renaming individual sites, to all sites within a SharePoint tenant, while ensuring a consistent user experience across M365 is a complex problem. We have been working hard on this long-awaited feature and are currently validating this with a subset of customers in a closed (no longer accepting nominations) Private Preview Program. As we consolidate their feedback, we will provide another update in the next few months.
Joel Chmiel
supported this idea
·
-
420 votes22 comments · SharePoint Dev Platform » SharePoint Framework · Flag idea as inappropriate… · Admin →
We are actively working on new extensions like covered in SharePoint Conference 2019 breakout sessions. There will be extensions on the page content and ways to replace the native menu experience and/or footer experience.
Joel Chmiel
supported this idea
·
-
1,170 votes
We know wikis are critical to sharing knowledge within your organization! We’ve been slowly building capabilities to share information more easily with our focus on modern pages and web parts. And with that work, we’ve been adding some of the capabilities we hear you want when people refer to wikis (easily add links to other pages or content, add metadata to each page to help people find and categorize it, roll-up content based on that metadata to show groupings of like content, etc.) But we know this isn’t all that’s required to have a great wiki. Many people also want wiki linking syntax e.g. [[]], we don’t yet support that, but we do support ctrl/command + K from the text web part to search and find pages on your site. We’ll be working on adding wiki syntax shortly. We know you also need easy roll-up pages, maybe an index page,…
Joel Chmiel
supported this idea
·
I'm working with a client on a library now and we're running into this. We're trying to move to modern, but this is a big deal / potential dealbreaker.
While things have improved...we now receive back the first 140 parent terms. (I don't know if that's because there's some children terms or if 140 is the new limit.) It's still very frustrating that there's no way to bring back more terms. It makes the field unusable for filtering.
Ideas:
- Add a text box at the top of this filter to allow for manually bringing back a subset of terms starting with whatever is typed.
- Add a next button to "page" through terms...which could make a call back to the term set, thus reducing the size of each query (assuming that's the real reason there's an arbitrary limit).
In any case, this worked in classic with "Key Filters", but doesn't in modern. It's a real issue for users trying to move to modern. In this case, the term set has about 300 terms, so it's not huge, but we simply cannot use it for filtering. In another library, there's a term set with more and we'll have the same problem.