Step wrote, at 09/12/2008 09:30 AM:
>> Assuming that Module is a custom field, you could add some
>> code to the custom_fields_updated hook in the work flow to do this.
>
> I am not sure how I can do this.
>
> This term "Module" is quiet abstract. Do not take it literally.
> What ever the project is in Eventum, it can be a "server park", a building, a floor
> in the building, a department in a company, a wine cooler door, printer button panel etc.
> :)
>
> Project A
> module 1 - maintainer blah@...
> module 2 - maintainer ahh@...
> ...
> module .. - maintainer blah@...
>
> Project B
> module 1 - maintainer...
>
> Projects DO NOT share modules. One person can be responsible for multiple modules.
>
>
> Example: Project A is a toy that is made of 3 parts. Those parts are Red, Blue and
> Yellow.
>
> Project A has modules:
> Red
> Blue
> Yellow
>
> If a "Project A" client has a problem with "Yellow", she submits a bug by selecting
> module Yellow and describes the probel or idea or what ever.
>
> 5 moths later you like to know which is the most fracked up module?
> Take a look at the "Project A" in Eventum and generate the report where you group
> issues by module.
One approach: Create categories for the project that match your concept
of "Module". Use handleNewIssue() in the Workflow API to automatically
assign the issue based on category.
Another approach: If, for some reason, you are already using categories
for a different purpose, create a custom field and once again use
handleNewIssue() to automatically assign the issue based on the value of
the custom field.
I don't think handleCustomFieldsUpdated() is what you want here. It
looks like that kicks in when you add another option to a custom field.
You might be able to leverage it for some initialization purpose, but to
perform an action when creating a new issue, use handleNewIssue().
