Re: Feature request: "module" and module maintainer

[Jorey Bump]

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().