Creating KMKey Patterns
A KMKey Pattern is the way to say how we can work on each type of our projects or files. It is like an object type, plus a workflow, plus a set of tasks, plus a set of subojects, plus permissions definition, plus documents to generate, etc. Similar concepts, in other areas, are business patterns or ISO 9000 process definitions. For instance, a KMKey pattern could be used to define how our commercial staff should make their offers and hind tracking, or to define how our technical staff should prepare their technical documents.
In the current stage (January 2007), there is not an existing user interface to easy define new patterns, but the Zope Management Interface (ZMI) need to be used to do it. In the future, we are planning to create a end user GUI to manage the most typical cases. Here we will describe the steps needed to create a new KMKey Pattern nowadays:
1. The first step is define the schema, this is, which fields will compose it. Knowing that a pattern could use more than one schema, you could go to the ZMI, to your_site/portal_schemas, and create a new schema with its fields and data types
2. Next, we should define a layout: the widget to be used for each field, and their position in the screen. To do it, got to ZMI, to your_site/portal_layouts, create the new layout, and in it add the set of widgets. Then go to the tab Layout to define its position in screen. You should also know that a pattern could use more than one layout at the same time.
3. Well, we have the data definition we want (schema), and how to show it (layout). Next step is to create a portal type. Each pattern will be an unary relation (one to one) with a portal type. In fact, a KMKey pattern is an extension of a portal type, doing all what it does, plus a lot of other features. Go to ZMI, your_site/portal_types, and create the new type. The easy way is to copy de “KMKey Project” type, and rename it to “kmkey_yourpattern”. Then edit de portal type, and assign the schemas and the patterns you want to use. If you are a developer, you could also want to change de Product name and Product factory method, forcing the portal_type to use your own python class (that should inherit from KMKeyDefault.unit.KMUnit, anycase).
4. We have a new usable type. Now we should say how this could be used. Firstly, let's say that our new type could be created only inside Projects Containers. Go to ZMI your_site/portal_types/KMKey Projects Container and add your type to the list of checked types in the Allowed content types field
5. Secondly, we should define which workflow should be used in our new portal type. Go to ZMI your_site/workspaces/.cps_workflow_configuration and add a chain for your new portal type. If you haven't defined an special workflow for it, then choose the kmkey_folder_wf
6. This step is just for help the application to show your new portal type in trees structures. Go to ZMI your_site/portal_trees/kmunits tab Properties, and add your type id to the list of Portal Types indexed by the tree
7. Now, if you need new roles to be used inside projects or files created from the new KMKey pattern, you should create this roles and their permissions. Go to ZMI, your_site, tab Security, and create the new roles as local roles. Then go to your_site/workspaces, to the tab Security, and check the permissions you want to assign to each role. You can read http://www.kmkey.org/sections/blogs/santi-camps-blog/2006_10_04_managing-permissions-in for an extended explanation about permissions in KMKey
8. We have finished to work with ZMI. Let's go to the application, using a manager user, and visiting your_site/workspaces/kmkey/folder_contents, or any other project container, if you have a tree of them under kmkey. Copy and rename an existing KMKey Pattern, o create a new one calling your_site/workspaces/kmkey/cpsdocument_create?type_name=KMKey%20Pattern
9. You should specify the Related Portal Type created in step 3 and the Allowed Local Roles defined in step 7.
10. You should also define an Objects Creation XML, to say what objects will be created inside the new project, like tasks or subtasks. You can even use TAL to construct this XML. Here you have an example::
<?xml version="1.0" ?>
<objects xmlns:tal="http://xml.zope.org/namespaces/tal">
<default_portal_type tag="task" portal_type="KMKey Task" />
<task task_id="1" Title="1. First Task"
responsible="role:Editor"
planned_start="parent['planned_start']"
planned_end="parent['planned_start']+50" />
<task task_id="2" Title="2. Second Task"
responsible="role:Editor"
planned_start="parent['planned_start']+5"
planned_end="parent['planned_start']+120">
<task task_id="2.1" Title="2.1 First Sub Task"
responsible="role:Editor"
planned_start="root['planned_start']+5"
planned_end="root['planned_start']+40" />
<task task_id="2.3" Title="2.2 Second Sub Task"
responsible="role:Editor"
planned_start="parent['planned_start']+20"
planned_end="parent['planned_start']+50" />
</task>
<tal:block tal:repeat="i python:range(here['planned_start'] - DateTime())">
<task tal:attributes="Title python:'%i. Task %s' % (i+3, str(i+3));
task_id python:100+i"
responsible="user:scamps"
planned_start="2006/09/01"
planned_end="2006/09/15" />
</tal:block>
</objects>
11. You can also define documents to be generated in the project. The document template should be defined in OpenOffice format, and including XML for your ZOORRA Product (that will be described in next blog entries). The template could be everywhere inside the own KMKey application, and could be referenced by Title, by getDocId, or by any other catalog condition. Here there is an example that allows the generation of a document from any task, and a generation of another document just for tasks 2 and 3:
<?xml version="1.0" encoding="iso-8859-1" ?>
<objects xmlns:tal="http://xml.zope.org/namespaces/tal">
<document getDocid="1004828750" task_id="*" />
<document Title="simpleCase.sxw" task_id="2#@3" />
</objects>
12. And that's all by now. You should be able to create new projects from using your new KMKey Pattern calling your_site/workspaces/kmkey/patternBasedCreateForm.html?type_name=kmkey_yourpattern In future entries, we will explain how this could be linked from the menus engine or from an action in a tab.