Derek D'Amore
My feedback
-
20 votes
An error occurred while saving the comment Derek D'Amore
supported this idea
·
-
294 votes
We’re working on audience targeting in hub navigation. Hub owners will be able to set who should view certain links and those links are filtered out.
Trimming based on a users access to the site or resource is not in the plans.
An error occurred while saving the comment Derek D'Amore
commented
For those of you looking for a SPFx solution, see the following: https://github.com/bcameron1231/SharePoint-Framework/tree/master/react-hubsite-securitytrim-navbar
Derek D'Amore
supported this idea
·
-
1,604 votes
In modern pages, we open links within SharePoint in the same tab by default, and external links in a new tab. In the text web part, users can specify to open links in a new tab, but that isn’t the default behavior. Similarly, for navigation links, they follow the same rule (within SharePoint, same tab, external to SharePoint in a new tab). This is true of the modern web parts that support linking as well (hero, quick links, images, etc.) This is the pattern we’ve adopted for consistency.
After reviewing other areas of modern sites, like the site pages library, document libraries, lists, site contents, etc. we did find some different opening behaviors which we’ll review and resolve.
Can you help us understand if this pattern isn’t meeting your expectation, if we have some inconsistencies within modern pages we’ve missed, or if it’s the other areas of modern sites where…
An error occurred while saving the comment Derek D'Amore
commented
This honestly can't be that difficult to resolve... For system pages (Site Contents, Editing Views, etc...), DO NOT OPEN THEM IN A NEW TAB!!! It's crazy that we have to build custom extensions and deploy to the tenant to fix this.
Only open new tabs if the link is external to the tenant!
Derek D'Amore
supported this idea
·
-
472 votes
This feature is currently in progress and we are targeting summer 2020 for the release date
Derek D'Amore
supported this idea
·
-
504 votesDerek D'Amore
supported this idea
·
-
1,263 votes
Thanks for the suggestion. While this can accomplished via PnP Powershell today, we understand the desire to have a way to do it in the UX. We’ll add it to our backlog.
Derek D'Amore
supported this idea
·
-
727 votes
We initially didn’t enable the full width column on team sites due to the vertical navigation on the left and left justification of team site pages. How do you imagine it should work/look on those pages?
An error occurred while saving the comment Derek D'Amore
commented
Easy solution: remove the max-width restriction on the .CanvasZone class... It is currently set to 1268px which does NOT look good on larger resolution monitors.This would enable full-width of the page and also keep the vertical navigation on the left.
Derek D'Amore
supported this idea
·
-
902 votesDerek D'Amore
supported this idea
·
-
1,039 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,…
Derek D'Amore
supported this idea
·
Can't believe this doesn't have any comments or upvotes - ridiculous that we are basically forced to use use crazy workarounds or third-party tools for a standard setup in most sites...