I have been waiting for SP1 before blogging this as it might have frustrated a few people as pre SP1 there were some broken pieces here. The filter that you use when creating a view for everyone through Server Settings, Manage Views behaves slightly differently from that found on the client side when a user creates their own filters. So why is this? To explain I will use the example of filtering for particular project types. I will base this on the out-of-the-box Project Center, Summary view, with the field Project Type added.
Here is a view of my starting point view - where "Maintenance Project" is the term for Proposals and Activity Plans.
When adding a filter on the client in Project Center the filter works as most people would expect - it is doing a text comparison. If I want to just see Maintenance Projects I can set a custom filter where the Field Name Project Type contains the word Maintenance.
And then we see:-
But if we want a view that users can choose that automatically has this filter then we probably want to define it on the server. Setting exactly the same filter in the view definition for Summary in Manage Views gives this:-
Why is nothing showing up? The reason is that server side filters are not working quite the same as on the client - and are doing their comparisons against an enumeration of the Project Type defined as a number. Maintenance Projects have a Project Type of 4 - so with a filter set like this - where Project Type equals 4
we get what we want on the client with no client side filters set.
Enumerations for various of these kind of things can be found in the SDK. This different behavior makes more sense when you look at different language versions. If you have created a PWA site in French for instance you can set a server side filter for Maintenance Project without needing to know the French term. Remember on the server you can filter on a field that is not displayed - so it isn't as silly as it sounds...
I know in this case it wouldn't make much difference - maintenance is maintenance - but other translations may be more challenging (at least to me). This is a site provisioned in Korean, and viewed with IE set to French - just so you can see we are still looking at the same field.
I hope this helps you understand why there are differences in the filters - and how to use them.
Technorati Tags: Project Server 2007
Blogging in Microsoft does allow a great deal of freedom to the blogger, but the final test before hitting "publish" is always to think "What would this story look like on the front page of the New York Times, or Wall Street Journal". I think the worst case interpretation of this blog might give a headline like "Steve Ballmer got it wrong" says Brian Smith. But hopefully it wouldn't come to that (he didn't get it wrong anyway) - and it probably wouldn't be the front page, and probably wouldn't even make the Valley View (my local paper) - so here goes...
At the time of the project conference the work on SP1 was going well - still not complete, but homing in on the final few fixes. So we knew we would soon have a release date we could stick to - but we weren't quite there. Steve Ballmer did a great keynote on the future of project and work management - along with some demonstrations of what is coming in the next release - and then to Q & A.
The inevitable question was the date of SP1! Steve was really gunning for the customers here and pushing Mike Angiulo for a date. At that point we were still on track for December, but with the holiday period approaching even a small issue could push this into the new year - so Mike gave Q1 as a safe release date. Steve's interpretation of Q1 was "March at the latest". So the date was now March! That's how it happened - and I know because, to quote Max Boyce, "I was there". And nobody really got it wrong.
You all now know we delivered SP1 on 12/11. Plenty of customers are happy to see it earlier than expected - so what compels me to write this? There are now various interpretations of this "early" delivery - all the way from "Microsoft has cut testing to ship SP1 early" through to "Microsoft doesn't know what it is doing if they can cut 3 months from the plan" (with the added irony that comes with such a statement when one is on the Project support team ). This certainly does an injustice to the many people who have worked very hard on this release both in the different product groups and the support teams. I'm not looking for mutual back-patting here - I know there are still some bugs we didn't fix with SP1 - but SP1 is the first step. Now we move on to the rollup patch of hotfixes we have addressed since SP1 was locked down - then to SP2.
This posting was different from my usual technical stuff but I think the better understanding customers and partners have of how we work - and sometimes how decisions are made - is of mutual benefit. Let me know what you think. And in case this does get brought to SteveB's attention - I love this company too (and my job):).
And before you ask - this blog wasn't based on a bet to mention Max Boyce and Steve Ballmer in the same paragraph, but that has to be a first.
The December 2007 update to the SDK is now available
Project Developer Portal: http://msdn2.microsoft.com/en-us/office/aa905469.aspx
SDK Online: Project 2007 SDK in MSDN online library: http://msdn2.microsoft.com/en-us/library/ms512767.aspx
SDK Download: http://www.microsoft.com/downloads/details.aspx?FamilyId=2672F6F9-7028-4B30-99A2-18CB1EED1ABE&displaylang=en
New and updated topics since July:
· ERP Connector Solution Starter (20 topics)
· How to: Customize E-Mail for Project Server Notifications – this is an update of the project_programmability blog post.
· Project XML Data Interchange Schema Reference includes the following topics:
· New XML Elements
· Custom Field Data in XML
· Saving and Opening Projects in XML Format
· How to: Use XSLT Transformations with Project XML Data Interchange Files
· Project Data Interchange Elements includes reference topics for all of the schema sections, XML structure, and XML elements.
PSI Managed Code Reference:
· Additional descriptions of row properties in the following datasets in the Project Server Interface (PSI): LookupTableDataSet, LookupTableMultiLangDataSet, AlertSubscriptionInfoDataSet, ReminderSubscriptionInfoDataSet, QueueStatusDataSet, QueueStatusRequestDataSet, StatusingSettingsDataSet.
· Additional descriptions for event receiver methods.
· ERP Connector: Complete sample source code and test application for the ERP Connector.
· XML Schema: Revised XML data interchange schema, mspdi_pj12.xsd.Note: The Project XML schema is also now published on http://schemas.microsoft.com/project/2007.
· ProjTool: Now includes a dialog box for backup and restore of selected projects.
· SP1 library assembly: Redistribution license for the SP1 build of the Microsoft.Office.Project.Server.Library.dll assembly, and 32- and 64-bit copies of the assembly.Note: The MSIL code of the assembly is the same in both cases, so the file size is the same. However, we provide both builds to be consistent with the Project 2007 SKUs and because there may be differences in the future.
So with the Holiday season in full swing - what to give that difficult person who has everything. How about Project 2007 SP1? Yes, the links should soon be live, and until then you can prepare by reading the TechNet article at http://technet2.microsoft.com/Office/en-us/library/c3b86049-7cba-4b9c-8335-e37fb6e7518a1033.mspx?mfr=true
Please read all of the article - and also note that there is just one Microsoft Office Server 2007 SP1 which fits the whole family. So don't go looking for a file that just says "projectserver" as you won't find it. The file will be called officeserver2007sp1-kb936984... with the last piece of the file name referencing wither the 32 or 64 bit version.
If you do have Microsoft Office SharePoint Server 2007 then the SP1 file is the same - but the document you should read as well as the one above is http://technet2.microsoft.com/Office/en-us/library/f484f5f2-35bb-4d70-bf56-dd1c4c287c721033.mspx?mfr=true
And for any version of Office Server you also need to load the Windows SharePoint Services 3.0 SP1 first (it won't work if you don't, and it will tell you why), and both Service Packs need loading on all servers in the farm (except your database server if it isn't doing anything else). See the related links section of the article for more details on planning for the WSS 3.0 SP1.
For the client there is a separate SP1. It is not imperative that you load at the same time as the server - it will work if you load client first and do the server later - or the other way around. I will update with the links when they are all available - but planning is important - so get reading!
Links (But please READ the above documents FIRST!):-
Office 2007 suite SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyId=9EC51594-992C-4165-A997-25DA01F388F5&displaylang=en
Office Project 2007 SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyID=CEC3E1E2-D802-4A03-BC78-05C48472559B&displayLang=en
Office Project Language Pack 2007 SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyID=d322ba67-b199-4503-8aff-6813b320d708&DisplayLang=en
Office Servers 2007 SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyId=AD59175C-AD6A-4027-8C2F-DB25322F791B&displaylang=en
Office Server Language Pack 2007 SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyId=3A6C26FD-0BEB-40D5-8CBA-15164FAAB150&displaylang=en
Windows SharePoint Services 3.0 SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyId=4191A531-A2E9-45E4-B71E-5B0B17108BD2&displaylang=en
We don't seem to have done a good job in educating our customers on this topic, so thought I'd put this out there at least as a starting point and I'm sure we can also try and get better samples in the SDK.
One of the tricky things with setting custom fields for any entity (Project, Resource or Task - but also assignment or timesheet) is that you cannot always just call up the dataset, navigate to the custom field row and set the value. In many cases the row may not yet exist, so you need to add it, then set all the required properties and then update back through the PSI.
As an example if you create a project through the PSI it will have no project level custom field rows created by default, (except ones based on Lookup Tables with a default value forced) and any tasks will only have the "Health" special custom field set, and again- any with Lookup Table defaults. If you then open in Project Professional and just save again, you will then have added any calculated fields at the project level, along with any calculated fields at the task level. Also at this stage the project summary task (Task 0) is populated with any task level fields with roll up to summary level set.
As my server does not have all the possible combinations of fields I may be missing something here - but ProjTool is a great way to see just what is in the dataset at any time.
So whenever you are setting custom fields first see if the row already exists - and if not you will need to add a customfieldrow to whatever dataset you are working with. Then the next step is to set the appropriate properties - which will depend on the type of field you are setting (defined by FIELD_TYPE_ENUM), and the dataset you are adding it to. For instance a ProjectCustomFieldsRow will need the PROJ_UID. A TaskCustomFieldsRow will need the PROJ_UID and the TASK_UID. A Timesheet CustomFieldsRow will need the TS_UID to identify the timesheet and a TS_LINE_UID to identify the specific line. Then for any row you need to set a new GUID for the CUSTOM_FIELD_UID, the MD_PROP_UID and/or the MD_PROP_ID to identify the specific custom field and the actual value you want to set in the appropriate property as detailed in the following table.
Set field value in:
Value in 1/COST_MULTIPLIER dollars
A date value. HIWORD contains days off set from 1/1/84. LOWORD contains minute off-set, ranging from 0 to 1440, from 12:00 A.M. (midnight)
Value in 1/DUR_MULTIPLIER minutes
DUR_VALUE and DUR_FMT
A string value
Index into yes/no string table
A number value
FINISHDATE is also listed in the SDK but is not applicable to these custom fields. Lookup Table isn't specifically a custom field type - but I added it for completeness. If the custom field is based on a Lookup Table then the LT_STRUCT_UID of the specific entry in the Lookup Table is entered in the CODE_VALUE property. For those that accept multiple values there will be a row with each CODE_VALUE - not a single row with multiple CODE_VALUES.
Another property you will come across in the datasets is the INDICATOR_VALUE - which will hold the enumeration value for the indicator to be displayed based on the custom field settings.
No code sample just yet on this - but I will try and come up with some shortly. I am looking into a support incident where values are being set for summary tasks (or rather they are not) - these are likely to be read-only if "roll-up" is set, so be aware of that.
*** Update *** Finally got a sample together - hope it is worth the wait - http://blogs.msdn.com/b/brismith/archive/2010/08/25/project-server-adding-custom-fields-to-projects-and-tasks-using-the-psi.aspx
The ProjCFDlg.cs sample in ProjTool and the Add Project Custom Field option on the Project Details pane of ProjTool is a great place to look for an example that covers this well.
Other things to be aware of are that constraints applied to the custom fields will need to be adhered to. If the custom field only allows selection of codes with no subordinate value (leaf nodes) then the PSI cannot over-ride this.