N°4032 - On UserRequest, service subcategory no more limited by request_type

[v-dumas]

Base information

Question	Answer
Related to a SourceForge thread / Another PR / Combodo ticket?
Type of change?	Bug fix / Enhancement / Translations

Symptom (bug) / Objective (enhancement)

Reproduction procedure (bug)

1. On iTop x.y.z
2. With PHP x.y.z
3. First go there
4. Then do that
5. ...
6. Finally, see that...

Cause (bug)

Proposed solution (bug and enhancement)

Checklist before requesting a review

• I have performed a self-review of my code
• I have tested all changes I made on an iTop instance
• I have added a unit test, otherwise I have explained why I couldn't
• Is the PR clear and detailed enough so anyone can understand digging in the code?

Checklist of things to do before PR is ready to merge

• ...
• ...
• ...

[Hipska]

Shouldn't the request_type field now be dependant from subcategory_id and made read-only?

[v-dumas]

Shouldn't the request_type field now be dependant from subcategory_id and made read-only?

For the dependency, it would make sense if it was recomputed it in the DB_EVENT_COMPUTE_VALUES, but as it is done on a DB_EVENT_BEFORE_WRITE, the dependency would have no effect. At the end the result, is the same, so it's good enough, I will tackle other topics.
For the read-only, I would have transformed it in ExternalField. The reason why it is not read-only is that out of the box, in the console, Service subcategory isn't mandatory and user may set the request_type without setting a Service. At least that's what I was told by those who have the most experience in iTop Datamodel Design back in year 2010 ;-)

[Hipska]

It would have been nicer indeed if it was implemented as DB_EVENT_COMPUTE_VALUES, the user could see the updated value when changing a service/sub.

Anyway, accepted as-is.

[rquetiez]

As soon as this changes, I would like it to be fully aligned with the recommendation => event based.
Two handlers could be called : EvtComputePriority and EvtComputeRequestType.