remove addons depending on aeroo reports

[gurneyalex]

The following addons depend on aeroo report:

• hr_payroll_register_report
• hr_report_manpower
• hr_report_payroll_attendance_summary
• hr_report_payroll_net
• hr_report_turnover

Aeroo reports is not an OCA module and the OCA policy is to not depend on 3rd party modules.

In the discussion on OCA/reporting-engine/issues/1, the main author of aeroo reports strongly objected to the inclusion of his work in OCA. Since he also did not sign the CLA, I don't see how we could forcefully include his code in our code base. I therefore ask for the removal of the modules above.

If someone cares for these, it would be great if they could be cleanly moved elsewhere, and we will gladly provide a link in the README.md file pointing to that repository. If noone cares, I shall remove the modules from the git repository in a few weeks.

[lepistone]

I respect @sraps's wish to keep aeroo in his personal repository and not within OCA, and I would not duplicate it for inclusion (even if we had a CLA, which we don't).

👍 on the removal of depending modules then.

[dreispt]

👍 but we need a new home for them. Any volunteers?

[bwrsandman]

We could code sprint the rewriting of the reports in another engine. I would be in. 👍

[dreispt]

@bwrsandman that should be QWeb reports.

[rvalyi]

just as a note: I'm not sure going invented QWeb TM is any more sustainable than relying on Aeroo. As for myself I think that if reports are a bit complex, having them in another non core OCA repo (it can work just like an OCA repo it would just miss the "label") is more sustainable than doing QWeb rewrite, but that's just my opinion. Now if these reports are broken already (I don't know) then it's another story.

[gurneyalex]

For the record, I have no issue against these reports as they stand. It's just that they are not compliant with our policy, and I welcome any initiative to move them out of OCA instead of plain removal. I won't do it because I'm not using aeroo in my day to day work, and the tone of the current aeroo maintainer does not make me look forward to supporting users of this module.

The suppression PR is ready. Review and merge when you feel it's time.

[sraps]

"the tone of the current aeroo maintainer does not make me look forward to supporting users of this module"
@gurneyalex

I see that there are some pressure applied to those not agreeing with current state of OCA and the Odoo iself. Something like "give up for good", read all the communication from people mostly never interested in Aeroo. You may like it or not, but I am interested in people using Aeroo, and those who do use Aeroo, strongly knows why.

BTW I am closely watching OCA activities, and I was one of the initiators of OCA formation. Unfortunately, OCA have formed into something else, not that I was (am) seeking for, so sorry - at the moment I am not interested.

If you want to remove something out of OCA repositories out of policy or political reasons, feel free to do so.

P.S. And, please, do not apply pressure, it just incurs a defence reaction. Not all people think the same, it does not mean they are wrong. ;)

[dreispt]

@rvalyi I believe that no OCA repo should depend on a specific report engine (other than the provided by the core). This allows each one to be free to pick their favorite engine: Aeroo, Webit, whatever.
So, IMO it makes sense to remove the dependencies, even if Aeroo were an OCA project.

Having said that, I see no conflict in having an aeroo_hr, or maybe a global aeroo_reports repo in OCA. Or maybe @sraps would like to host these repos alongside Aeroo itself - there could be benefits on that.

[sraps]

My stance is, I would like to see generic Aeroo related modules alongside Aeroo itself, whilst reports should be hosted along the "vertical" module. For example along hr thematic. This would make sense to the user and professional on the subject.

[dreispt]

@sraps OK.
Anyone else thinks that a aeroo_hr or aeroo_reports OCA repo makes sense?

[StefanRijnhart]

@dreispt Well, not an OCA repo but maybe put them in an unbranded repo for these purposes. I would not mind being in the maintenance team of such a repo as I like to use Aeroo myself.