Showing posts with label Sharepoint. Show all posts
Showing posts with label Sharepoint. Show all posts

Friday, April 9, 2010

Sharepoint recurring calender events filter

We are improving our processes using Sharepoint. On paper everything works well. In real life, its sometimes difficult.

I was trying to create a agendaview of the current week in Sharepoint. This wasn't supported default by sharepoint.

There is a workaround to fix it:
How To:
If there is a calendar, and you want to create a view where only events from today up to the next 60 days (or how many days out), here is how you do it:

  • Add a column to your calendar.
  • Name it “Date” and make it a calculated field.
  • Add “Start date” to the formula, and select “add date only”.

What this does is it creates a column that is filterable, because Start Date is not, and automatically populates the content of this column with the start date of the event.

  • Next, create a new view for the calendar, name it “Upcoming” (or whatever).
  • Select whatever fields you would like to display. If you are creating a view to show on another page, like the home page, and you just want a quick list of upcoming events, you might want to just have title and date fields display.
  • Under “Filter”, select: Date is less than or equal to[Today]+60andDate is greater than or equal to[Today]+60


http://designshare.wordpress.com/2007/11/02/filter-calendar-view/

This works for normal calendar events. But when using recurring events the start date defaults to the day the event was set to start. While the "Start Time" column displays the different dates as they progress, if you do the calculated field on "Start Time" it will only return the start time of the entire recurring event. So if you told the recurring event to start on 8/1/08, the Start Time may show 8/5/08 (today) but the calculated column will still show 8/1/08 regardless.

I did not find a fix yet!

http://abstractspaces.wordpress.com/2008/05/14/filter-list-view-by-current-week/

http://weblogs.asp.net/gunnarpeipman/archive/2007/10/09/filtering-sharepoint-calendar-by-start-time.aspx

Monday, November 16, 2009

SSRS 2008 deployed on sharepoint BI gives a drilldown error (rsItemNotFound)

We created various reports with drilldown functionality on SSRS. This worked great and we assumed it would work the same way on Sharepoint.

So we deployed the reports, but we discovered after some testing that the drill down functionality didn't work anymore. It displayed the error: The item 'http://oursharepoint.nl/reports/reportslibrary/report1' cannot be found. (rsItemNotFound)

While researching this error, we came to the conclusion that default the underlaying report is accessed without extension. SSRS knows which report need to be called, automatically filling in the RDL extension. Sharepoint, on the other hand doesn't know . There are multiple types of reports and therefor it doesn't automatically knows which extension it needs to use.

Summarizing: SSRS just needs the name, Sarepoint expects an name and extension.

So we could build the report in such manner that it works with sharepoint, but then i wouldn't work with SSRS anymore. So we need another way. To fix this, try the following:

Open the report in Visual Studio

Go to the link which provides the drilldown

Open the properties


Go to actions

Edit the expression, which calls the report



Finally add the following expression: IIF(Globals!ReportServerUrl Like "*http*", "report1.rdl", "report1")



Using the Globals!ReportServerUrl we can determine if the url is a http protocol or not. If so, its called by Sharepoint and we need the extension (report1.rdl), if not, it's called by Visual Studio and we don't need the extension (report1).


Now the reports opens if its called in Sharepoint or in SSRS.


http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/002ccd0b-a850-4c5f-8904-38ac5bcbe5c3/

Update:

The error is caused when the underlaying report is called using an expression. If you point straight to a report without expression, it works fine on Sharepoint or SSRS. But when you use an expression to determine which report needs to open, it needs the extension and the workaround above still solves the problem.




Thursday, October 22, 2009

Wrox Professional Microsoft Sharepoint 2007 reporting with SQL sever 2008 reporting services review

I'am currently working on a Microsoft Sharepoint business intelligence project.

To prepare for the project I read the book Wrox Professional Microsoft Sharepoint 2007 reporting with SQL sever 2008 reporting services.

