[8.0][lettermgmt] Module simplification

[oca]

[8.0][lettermgmt] Module simplification

[max3903]

@bwrsandman worked on it for a large organization with a internal courrier service in charge of receiving and shipping letters and parcels internally and externally.

Workflow

You can have people creating the letter and people verifying that the information entered in the system is the one on the letters/parcels.

Fields

parent: You can have one incoming shipment spread out among many letters/boxes.

This is as much as I can remember about it. Maybe @plamarche have more information.

[ivantodorovich]

Thanks for the clarification! 👍

I'll wait for the others' response

[hbrunn]

I just ported what existed, and actually wrote a module that dumbs this down be removing all fields you ask about save for class, channel and type. About those, have a look at the demo data in https://github.com/OCA/crm/blob/8.0/lettermgmt/data/letter_demo.xml to confirm you're mostly right about their use.

[ivantodorovich]

Thank you @hbrunn !

That module you wrote, the one that dumbs this down, is it public?

I'd like to hear your thought and @bwrsandman's about splitting this module in a few: a simplified base + specific extensions. I'll gladly make that PR, but only with your approval.

[hbrunn]

the dumbing down module is not public, but only for the reason I figured it's not interesting for anyone. Your proposal sounds a lot better to me. @bwrsandman doesn't work on Odoo any more to my knowledge, so I'm not sure he's interested in being involved here

[hbrunn]

maybe for compatibility keep lettermgmt depending on letter_management, letter_managemet_channel, letter_management_etc?

[ivantodorovich]

That sounds good to me.
Although I have to ask, is it a standard practice in these cases?
For how long should lettermgmt be supported?

[max3903]

@ivantodorovich It will be supported as long as there are people to support it for users who uses it.

[ivantodorovich]

@max3903 I don't think we are talking about the same thing. I meant that question in response to @hbrunn's idea.

[ivantodorovich]

Ok, so.. to sketch resulting modules:

• letter_management: The base module. As simple as possible. I'm thinking on supporting current 'classes' (Personal, Confidential, Classified) as 'tags' instead.
• letter_management_channel: Add support for letter channels (Post, FedEx, UPS)
• letter_management_type: Add support for letter types (Envelope, Parcel)
• letter_management_folder: Add support for letter folders (Still don't know use case)
• letter_management_shipment: Add support for letter parent / childs.
• letter_management_validation_workflow: Add support for validation workflow

What about reassigment_ids? I don't understand the usecase yet.

[ivantodorovich]

Maybe channel, type and folder can be unified in a single letter_management_extended module..

[hbrunn]

it's quite usual to do this when you do refactorings in a branch where the module potentially already is installed in the wild. If you plan to do the refactoring during your port to 9.0, we don't need it. An example is base_contact which we split up in 8.0 I think: https://github.com/OCA/partner-contact/tree/8.0/base_contact

There you also find examples for moving xmlids to the new modules which will be pulled as dependency in the migration script. In a nutshell: For existing modules, the change needs to be done in a way that pulling the new code and --update=all is enough for people with the original module from the branch installed.

[hbrunn]

or what comes to my mind only now: How about attaching the fields in question to groups and make a configuration page that allows users to turn on the fields? Then only the workflow would need its own module, the rest would live in the main module and being turned off by default.

[ivantodorovich]

I understand.

Using groups would work for the extended fields and shipments, indeed.
I don't have much experience developing for the OCA, so I'll go whatever way you want!
Do do you think it's better to handle it using groups?

EDIT: Based on what they did on base_contact, it seems the way to go is having separate modules for the fields. (ie: partner_contact_birthdate, partner_contact_in_several_companies, partner_contact_nationality).
Don't you think?

[hbrunn]

in the case of base_contact, I think it's a good thing to have separate modules because those fields have nothing in common at all. Here, we need the base module anyways because it's a dependency for all the +1field modules, and given the amount of fields, we'd have quite a proliferation of modules, which is why I think the groups are a better choice

[ivantodorovich]

After thinking it a bit more, I'm more inclined to this idea:

• Use group for reassignments
• Use group for parent_id, child_ids
• Use module for letter_management_validation_workflow

And for the rest of the fields, I'll just rearrange the view and move them into an "Other information" tab. leaving only the most common fields at the top of the form.

[pedrobaeza]

Closing as there's a PR now