Training module

[yajo]

I'll write this bug in English to be able to refer to it from other OCA repos.

I already commented this elsewhere, but it's good for everyone to know that we are working in a training module adapted to Spanish' Fundación Tripartita. If anyone wants to help, just ask me.

It's pretty advanced already, but it's going to be a collection of many micromodules: some just for add fields to DB, others to adapt event.event to training, and others to adapt those to Spanish law.

We do not sell Odoo; we use it. This is a long-term project of my company and bosses agree in sharing most of our code under AGPL back to the community. With your help, we are developing very high quality modules and we are very thankful for that. We see no benefit on having our own forks of OCA repositories forever. However, please have in mind that honestly our priority number 1 is to make it work for us.

This will mean changing some structure to some OCA repositories, as many of you have seen in OCA/partner-contact#120 and other places.

This bug will be a good reference for all those efforts, and I think that if the everyone knows where are we heading, you will better understand the motivations after our contributions.

BTW, all our code can be found under the @GrupoEsoc team, and in https://github.com/grupoesoc/odoo-grupoesoc-addons you can already find some modules that we have and that we still did not have time to contribute back. It's not a repository intended to be used in production, and it does not have the quality standards of OCA repositores, but you can find there pretty helpful modules such as mail_forward, important_fields or our current standard training implementation.

You are being a very helpful community. Thanks for all your help!

[dreispt]

Thanks @yajo. IMO it would be better to "post" this issue on the https://github.com/OCA/hr project, since people there may not be following this repo and will not be aware of your message.

[yajo]

Well, training is intended for res.partner objects, which fall out of scope I think. But if you recommend in #175 that some fields go there, I'll tell them.

[pedrobaeza]

@yajo, although you use case is for convinience in res.partner, the rest of people wants this information at hr.employee level, so HR is the proper place. You should also consider the auto-creation of hr.employee from res.partner instead of making this kind of tricks.

[yajo]

You should also consider the auto-creation of hr.employee from res.partner instead of making this kind of tricks.

You assume then that every res.partner is an hr.employee, but that makes no sense at all. I don't need an employee for each partner in my database.

However, every hr.employee could be a res.partner (it is not by default, but it could make sense).

Then, to satisfy everyone, the fields should be in res.partner, and accessible from hr.employee, which should create a res.partner for each.

you use case is for convinience in res.partner, the rest of people wants this information at hr.employee level

That's why I can make the modules to store data in res.partner, and "the rest of the people" can make the ones that mirror it from hr.employee.

you use case

BTW, please rephrase that to "your use case and that of everyone who imparts trainings to clients and/or wants to automate communications with Fundación Tripartita". It seems like we are the only ones in the world interested in this functionality. If we are, please tell me to stop wasting time in trying to push modules that nobody needs.

[dreispt]

I agree that training participants should not be required to be Employees.
Now fields required for legal reporting on employees should be: 1) stored on the Employee; b) provided by a localization module extending the hr_training module.

[dreispt]

@yajo My advice it to try to split features in smaller modules. You can still create a "Fundación Tripartita" meta-module that installs everything at once, and people can pick the "bricks" they are interested in for their specific use case.

[yajo]

I agree that training participants should not be required to be Employees.
Now fields required for legal reporting on employees should be: 1) stored on the Employee;

Hmm the difficulty is that if a participant is not an employee I still need those fields, and if I put them in hr.employee I'd have to do as @pedrobaeza says and make all participants employees, but they are not.

I think it is better to discuss separately where to put the fields in #175, since there you can find exactly what fields are required.

b) provided by a localization module extending the hr_training module.

Where can I find that module?

My advice it to try to split features in smaller modules.

That was my goal since the begining 😉

[dreispt]

The hr_training would your core module for these features 😸

[yajo]

To which of OCA's repositories should go the PR for modules based on event?

[pedrobaeza]

I have requested a new project for that. I'm waiting for the answer.

[yajo]

Nice, thanks! 😉

[rafaelbn]

@yajo we have a similar situation with recruitment. Odoo has standard functionality for recruitment inside the company. But if you company business is recruitment you need to develop a vertical.