What a disappointment that was! Do not read or buy the book, if you are a tiny bit familiar with reporting and deploying. I really thought it would go in-depth, combining Microsoft Sharepoint and business intelligence. Talking about structure, function, enc. But that’s not the case.

The first 9 chapters is about creating reports and deploying. Chapter 10 is about some overrated and complex AJAX solution to deploy and display your reports. Chapter 11 is about gauges. Very short and obvious.

Off course everybody needs a basic understanding and every organizational needs are different, but there is an certain essential that is missed.

Deployment is very imported, but not worth 3 chapters. Especially not when your pretty new to this, and that’s the books audience. You want to know how to create a fast, efficient and good solution for the end-users.

Summarizing:
If you want to know more about deployment and care less about how the reports are shown and interact, this book is for you (although is pretty expensive for what you get). If not, please find another book. There are much better books out there.

http://www.wrox.com/WileyCDA/WroxTitle/Professional-Microsoft-SharePoint-2007-Reporting-with-SQL-Server-2008-Reporting-Services.productCd-0470481897.html



Professional Microsoft SharePoint 2007 Reporting with SQL Server 2008 Reporting Services
Coskun Cavusoglu, Jacob J. Sanford, Reza Alirezaei
ISBN: 978-0-470-48189-9
Paperback
480 pages
September 2009

Monday, October 19, 2009

Setting target audience in Sharepoint using Active directory

I'am currently working on a Microsoft Sharepoint BI project. It's a rough road, but we are getting there. The base foundation for Microsoft Sharepoint users and security is Active directory.


What I tried to accomplish is a portal page with three main parts:

- Dynamic reports, showing only those reports relevant, depending on the usertype;

- A main KPI about the topic;

- Key figures about the topic.


As said, I want to create the reports dynamically. This is for two reasons:

1. For more effective transaction and interaction with the enduser;

2. For security reasons.


i.e I have 2 types of users:

Managers;

Operational employes.


Both usertypes need to see different reports. The employe wants to know if the have enough supplies left and the type of orders.


The manager on the other hand wants to know if his department is meeting the organizational goals. He want information about salaries, costs, enc. The manager does not need to know the order details, cause it isn't relevant to his job and the employe doesn't need to see the main salaries for security reasons.


So I created these two active directory groups and added the users. I created the same group in Microsoft Sharepoint.




The next step is adding a report to a webpart and set the target audience to the appropriate group.



But there things went wrong. Altho it sounds doable, Microsoft Sharepoint doesn’t allow Active directory groups in a Sharepoint group to be assigned to a target audience. It could cause performance issues.


There is a second but: I’am not happy having to create an Active directory group and then the SAME Sharepoint group for management reasons.


...but there is hope. For my first concern, there is a hotfix available:



SYMPTOMS

You add Active Directory user accounts and Active Directory group accounts to a group in Microsoft Office SharePoint Server 2007. When you designate the SharePoint group as the target audience for a specific Web Part, some user accounts in the SharePoint group cannot access the Web Part.


CAUSE

This behavior occurs because only individual user accounts that are assigned to the SharePoint group are recognized as the target audience. Only those individual user accounts can access the Web Part. However, when you add an Active Directory group account, the users in the group account are not recognized as part of the target audience. Therefore, user accounts that reside in a group account that has been added to the SharePoint group cannot access the Web Part.


RESOLUTION

To resolve this issue, apply the hotfix package that is described in the following Microsoft Knowledge Base article:

942819 (http://support.microsoft.com/kb/942819/ ) Description of the SharePoint Server 2007 post-Service Pack 1 hotfix package: January 31, 2008

Back to the top


http://blog.tomaselfving.com/2007/12/moss-audiences-with-sharepoint-groups.html

http://support.microsoft.com/default.aspx?scid=kb;en-us;948681


Hotfix

http://support.microsoft.com/kb/942819/