-
-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[16.0][ADD] product_usability #1657
Conversation
db95ac0
to
6ea1eea
Compare
e1eaa6d
to
dab31c5
Compare
4948596
to
9fdb8f9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this module.
I think the name does not tell us that much about the subjet. May be something like product_menu or product_app .
It looks a lot like this module : https://github.com/OCA/odoo-pim/tree/14.0/pim
yes product_app could be nice, thanks |
Eventually the pim module could start depending on this new module if it makes things simpler and more integrated... I could also be named product_management. Not sure which is the best. "catalog" could also be used. |
After Contacts app, Catalog sounds nice |
Hi. Thanks for your review and answer. About the name, the rational are the following : So If we name the module "product_app" or "product_menu", and if version 18 (or +) introduces an entry menu, the name will not be OK, but the module still is needed, because access rights are not present or other things. So i prefer that generic name, as it will become more resistant over time. Note : Note 2: About
So, i propose to maintain this one, and deprecate Thanks ! |
For me, |
@legalsylvain |
Hi. Here is my rational behind the choice of "usability". In the history of OCA modules: "usability"Looks to be used to improve Odoo Core module / Odoo Core features. (account / product_packaging / etc...) without adding changes in database layout : for exemple "management"looks to be used to add new features (or to implement features in another way than Odoo does it, for exemple, for assets). fieldservice_change_management, account_asset_management, mrp_subcontracting_partner_management all adds a lot of new fields and new features. Could we keep the same logic for this module, or could you explain alternative logic ? Thanks for your remarks ! |
Management is management. To manage something. In this case, to manage products. No matter if you need to add 3 views, 4 actions or whatever. Usability is to improve that specific part of something. Going to that subjective way, every OCA module improves the usability of something. I still vote for |
Thanks for your reponse Pedro. I'm not sure to understand. Do you mean all the existing "usability" OCA modules should be renamed into "management" ? What I really don't understand is that the current proposed module "product_usability" does exactly the same things as the accepted module "account_usability", so I don't understand why to change product_usability and not account_usability. Thanks for your precision. |
Each case is different, and I wasn't there when that modules were decided to have that names. Now I'm on this one, and as said, for this one, I think the valid name is |
Not sure to understand, Do you mean account_usability is bad named ? and should be renamed ? |
Arf https://medium.com/the-product-marketer/the-art-of-feature-naming-four-survival-tips-76bd86f82cff
The problem with Using |
I haven't analyzed it, but in that case, being a gathering of a lot of little "improvements", can be a valid name. In this case, you are only enabling to manage the products. And that's why I insist with |
mimick odoo bad choices is a bad idea IMO
|
Then @pedrobaeza think product_usability is a good name ? Nice |
Not always. Indeed, Odoo has taken some bad decisions in the past, but there's also some things that you shouldn't do the contrary for consistency. Example: naming m2o with I think something similar happens here, calling |
You're right not always |
No, I still think |
It's a matter of taste |
whatever we need to merge it |
Whatever, this page should inspire OCA for the future I think |
Well, this is not exactly a feature naming, but a module technical name. It follows another rules. Mine are:
|
We are ok. |
That's why I insist in the generic name |
product_manager 😁 |
My little suggestion: |
@youring good catch It's a shortname, then easy to use in a message commit like or for an extended module compared to |
hi. sorry but I don't see it is fair to block a PR, just for a matter of taste. When we receive PR, reviewers should follow the existing OCA rules and convention. It is not the place to introduce new rules.
Then, if clarrification is required please make PR upstream, on OCA convention repo, to specify what mean the following suffix Side remark : @bealdav : I don't know if it is written somewhere, but AFAIU, "_oca" is about OCA modules forking EE / CE features, and introducing possible incompatility with the official modules. Ex : l10n_fr_oca from akretion, spreadsheet_oca, web_pwa_oca Thanks ! |
No objection to stay with current name in this version whatever the name in future version Thanks @legalsylvain to clarified the situation allowing to merge this module. cc @pedrobaeza |
Hi @legalsylvain FYI, just found in 18.0 there is a group called "Product Creation" id=group_product_manager, should we be consistent with it from now on? |
@youring : I don't understand what you propose. could you elaborate ? |
@legalsylvain I mean when upgrading |
9fdb8f9
to
7ca4c4a
Compare
OK I get it ! Thanks for your message. (sorry, I was pretty lost, I made this PR 5 monthes ago). Well, for the time being (v16.0), the design is OK. Nothing to do IMO. I just added a ROADMAP.rst file, to mention what you say. See : 7ca4c4a For the V18 migration, we will :
Do you think it's OK ? Note : I tried to directly use the futur xml_id in the current module.
but I have an exception. I think such check is recent. Before, I think it was allowed.
|
OK, clear enough.
Coz the group does not exist in 16.0 or 17.0 CE |
…or models present in 'product' module. (product.product, product.category, etc...)
7ca4c4a
to
40f6965
Compare
/ocabot merge nobump |
Hey, thanks for contributing! Proceeding to merge this for you. |
Congratulations, your PR was merged at f8393c2. Thanks a lot for contributing to OCA. ❤️ |
Description
This module extends the Odoo CE product module to improve usability.
New Menu items
By default, when installing
product
module, a lot of menu items are not created and are available only if other module are installed.For exemple:
stock
module, that create the menu entry "Inventory / Configuration / Product / Product Categories".sale_management
module, that create the menu entry "Sale / Configuration / Products / Tags".This module so create a new main menu item named 'Product' that provides all menu entries to see and manage product, attributes, pricelist, Unit of Measure, etc. So that all the product configuration is available in a unique place.
New Access Rights
By default, to create product, attributes, pricelist, categories, User should be member of a group that adds a lot of rights, like 'Inventory / Manager' or 'Sale / Manager'.
This module adds new Access rules to fine-tune access rights, creating the following rules:
"Product Creation": Allow to create Products (
product.template
), Variants (product.product
), Product Template Attribute Lines (product.template.attribute.line
) and Product Template Attribute Values(
product.template.attribute.value
)"Product Attribute Creation": Allow to create Attributes (
product.attribute
) and Values (product.attribute.value
)."Product Tag Creation": Allow to create Tags (
product.tag
)"Product Category Creation": Allow to create Categories (
product.category
)"Unit of Measure Creation": Allow to create Unit of Measures (
uom.uom
) and Unit of Measures Categories (uom.category
)