In this recipe, we chose to extend the behavior by calling the normal implementation and modifying the returned result afterward. It is also possible to perform some actions before calling the normal implementation, and of course, we can also do both.
However, what we saw in this recipe is that it is more difficult to change the behavior of the middle of a method. We had to refactor the code to extract an extension point to a separate method and override this new method in the extension module.
You may be tempted to completely rewrite a method. Always be very cautious when doing so; if you do not call the super() implementation of your method, you are breaking the extension mechanism and potentially breaking addons for which their extension of the same method will never be called.
Unless you are working in a controlled environment in which you know exactly which addons are installed and you've checked that you are not breaking them, avoid doing this. Also, if you have to, ensure that you document what you are doing in a very visible way.
Unless you are working in a controlled environment in which you know exactly which addons are installed and you've checked that you are not breaking them, avoid doing this. Also, if you have to, ensure that you document what you are doing in a very visible way.
What can you do before and after calling the original implementation of the method? There are lots of things, including (but not limited to) those listed:
- Modifying the arguments that are passed to the original implementation (before)
- Modifying the context that is passed to the original implementation (before)
- Modifying the result that is returned by the original implementation (after)
- Calling another method (before, after)
- Creating records (before, after)
- Raising a UserError to cancel the execution in forbidden cases (before, after)
- Splitting self in smaller recordsets, and calling the original implementation on each of the subsets in a different way (before)