@Martin Coupal
Albeit that this thread is somewhat old now, I nonetheless thought I'd share my 2 cents as no one else on this thread has shared any meaningful comments wrt what exactly is causing this particular issue nor why the behaviour experienced is not necessarily consistent for all users nor what steps you can follow to reproduce this issue and last but certainly not least what you can do to fix it :-).
Let me begin with the last point I mentioned above, given that's what everyone reading this response is wants to know. The answer in that regard is quite simple but equally not the answer most of you want to hear.
Basically you need to use a SharePoint app tab to display SharePoint pages because should you choose to alternatively use a Website app tab to display SharePoint page you and other users in your Team will encounter this issue when clicking on links to other site pages that are configured to load in the same Website app tab window. Links on any site page configured to load in a new web browser tab will work as expected and not experience similar behaviour to links configured to load in the same window,
So why then may some if not all of your links configured to load other site pages in the same Website app tab window work as one would expect them to, whilst this may not be the case for one or more other users when viewing the same SharePoint site page within the context of a Website app tab?
Great question, and extremely difficult to identify the exact root cause for this behaviour.
The easiest way for you to reproduce this exact behaviour on your own workstation, especially if you are addiment the problem doesn't exist on your workstation, is to clear the Microsoft Teams client app cache on your workstation, and subsequent to which re-evaluate the user experience / behaviour when viewing and navigating to other site pages via your SharePoint site(s) embedded in a Website app tab(s) in your Teams workspace.
Clear Teams Cache
Should you clear the Teams cache on your workstation I believe every single link configured to load a site page in the same Website app tab associated to your SharePoint site (page) will no longer work for you on your workstation and when clicking on such links in Teams nothing will happen.
Importantly, no other users will be impacted by the steps / actions to reproduce the issue as detailed above,
Another interesting observation is that if you hold down the Ctrl key and click on a link to load another page on the site that hasn't been working, you should observe that annoyingly that the page should now in fact load, albeit in a new Team web browser window which does little more than prove that the Website app tab can access the "broken" links when it wants to.
Ok, but what if you don't want to completely break all the links that open site pages in the same Website app tab window if you were to clear the Teams cache on your workstation. Thankfully there is another relatively easy way to reproduce the issue without wreaking havoc in your own MS Teams client app or anyway else for that matter. For this test you would need to perform the following steps:
- In your SharePoint site create a new site page. Update the Title of the page as you so wish, Publish the new site page, subsequent to which a popup window will be displayed in the top right corner of the page, from which you can copy the URL to the new page to your clipboard. Close the popup window.
- Navigate to any other page on your SharePoint which you can use to add a new Quick Links webpart or alternatively you can use an existing one instead. Add a new link in the Quick Links webpart, input any name of your choosing and paste the URL to the new site page to use for the new link you're adding. Save the changes to the site page and Publish the latest updated version of it.
- To further understand the nature of this issue, I highly recommend navigating to another page or your site where you can equally add a new link to a Quick Links webpart, which you should equally associate the URL for that new link to that of the new site page your created in the first step. Save and Publish the changes to this 2nd site page you have modified.
- Having made a couple of minor changes to the SharePoint site, that brings us to the really interesting part of this test. In the Teams client app navigate to your Teams workspace containing the Website app tab that you have associated to your SharePoint site.
- In the Website app tab, navigate to the 1st site page you modified to as to add a new link in the Quick Links webpart that you associated to the new site page you created for this test. Click on this new link you added and observe the behaviour experience. The new site page should load in the same Website app tab window. However nothing happens. I would greatly appreciate any feedback should this not be the case for all user.
- Perform the same test on the 2nd site page you modified as you have done for the 1st site page modified. The outcome should be the same - i.e. nothing happens when you click on the new link added to a different Quick Links webpart located on a different site page.
- So this begs the question - can one fix this behaviour?
- This answer is sort of but not for teams having anymore than a few (5 or so) users and even then you might just as well use the SharePoint app tab instead.
- Regardless I can't state you can sort of fix this without articulating how you can "fix" it.
- Thus the following steps, as simple as they be, can be followed so as to get links to site pages in a SharePoint site embedded in a Website app tab that do nothing when you click on them remediated such that they will thereafter behaviour as one would expect them to.
- This remediation solution requires you to add a SharePoint app tab associated with your SharePoint site - I believe this tab can be added to any Teams workspace you have access to and on any channel in the Teams workspace for that matter. I don't believe it needs to be added to the same Teams workspace containing your existing Website app tab.
- Having added your new SharePoint app tab to your Teams workspace, navigate to that tab whereupon your SharePoint site should load and render as it does when you alternatively view the site in the context of your Website app tab.
- In the SharePoint app tab navigate to either of the 2 site pages you earlier modified so as to add a new link in a Quick Links webpart on each of the 2 site pages, in both instances associating each link to the URL of the site page you had just created in this SharePoint site.
- Regardless of which of the 2 site pages you have now navigated to, click on the new link you added to the Quick Links webpart on that page, Observe the behaviour. The new site page you created should now successfully load in the SharePoint app tab window, unlike the behaviour you had just experienced when attempting the same action but within a Website app tab.
- At this point you do not need to navigate to the other site page you had modified so as equally add a link to the new site page in a Quick Links webpart.
- Navigate back to your Website app tab associated with your SharePoint site in Teams. Navigate to either of the 2 site pages you modified and added a new link to the new site page in a Quick Links webpart.
- Click on the link to the new site page you create in the Quick Links webpart and observe the behaviour. Does the new site page all of a sudden miraculously load in the Website app tab window whereas before nothing happened when clicking that link? If it does, navigate to the other site page you modified and check whether clicking on the new link you added in the Quick Links webpart to your new site page equally now loads as you would expect it to.
- Hopefully all the steps to reproduce and furthermore remediate the issue discussed on this thread don't just work for me, but work for everyone.
- There are some key takeaways from this workaround, and none of them are not desirable findings. This workaround applies to a single user, further isolated to a specific workstation, as well as to the MS Teams desktop client app, the MS Teams web client app (and web browser used).
- Put differently should I load the MS Teams web app in a web browser on my workstation and navigate to the Website app tab I used for the remediation workaround I described above, the same links I had "fixed" in the Team desktop app would still be broken.
- Equally every user would have to perform the remediation workaround steps themselves.
- I believe it would be impossible to automate these remediation workaround steps, with the exception of the solution one user on this thread whereby using a PowerShell script (I think) iterating through all the Teams workspaces removing Website app tabs associated with SharePoint pages and alternatively adding SharePoint app tabs associated with those SharePoint pages instead, where necessary.
The biggest issue I have with this behaviour in Teams Website apps tabs associated with SharePoint site pages is that Microsoft do not support the configuration of SharePoint app tabs in Teams Templates.
This means you can't add a SharePoint app tab to a channel in a Teams Template and associate that tab with a SharePoint site page. Each time a new Team is created using such a Teams Template, someone would have to manually go and associate the relevant SharePoint site page to the SharePoint app tab in each new Teams workspace provisioned, which completely defeats the purpose of using Teams Templates to automate the provisioning of new Teams workspaces for certain scenarios.
Conversely with a Website app tab you can associate it with the URL to a SharePoint site page when you add it to a channel in a Teams Template, Should you do so there would be no need for someone to manually go and associate the relevant SharePoint site page to the Website app tab in each new Teams workspace provisioned. Unfortunately per this thread one can't leverage this approach because of the bizarre behaviour experienced when clicking on links to other pages on the site that are configured to load in the same window when using the Website app tab to embed the associated SharePoint site. The workaround is even more bizarre.
This behaviour is seemingly identical when using the Teams web client app - i.e. logging into Teams in a web browser app such as Chrome.
Regards,
Brian
