Project Time Reporter

Hello All

It is with great excitement that I share that news. rolling drums...

The Project Time Reporter iPhone app is available

This is so great. I had a chance to test it and it looks amazing.

Please have a read to the Microsoft article and download the app
More information on how to get started with the app is available here : Getting started with Office 365 Project Time Reporter

I may update this article later on based on my tests but I wanted to share the big news

Enjoy

Using target audience to prevent team members from accessing timesheet

Hi and welcome for this new blog post! 

The TechNet forums are a great source for improving our knowledge and experience since new concerns, ideas, workarounds or solutions always show up to enhance Project capabilities. Recently a user had a question about restricting timesheeting to a certain group of users. In other words, is it possible to prevent timesheet entry for a specific group? The first reply is "no", timesheet in Project Server and Project Online is a "all or none" feature as Dale Howard a fellow MVP said. A workaround I proposed subsequently consists in not enabling the "View Timesheets" global permission to a security group similar to the team member group. By the way, you can refer to this post for having all security references for Project Server versions. The description of the permission is "When this permission is denied, it prevents users from seeing the Timesheet Center link on the Project Web App Quick Launch menu". This permission does not lock down access to the Timesheet page and it is still possible for users to navigate to this page. But in addition, if you don't give access to the timesheet views to the associated category, it should prevent users in this group to submit timesheet. Well done! I've not tested it, but still, it is only a workaround, isn't it? I say workaround since it is a combination of configurations which are not intended to prevent users from doing timesheet. But put together, they more or less reach the same goal, with some weaknesses.

Then another person jumped in the thread and proposed to use the target audience. We are in a Project Server world, and evenif it is (more and more) part of the SharePoint ecosystem, we (or at least I) do not always instinctively think about exclusive SharePoint features for supporting our customer needs in terms of Project implementation.

So what is target audience and how does it work in a Project context (Project Online for my example)?

Here is what the TechNet article about target audience says:

"Web Parts in Microsoft SharePoint Server can be targeted to appear only to people who are members of a particular group or audience. When you do this by editing the Web Part in the browser, SharePoint Server assigns the GUID that identifies the audience to the AuthorizationFilter property of the Web Part."

Basically you define groups (be aware that they are independant from the Project Server security groups) in the Central Admin or inthe O365 admin center. Then you edit the webpart and associate it with the given group.

Figure 1: access the O365 admin center

Once in the O365 admin center, you can access the groups section. In my Online demo tenant, I already have preconfigured groups which contain users and are gathered under distribution lists. Either you can use one of those if you already have groups or you can create a new groups.

Figure 2: edit or create group

Since I'm not a SharePoint expert, I will simply edit one the existing group and remove myself from the group (note that I have to declare another user as the group admin). Then go to the timesheet and edit the page. Select the timesheet webpart and open the properties.

Figure 3: edit the timesheet page and open the webpart settings

In the advanced settings, select your audience with authorized timesheet users, apply the change and close the page edition.

Figure 4: configure the target audience in the webpart advanced settings

Once done, if I come back to the timesheet page, here is what I got: just a blank page:

Figure 5: timesheet page for users not belonging to the authorized audiences

As an advice, I would suggest to make a combinaison of configuration for preventing a group of users from doint timesheet:

1. Create a security group with the "View Timesheets" global permission not enabled,
2. Configure a target audience for the timesheet webpart with authorized timesheet users.

Doing this, you ensure that the users cannot see the timesheet link in the timesheet, and in case they copy paste the timesheet page URL, they still cannot see the timesheet webpart. However note that it requires that you maintain Project Server groups AND the target audience groups, which might be tedious and increase the administrator workload.

Do you have other ways to prevent users from doing timesheet? I'll be glad to hear it, so please share your thoughts!

Multilines administrative time categories in PS2013 timesheet

Most of the timesheet improvments brought by Project Server 2013 are for the end users. But anyway what's a good for the end user is obviously good for the administrators, isn't it? Since we do like those "win-win" new features, we will go in this new post through the multiline administrative time categories. Note that in PS2013, the administrative time has been renamed "non-project activities".

A common need from our customers is the ability to manage in their timesheets tasks that are not personal tasks, neither on a specific project. That's why the administrative time was introduced since 2010 version. As it is a pretty straight forward and simple feature, you might ask "what could be new with the administrative time feature?".

So let me ask how do you manage support activities with tickets? The best solution is obviously an integration with Team Foundation Server, but you might not have it in your organization or you might not have to budget for the PS/TFS integration. Thus the common way to manage tickets in previous version was to manage a specific support project, which was tedious due to the project's granularity.

The new multiline feature expands the administrative time categories to take into account this type of work allowing multiline to be added to an administrative category in a given timesheet. Below is the procedure to implement multilines administrative time.

The first step is to define your new administrative categorie (non-project activity) in the server settings, checking the "Allow Multipe Lines" checkbox. In this case, it is adviced to flag the ticket activity as "approval required". Note also that the administrative time categories can now be department specific.

Figure 1: new multiline administrative time category creation

Then when the user goes to his current timesheet, he'll be able to insert one or more tickets activities not related to any project, giving a custom name.

Figure 2: current user timesheet

Figure 3: inserting a noin-project activity in the current timesheet

Picking up the "ticket" category, the user will be able to enter a specific name for the ticket activity.

Figure 4: entering a custom name for the "ticket" activity

 After entering as many tickets as required, the timesheet will look like this:

Figure 5: timesheet with 3 "ticket" activities

Grouping by billing category will give to the user a clearer view of the ticket activities in the timehseet versus the other administrative lines and the standard (project) lines:

Figure 6: timesheet grouped by billing categories

As another nice improvment, we can mention that the non-project lines are now carried forward to timesheets for future periods, supporting in the best way possible this new multiline administrative time categories.

Hope you'll try and enjoy it. I'll be pleased to hear from you other use cases than the ticket use case presented here in this post.