K2 offers Management Work list web part and Work list web part for managing work lists. However, there are situations when the web parts need to be customized to meet additional business requirements. Here are some use cases that may require the customization of the available K2 web parts:
- An application has several SharePoint sub sites where information is managed for project sub-teams. The teams should only see the process instances and work list items associated with them. The K2 Work list web part does not provide a comprehensive filtering scheme to filter process instances or tasks based on business data stored in process data fields.
- Project managers responsible for a project should be able to see all tasks for that project. The management Work list web part does not provide a way to filter tasks by process instances; when a user has Admin rights to a process, it lists all tasks for all instances of the process regardless of the project. This will be a topic of our next blog.
- An application has several SharePoint sub sites where information is managed for project sub-teams. The teams should only see the process instances and work list items associated with them. The K2 Work list web part does not provide a comprehensive filtering scheme to filter process instances or tasks based on business data stored in process data fields.
- Project managers responsible for a project should be able to see all tasks for that project. The management Work list web part does not provide a way to filter tasks by process instances; when a user has Admin rights to a process, it lists all tasks for all instances of the process regardless of the project.
The K2 Worklist web part provides a mechanism to filter tasks, but that’s limited to out-of -box fields such as Folio, Originator etc. Often there is a need for additional filtering based on custom process XML fields (example: Project-Id). The source code for the K2 Worklist webpart is available on K2 Underground. A relatively straightforward modification can be made to accommodate the additional filtering needs. This avoids re-inventing the wheel and building something from scratch while providing consistent user experience in line with other out of box K2 webparts.
Following is the structure of K2 Worklist web part in Visual Studio solution explorer. The code is fairly complex and contains a lot of functionality. However, only the two highlighted .cs files need modifications:
- Tasklistcontrolpage.cs
- Tasklistwebpartfactory.cs
Execution starts in Tasklistwebpartfactory.cs file that defines the TaskListWebPartFactory class which is the actual webpart class derived from ASP.NET webpart class.
Public class TaskListWebPartFactory : System.Web.UI.WebControls.WebParts.WebPart, IWebEditable.
- This TaskListWebPartFactory class is a container that loads an instance of TaskListControlPage class
- The render() method of the TaskListControlPage class calls the ApplyFilter() method which actually sets the filters for the Worklist items.
We let the ApplyFilter() method do its job of setting the default filters (set by end user using Edit webpart properties page) and then applied our additional filtering on top. This is accomplished by adding a call to AddCustomFilter() method that we created. This custom method added desired filter(s) to the TaskListControlPage class’s CurrentConfiguration property mimicking how the out-of-box ApplyFilter() method handles user defined filters. Following is the code snippet.
private
void AddCustomFilter() {
if (!string.IsNullOrEmpty(_projectIdValue)) {
CurrentConfiguration.Criteria.AddFilterField(SourceCode.Workflow.Client.WCLogical.And,
SourceCode.Workflow.Client.WCField.ProcessData,
"", SourceCode.Workflow.Client.WCCompare.Equal,
"");
}
}
- The <Process Field Name> in the above code needs to be replaced by the name of the process data field that holds the project name and <Process Field Value> replaced by the project name to filter on. In our implementation, the project name was stored in the SharePoint property bag for the site, and the K2 process was designed to grab that value from the context and save it in a process data field (specified in <Process Field Name>) when a process instance is launched. The web part can access that project name to filter on from the containing site’s property bag and use that in place of <Process Field Value>.
- The ApplyFilter() method is not declared as protected that can be overridden in a derived class, therefore the implementation modified the original ApplyFilter() definition rather than creating a derived version that refines the logic.
- Everything else beyond that point is unchanged and this customized webpart displays the custom filtered set of worklist items from the process instances that match the process field value mentioned in the query.
Summary
We were able to provide a webpart that really trims the noise and shows only the Worklist items and process instances that are relevant to the user.