In this case we could have a standard functionality for Spanish localization because ALL Spanish companies are able to manage their European subsidy founds for training adapted to Spanish' Fundación Tripartita. But in this case this is developed because the business of the company is to manage this training for other companies (clients).

@dreispt said "split features in smaller modules" and this is understandable in a vertical project because all this small modules has relation with the project, so all of them are logic in this specific situation. But when you split this amount of modules so specific for this funcionality, in my opinion don't fit the agreement of general use.

@pedrobaeza said "I have requested a new project for that. I'm waiting for the answer", I'nm not sure if you are talking about this new project https://github.com/OCA/event because I don't think any of this can fit in event project.

This point is interesting:

@pedrobaeza "You should also consider the auto-creation of hr.employee from res.partner instead of making this kind of tricks."

@yajo "You assume then that every res.partner is an hr.employee, but that makes no sense at all. I don't need an employee for each partner in my database."

We are talking of personal data and professional data of employees of res,partner. Something like res.partner.employee. Because we talk about a vertical of a specific business.

[yajo]

In this case we could have a standard functionality for Spanish localization because ALL Spanish companies are able to manage their European subsidy founds for training adapted to Spanish' Fundación Tripartita. But in this case this is developed because the business of the company is to manage this training for other companies (clients).

You are right. However, if I focus in the standard case, I cannot cover mine at all. But if I focus in mine, it can cover the standard one. All you have to do is choose your own company as the client.

But when you split this amount of modules so specific for this funcionality, in my opinion don't fit the agreement of general use.

I can merge all fields in less modules, but have in mind that not splitting could lead to a future situation like what we had in base_contact (see OCA/partner-contact#119 and OCA/partner-contact#120).

It also seems more easy to maintain and test when modules are smaller.

Maybe the problem is that you see many little modules coming that many people don't need. Instead of PR each of them separately, I can finish all macromodules and make a PR of the full functionality (well, actually 3, one for each repo), including micro and macro modules in the same PR. Just to help you all see the big picture.

However, as I always say, I'll follow OCA's guidelines.

I'nm not sure if you are talking about this new project https://github.com/OCA/event because I don't think any of this can fit in event project.

Actually it fits, since the training module is just an extension to the event one. Nobody noticed me about it, thank you. I'll send the first macromodule there ASAP.

You should also consider the auto-creation of hr.employee from res.partner instead of making this kind of tricks.

Speaking of which, I never understood why hr.employee is not a submodel of res.partner. res.users is and it avoids many data duplication and these kind of problems.

[yajo]

After feedback, I'll close all single-field PR and merge into the macromodule.

[yajo]

I'll leave OCA/reporting-engine#21 and OCA/partner-contact#147 open since those seem more general-purpose.

[yajo]

Could you reopen this please? Seems that GitHub fixed it for me 😁

[rafaelbn]

Speaking of which, I never understood why hr.employee is not a submodel of res.partner. res.users is > and it avoids many data duplication and these kind of problems.

There are Employees that are not users
There are Users that are not employees

@yajo could you give us a general situation of the module with dependencies after re-structuring them?

Thanks

[yajo]

There are Employees that are not users
There are Users that are not employees

Of course, but I meant res.partner, not res.users. All employees should be contacts, the same way all users are contacts. They share many fields (if not all) from res.partner and add some others AFAIK.

@yajo could you give us a general situation of the module with dependencies after re-structuring them?

You can see the last 3 PR. They are micromodules too. I hope they are purpose-agnostic enough to be split.

I'll push the country-agnostic training vertical module to https://github.com/OCA/event/ when I see it's ready for prime time.

All modules that just add one field will end up mixed in l10n_es_training. I'm still thinking about what to do with #192 though. Right now I still have not had time to restructure it. As you can understand, it's more urgent for my boss to finish the job than to restructure it to make the same in less modules, so it will take a long time.

Also I'll be out for holidays some weeks, which will slow this a bit more.

Just be patient.

[pedrobaeza]

I close this as triage