Following our discuss about Supplier Price Request, we allow users to create products “on the fly” to ask price to suppliers and sending an offer to the prospect/customer. To prevent using incomplete (missing accounting data that the user doesn’t know) or erroneous products in the main functionalities such as sales or purchases, we define a rule to allow a specific group to update “salable” and “purchasable” fields on the product form, other people don’t have access to those fields.
We thought also to add another checkbox field like “unverified product” but in this case we had do update a lot of modules to take care of this field in the domain… If you have another proposal about this, feel free to suggest!
So, in the module sale_opportunity, products on the lines have a domain “salable = true” which is incompatible following our previous proposal (user create a product on the fly but can’t check salable or purchase because not allowed), so new products are not displayed in the lines (not valid following the domain).
I would remove the domain clause “salable = true” (i know it could be dangerous,…) but it’s for a customisation and only on the sale_opportunity module (anyway this domain is verified later when we try to create the sale). Is this code correct ?
@classmethod
def __setup__(cls):
super(SaleOpportunityLine, cls).__setup__()
clause = ('salable', '=', True)
if clause in cls.product.domain:
cls.product.domain.remove(clause)
I’m wondering if instead of removing a domain, it will not be better to improve the sale domain.
For me, the salable is to express that the company wants/is allowed to sale this product. But there is another common constraint which is the time. I think we could have a new module that adds time constraint on when a product can be sold.
Maybe a time constraint is needed. We didn’t think about that.
But in our case, i’m looking the best way to prevent using “draft products” in the purchase/sale workflow as we allow users to create any product on the fly to fill the opportunity lines.
Or, you consider this new field “time constraint” as a mandatory field for the sale process and only group admin is able to fill this field ? But what about the purchase ?
Each product involved in sale or purchase should be verified by a “product admin” and having the needed data (accounting data, …) and coherent data
I think we are missing a step in the product definition for sale which is probably best implemented with a date range. The access right for this field will be left to the implementer.
I found this module from Nan-Tic : https://bitbucket.org/nantic/trytond-product_validate/src/default/ and with the mixin it seems not so complex to implement. So it would be better than removing a domain clause.
Another question would be:
Once the checkbox “validated” is checked by a user in specific group, could we prevent other users to update or delete this “validated” product ? (something like when we uncheck the active field, most of the fields become readonly, or shoud i add a record rule on the model testing the “validated” field to block update and delete ?) Are there examples anywhere of this kind of restrictions based on a field ?
Thanks for help!
Following the discussion, you would apply this date range in sale but we would prevent also using “unverified” products in purchases too. Also this wouldn’t prevent users to update products with erroneous data (after product was used in a sale or a purchase)
No because making purchase of product that contains wrong data is not a problem because at the end the invoice is validated by the accountant and checked with the supplier invoice.
Only users with product administration right by default. But customization can divide even more the access to each field.