in our project there is one interesting requirement initiated by some project managers:
There is a synergy project named "documents" with the release docs/1.0.0. this project contains some papers, protocolls, records, concepts and other important documents. there are also some subprojects and subdirectories.
The requirement is: the subprojects need some new (mandatory!) attributes, e.g. "responsible team" or "responsible manager". Everytime a new (sub-)project for release docs/1.0.0 is created the creator needs to fill in the responsible team for that project. The value of the attribute can be any string and no plausibility checks are needed.
Is there any way to create new (mandatory) attributes for the object type "project"?
Maybe, create a new type "custom_project" or derive from the typedef "project" could help.
any ideas?
We are using Synergy 6.5 and 7.1 with the standard process rules and the parallel restriction: allow parallel checkout, disallow parallel checkin
Thanks in advance!!!
Knut
So it is good thing that we limit the alteration to only contain/address exactly those attributes that we need to touch. So far those has only been the ones that are expected to change anyway, like attr.info_attrs.text or attr.source_init.text - but that is just us, other customers might do otherwise...
A word of caution about exporting type definitions and importing them. You should never export any type definitions that are part of the [i]Synergy base model[/i] and import them into a database that is at a different release, iFix pack, or patch level. Such usage is invalid and can lead an erroneous base model. You have to be expecially careful with type definitions that model redefined methods or additional data (e.g. no_copy_on_derive or clear_on_derive) such as is the case for the project type.
It is safe to export user-created type definitions from one database to another, even if that database is at a different Synergy release.
David.
To further advance the discussion, this only makes sense in a prep project, as David points out: the developers rarely bothers with the attributes of their working projects. Furthermore, as the solution that I suggest is global, while your request seems to be release-based, it becomes even more complicated, as IBM recommends that users check out their working project once, and the alter the release as the go along with the evolution of the product. In your scenario there is nothing that enforces the users to alter the responsibility as part of that action.
What drives the responsibility that you want to document, the release or the project?
The more I think of it, it is not the kind of information, that I like a CM, would like to keep in Synergy, however convenient the managers might find it...
You can create mandatory attributes, but only the Synergy client will honor it, the Classic ignores the mandatory part.
The way we handle changes to built-in types is that we do:
ccm typedef -export {type} -ef CCM45SP2
The we remove all attribute files in the resulting {type} directoty, all but the cvtype/attr.info_attrs.text, which we edit with our local attributes.
In addition you need to create a new attribute on the project type as well:
required_attributes
where you list the name of the attribute to be manadatory.
In the end you should have two files (after having re-exported the type, or you can just create the file with a text-editor, but please note that you need to verify the filename for the required attributes, as I only made a guess there):
{type}/cvtype/attr.info_attrs.text
{type}/cvtype/attr.required_attributes.text
To deploy them across databases, launch a session with the role type_admin and import the type:
ccm typedef -import {type} -f
pointing to a path where you have stored the template from above.
You could also create a secondary type of the project as you suggest, it depends on the number of attributes tat you are going to work with. A variant type is recommended by IBM, as it will not be touched by an upgrade (as allow_update should be false), while having the project as supertype will allow it to inherit any changes IBM applies to the built-in type.
We have not opted for this solution, as users are already confused by the number of types... If there had been an option to "hide" types by making them inactive the option would be more attractive.
In either case you need to replicate the type definitions when DCM:ing as the target db might not have the new attributes to the type, regardless if you update the built-in type. or create an alternate type.
Hope this helps...
/PeL
Hi Knut,
The short answer is "no, not fully".
You can define custom attributes using [i]info_attrs[/i] on the project cvtype, and also list such attributes in the [i]required_attributes[/i] attribute on the project cvtype. I believe that there are support technotes covering this available from IBM Developer Works.
However, this cannot be used for enforcement. Firstly, in the Synergy GUI, the [i]Create Project[/i] dialog does not handle such custom attributes - you cannot add new attributes to that dialog. Secondly, the business logic checks for required attributes when the object is transitioned. For example, for a task, the required attributes are checked on task completion. For files, they will be checked on a transition from a non-static state to a static state. Since developers typically never checkin their projects, there will be nothing mandating that such data exists.
When you later open the properties dialog on the project, it will display the custom attribute and show it as mandatory. But there is nothing that forces the user into opening that dialog.
I think the best you might do is have a scheduled job run that queries for projects that should have the required data but do not, and then email the owner of such projects about the violation of your policy rules, then define the attributes as custom attributes so that GUI users can provide the information in the properties dialog for the project. You may want to think carefully about listing them in [i]required_attributes[/i] because that will apply to all projects in that database. You cannot apply a condition that it is required only if certain criteria are met.
Regards,
David.
Hi Knut,
The short answer is "no, not fully".
You can define custom attributes using [i]info_attrs[/i] on the project cvtype, and also list such attributes in the [i]required_attributes[/i] attribute on the project cvtype. I believe that there are support technotes covering this available from IBM Developer Works.
However, this cannot be used for enforcement. Firstly, in the Synergy GUI, the [i]Create Project[/i] dialog does not handle such custom attributes - you cannot add new attributes to that dialog. Secondly, the business logic checks for required attributes when the object is transitioned. For example, for a task, the required attributes are checked on task completion. For files, they will be checked on a transition from a non-static state to a static state. Since developers typically never checkin their projects, there will be nothing mandating that such data exists.
When you later open the properties dialog on the project, it will display the custom attribute and show it as mandatory. But there is nothing that forces the user into opening that dialog.
I think the best you might do is have a scheduled job run that queries for projects that should have the required data but do not, and then email the owner of such projects about the violation of your policy rules, then define the attributes as custom attributes so that GUI users can provide the information in the properties dialog for the project. You may want to think carefully about listing them in [i]required_attributes[/i] because that will apply to all projects in that database. You cannot apply a condition that it is required only if certain criteria are met.
Regards,
David.
You can create mandatory attributes, but only the Synergy client will honor it, the Classic ignores the mandatory part.
The way we handle changes to built-in types is that we do:
ccm typedef -export {type} -ef CCM45SP2
The we remove all attribute files in the resulting {type} directoty, all but the cvtype/attr.info_attrs.text, which we edit with our local attributes.
In addition you need to create a new attribute on the project type as well:
required_attributes
where you list the name of the attribute to be manadatory.
In the end you should have two files (after having re-exported the type, or you can just create the file with a text-editor, but please note that you need to verify the filename for the required attributes, as I only made a guess there):
{type}/cvtype/attr.info_attrs.text
{type}/cvtype/attr.required_attributes.text
To deploy them across databases, launch a session with the role type_admin and import the type:
ccm typedef -import {type} -f
pointing to a path where you have stored the template from above.
You could also create a secondary type of the project as you suggest, it depends on the number of attributes tat you are going to work with. A variant type is recommended by IBM, as it will not be touched by an upgrade (as allow_update should be false), while having the project as supertype will allow it to inherit any changes IBM applies to the built-in type.
We have not opted for this solution, as users are already confused by the number of types... If there had been an option to "hide" types by making them inactive the option would be more attractive.
In either case you need to replicate the type definitions when DCM:ing as the target db might not have the new attributes to the type, regardless if you update the built-in type. or create an alternate type.
Hope this helps...
/PeL
To further advance the discussion, this only makes sense in a prep project, as David points out: the developers rarely bothers with the attributes of their working projects. Furthermore, as the solution that I suggest is global, while your request seems to be release-based, it becomes even more complicated, as IBM recommends that users check out their working project once, and the alter the release as the go along with the evolution of the product. In your scenario there is nothing that enforces the users to alter the responsibility as part of that action.
What drives the responsibility that you want to document, the release or the project?
The more I think of it, it is not the kind of information, that I like a CM, would like to keep in Synergy, however convenient the managers might find it...
A word of caution about exporting type definitions and importing them. You should never export any type definitions that are part of the [i]Synergy base model[/i] and import them into a database that is at a different release, iFix pack, or patch level. Such usage is invalid and can lead an erroneous base model. You have to be expecially careful with type definitions that model redefined methods or additional data (e.g. no_copy_on_derive or clear_on_derive) such as is the case for the project type.
It is safe to export user-created type definitions from one database to another, even if that database is at a different Synergy release.
David.
So it is good thing that we limit the alteration to only contain/address exactly those attributes that we need to touch. So far those has only been the ones that are expected to change anyway, like attr.info_attrs.text or attr.source_init.text - but that is just us, other customers might do otherwise...