The name must be changed when changing of product,
but not for other changes, quantity for instance.
The 'or not uom_id' is just for retro-compatibility concerns
uom_id being False actually means we just changed of product,
and the name must therefore be changed
name as been set as False in the onchange call in the view
for the product_id field, in this rev.,
so the name being False now means th change of product
Nevertheless, existing databases for which the view
is not up to date won't have this change
and we therefore have to rely on something else to know
when the product has been changed or not.
fixes#5295
opw-628138
The seller_id field is a related that is read administrator so it would fetch
the first line, whatever the company specified.
Setting related_sudo=False would not be enough as creating purchase orders
through the scheduler makes the computation done as administrator.
Use the company of the procurement (required) to search for a supplier.
If no result, fallback on the first one as before.
Fixes#3833, opw 618809
- account: placeholder on invoice form
- sale: do not display "Default Options" menu if no option is available (added
by submodules).
- product: remove unnecessary section for uom
- placeholders Terms and conditions more helpful for configuration
- unify some partner title to avoid getting duplicates
This rev. is related to 8381d47543
The action action_purchase_line_product_tree is used in both
product templates and product variants forms.
Therefore, the default_product_id: active_id in the context
cannot be used,
As sometimes it will active_id will be a product template,
sometimes it will be a product variant.
I believe two different window actions should be used,
instead of sharing a common one and making hacks.
Nevertheless, as we avoid taking risks in stable releases
This should be done in master.
The purchases button on product templates open the purchase orders
that have at least one of the variants of the templates
Set in the context of the action button action_purchase_line_product_tree
'search_default_product_id': active_id, 'default_product_id': active_id
as no point, as default_product_id expects a variant id (product.product)
while active_id is a template id (product.template).
opw-626521
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Add a flag to replace or not the previous product description.
Apply the same logic than in sale. Change the description field on a purchase
line only when the product is changed. opw 620093
Clean the views and replace wrong parameter in warning
Do not write on the function field when you are writing on the function field.
- Now you do know what orders is right?
- I think I know...
- Orders is orders.
- I guess no one ever taught you not to use the word you're defining in the definition.
~~Lucky Number Slevin
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
1. The merge of the "email_template" module into the "mail" module.
2. The send action of the mass mailing has been moved from the frontend to a cron, because it was too slow to send over 10,000 mails (the user's browser was blocked for 15 - 20 minutes). Mass mailings have now their own process in the kanban view.
3. Mails sent from the mail form are sent immediatly instead of from the mail queue (for instance, when you go to sales > customers > list view > select 2 -3 customers > More > Partner Mass Mailing).
4. Users have now the choice from which mailing list they want to unsubscribe when they click on the unsubscribe link at the bottom of the mail.
5. Mass mailings inherit from their campaign UTMs and mass mailing campaigns are linked to an UTM campaign.
6. Many little improvements
When invoicing from dropshipping picking, choose the correct partner.
Also, change the partner on the picking to be the partner of the purchase.
Change the picking report to include the destination partner or the warehouse address on the right.
[IMP] Only put partner_id on move from purchase when really necessary
[FIX] Default value of partner on stock move should be False
[FIX] Message_post happens one by one and add test for next delivery date
[IMP] Add float_compare in orderpoint confirm
[FIX] Typo
[FIX] Use next_by_code instead of deprecated get
Update views for date_to on calendars
[IMP] Will add a date_to in the calendar attendance and date_from and date_to should be applied/ check backwards also
[IMP] get_attendance_for_weekday will pass date instead of weekday
[IMP] should assign correct procurements in run
Martin Trigaux