It was recently noted by one of our technical team that when setting up Calendar overlays the list of colours available seemed a bit screwed up with the same colour name appearing next to different colours. This issue is a result of the colour palette used to generate the custom Look for all sites in our SharePoint environment and is actually not a currently defined by Microsoft as a bug even though it would be nice to have a bit more clarity and control of how these are determined. So the question was asked ‘can we change these colours?’
I have done some additional research and confirmed that the colours presented to the user for calendars are generated by SharePoint based on the theme selected for the web site (in our case the custom Look) and not immediately customisable for calendars out of the box. Specifically each one of the 9 colours defined comes from the definition of Accent 1-6, Hyperlink, and 2 of the text/background theme colours in the custom Look. This is why the first 6 colours map directly to a colour defined by the accent shown in the SharePoint Color Palette Tool. I think the Hyperlink text/background colours are generated based on the definitions within the custom Look.
There are a number of solutions for implementing customisations but these are point solutions that apply to a specific calendar in a specific site and end users would need to deploy the solution themselves to customise the colours in their calendars. We could possibly look at updating our custom site provisioning app to deploy this customisation with a calendar when the site is first created.
For future reference here a few of possible point solutions (all use a similar approach)…
I recently deployed a new version of a provider host SharePoint app that updated the app icon and the app name. Whilst the deployment was successful and I could see the new name and icon in the ‘add an app’ area of team sites the appearance of the app as it exists in the Site Contents had not changed. When a new team site is created this custom app is pre-provisioned on the site so the user doesn’t have to add it themselves. Because of this I thought maybe the change would only occur for new teams sites that are created so I created one to check. Unfortunately this wasn’t the case and the original default icon and old app name were still associated. I also noticed that the version was not correct but strangely, if I clicked through from the app to the app details page it showed the correct details for the new version, the name was correct and the new app icon was displayed.
After working through some possible reason I found that whilst the app had been deployed I hadn’t been to the app catalog for and allowed it to push out the update.
To do this I went to the app site for the SharePoint tenant (e.g. <tenant url>/sites/apps) and then went to the Site Contents. Here I found a note under the app “An update for this app is available.” with a link on the word update. I then clicked through the update link. Here I found that whilst the “Add It” button was disabled SharePoint was recognising a new version was available and providing a button titled “Get It” (shown below).After clicking on the Get It button I was asked to verify the trust in the app which I did and once I returned to an existing team site and refreshed the Site Contents view found that the icon, name and version details were all updated to the new values.
I was recently redeploying a provider hosted SharePoint app from development to production. I had completed the app component of the deployment but hadn’t made any changes to the web component. The updates to the SharePoint app, in this case a new icon image and more meaningful app title, were successfully deployed and I could see them. I was able to add the app to a site with no problems but when I tried to run the app and was redirected to the azure web site I received the following error:
System.IdentityModel.Tokens.SecurityTokenException: Invalid issuer or signature
For the life of me I could sort out what had happened to cause this error or how to fix it as everything seemed to have worked correctly with the deployment.
Eventually I worked out what had happened. I had deployed the app from development to production but had not corrected the Client Id and Client secret to the values that had previously been generated for production. This meant that when the user was redirected to the production azure web site the client details in SharePoint, in this case from development, did not match those configured into the associated Azure web site and the end result was the above error. Once I returned to the visual studio solution and corrected the Client Id/Secret in the web.config and the publishing profile and deployed a new version of the app component the issue was successfully resolved.
From today (5th January 2015) until the end of May this year Microsoft is once again offering those wishing to sit a Microsoft Certification Exam a second shot at passing the exam if they fail the first time around.
There are of course conditions associated with the offer but these are clear and reasonable such as booking the retake within 30 days of sitting the first attempt.
Full details can be found at the Microsoft Born To Learn blog
Great news. I just successfully compeleted the Microsoft Partner Network course and exam for the Pre-sales Technical Specialist qualification. So the correct title is Microsoft Sales Specialist: Collaboration, Content Management and Search. Here is the associated official logo…
Have you had problems with merged cells in excel exports from Reporting Services reports? I have so I did some hunting around and found some information that looks like its solved my problem.
Add this post and the information at the following MSDN blog and you should have your problems with merged cells in excel exports from Reporting Services reports nailed.
Ed Spencer's Blog
Lets be completely direct here. Cell merging in Sql Server Reporting services after exporting to Excel, is a common nightmare.
It happens because the engine that transforms the report tries to do so on a presentation basis.
I have been developing reports in SSRS for a few years now, and here are the best ways around the issue that I have found:
1. Don’t use standalone textboxes for titles, or any non-data elements.
Rather than fiddle with these for hours trying to get them to line up, just insert another row or two as headers above your data driven report element (e.g. table). You can then play with the presentation of the cells to make it look like it isn’t part of the same table. This can be done by colouring certain borders white to give the impression that there is nothing there.
2. Use points and not centimetres when…
View original post 96 more words
I discovered some interesting behaviour in the Excel export files from Reporting Services today. Some users of the system I’ve been working on have a requirement to periodically export the data in MS Excel format so they can do some additional analysis. They recently began testing the export function on the report in question and have noted theat they are unable to generate a pivot table because there are additional empty rows and columns before at the top and on the left of the table in the spreadsheet.
My assumption was that when you export to Excel the export rendering engine would only attempt to output the tables on the page. Obviously my assumption was invalid and the rendering engine attempts to render into Excel as closely as possible to the web version including any whitespace around the report. The more whitespace the more blank cells, rows and columns will appear in the Excel export. The quick solution to the issue is to simply move the various object on the report so the edges butt up against each other and the sides of the page. Removing the whitespace in this way means the rendering engine wont include additional empty rows or columns in the spreadsheet.
Note also that I’m note using a head or footer for the exportable version of the report. These will also cause issues if the purpose of the export is to apply a pivot table to the data for analysis.
In-line images also cause issues in the exported Excel spreadsheet. I have small icon in cells in the table with actions defined to open sub-reports. The images were embedded in rectangle objects to enable control of positioning and size. The behaviour I saw in the Excel export spreadsheet was that I had merged columns around the images and this again interfered with apply a pivot table to the data. My only solution here was to remove the images from the exportable version of the report.
Finally, the report had two tables on the page. The first was a summary table and the second was a table containing the detail row for every item meeting the users selection parameters. When the user exports to Excel both tables appear on the one spreadsheet and the user is unable to simply create a table or pivot table on either of the data tables. Ideally the user wants each data table on its own spreadsheet. The resolution to this is again simple if you think in terms of what the rendering engine is trying to do i.e. render what it sees on the page into a similar looking spreadsheet. First we want to force the second table to appear on a new page. This is achieved by configuring the tablix for the first table to put a section break after it (see image below). Once this is configured the second table will appear on a separate page and the rendering engine will interpret the section break as needing to put the second table onto a second sheet in the Excel file.