Modules that add one field

[oca]

Modules that add one field

[dreispt]

As a general rule I agree that modules should not be trivial, and adding just one field should not be relevant enough to be worth an OCA module by itself.

[zaoral]

IMHO I think this is a really complicated issue. We should ensure modularity as much we can but we should also need to decrease the dependency complexity. As much ugly they can be one field modules need to exist. In the following l describe my reasons why.

There are times that we define one single module for only one field because maybe two very different modules like sale or stock will use it and inside this modules they adding an extra behavior for that field.

For example, Imagine one company that have sale modules installed but they do not manage stock, should they install an stock module only for be able to see that shared field? My answer is not.

I think this modules are required, but for solve the dependency complexity we could use a different approach: Delete this small modules (one field module) and add the functionality into a more generic bigger/complete module taking into account that this last module should have the option to activate/deactivate any of the functionalities that it have. This way the users will be able to have more simple dependency tree and will be able to select only the functionalities that they required.

This new approach it solves the dependency complexity issue in some way but will give us an extra complexity:

• Adding new functionalities will be harder task because will need to add the logic to activate or deactivate every functionality. However this is a drawback for development team but will be an
  advantage for the users because they will have control of all functionalities they want or not to have.
• Instance performance will decrease trying to know what functionalities will be use or not. Also database complexity will be increase giving us a larger new fields that if the user have not activate they will be dead data that will be never set or use.

[pedrobaeza]

@zaoral, for the case you mention, you only need to define the field twice, once on each module. When both are installed, the field overriding is made without problems.

My opinion about the one-field module is "depends". If the field is important enough (like the gender one in employees), and is added with the corresponding filters, group by and so on, it's justified then to add a module for this.

[dreispt]

@pedrobaeza True, but I believe that the wording should be "in general modules should not be trivial". There can be properly justified exceptions, but it us up to the proponent to make that explanation. Otherwise, if it is to just add fields, it would be best to add several in a single module, grouped by a them.

Adding just one field along with some logic and filters probably is a non trivial module. In fact most OCA/department modules probably are like this.

In the end, there could be a general indication about this in the guide lines, but the final word is on the PSC - if the PSC says that the module is not relevant enough, it shouldn't be merged.

[pedrobaeza]

@dreispt, good explanation. Can you please propose a modification in the guidelines with this?

@dreispt I agree with your explanation too. I will let this issue open until the guidelines are updated in case someone else would like to comment.

[dreispt]

OK, I think that shouldn't take much time to do that.

[dreispt]

I believe there is an pending action for me here, correct?