The commercial_partner_id field on "account.invoice" is a stored related
field to commercial_partner_id on res.partner and this field is recomputed
when changing the is_company field (by the function _commercial_partner_store_triggers).
So when changing the "is_company" field, the commercial_partner_id is recomputed and
a write is made on each account.invoice linked to the commercial_partner_id.
To avoid access rights problem on account.invoice, the write on "is_company"
must be done in SUPERUSER.
opw:694687
Backport of ab279d9cea
When getting the price from a account.move.line, the uom set
on the line must be taken into account.
Before the fix:
-Set anglo-saxon accounting
-Create two units of measure Box and Mot where 1Mot = 10Box
-Create a stockable product with Box as unit of reference and set with
real price and perpetual
-Create a SO with a Mot of this product
-Confirm the SO and create the invoice
-Validate the invoice
Bug:
In the journal of entries, only one box was counted for the debit and the credit
instead of 10.
NB: The function _get_anglo_saxon_price_unit must return the price unit of the
product in the unit of measure of the account.invoice.line.
opw:693075
Rev. d6e1d41128 removed old API
compatibility layer, but failed to preserve the ability to
call certain public methods from the RPC layer, when extra
browse_record parameters were required.
In particular the @api.v7 version of
`prepare_move_lines_for_reconciliation_widget` was dropped
and there was no way to call it with a `target_currency` RPC
parameter anymore.
When processing a partial reconciliation in a foreign currency, a
currency exchange difference might be generated during the
reconciliation process (see OPW for a detailed use case).
This prevents the user to process the reconciliation since he will get
the error: 'You have to provide an account for the write off/exchange
difference entry.'
The fix is to use the company-related foreign echange gain and loss
accounts automatically to book this difference.
opw-687975
Call was done in ajax to speed up the moderation and don't wait refresh at each accpet/refuse post.
But the problem is that when you refuse a post, you need to be redirected to a new page to ask more
infos about the reason.
The fix is to do the request in ajax only when it is an 'accepted' post.
This commits fixes odoo/odoo@14462
When we enable in the settings 'Get 2 levels of approvals' with a
'Double validation amount', and then create a request for quotation.
When we confirm it, even if the total amount of the request for
quotation is below the amount set in the settings, the purchase order
needs to be approved.
We excpect that if a purchase order has a total amount below the
validation amount setting, the purchase order is automatically
confirmed.
So to fix it, we compare the amount when the user click on the button
confirm. And immediatly call the function 'button_approve' if the amount
is below the double validation amount set in settings.
Bug introduced in rev: https://github.com/odoo/odoo/commit/9d4efc81a
opw - 694381
I hereby confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr
(yes, github mutilates nicknames with underscores)
Closes#13875
When changing the company of a sales order,
the change was not propagated to the related, stored, company field
of its sale order lines
These triggers makes that happen.
opw-694683
When changing the company of a pricelist,
the change was not propagated to the related, stored, company fields
of the `product.pricelist.version` and the `product.pricelist.item`
These triggers makes that happen.
opw-694683
The module `payment_stripe` was apparently not designed to work with
module `website_payment`, althought the payment method is available. For
example:
- Go to '/my/home', select "Pay Now" on an invoice
- Try to pay with Stripe ==> nothing happens
This commit brings the necessary modifications to make it compatible
with `website_payment`. Moreover, it prevents the creation of 2
`payment.transactions`, which was not necessary.
opw-693421
During the conversion to the new api,
the method `product.uom`.`_compute_price` has had its signature
changed.
Formerly, it was:
`def _compute_price(self, cr, uid, from_uom_id, price, to_uom_id=False):`
Now, it is:
`def _compute_price(self, price, to_unit):`
Basically:
- the first argument `from_uom_id` is removed, and you now should
call this method from the model record directly
- the last argument is no longer a kwargs
Some calls to this method were still done the former way:
- Some have been added during forward ports
- Some are oversights when this method has been converted to the new api
This revision corrects the calls that were still done the former way
to the new way.
opw-694871
Before this commit, if the loadJS method was called two times with the
same url, the associated script was effectively put in the DOM only one
time. However, the second call returned deferred was immediatly
resolved while the script (added by the first call) might not be fully
loaded yet.
Now, calling loadJS for a same url multiple times will always return
the same deferred, resolved when the associated script is fully loaded.
This commit comments the code of the Animation class and allows
for lazy loading of resources before animations' start methods
are called.
This lazy loading can be performed in the willStart method (to use
the same way as in the Widget class).
This commits also removes the "stop" function of the module as it
was not really useful. It was used to restart the animations (by
immediatly calling start again after the stop call). Now the Animation
class contains a restart method and the module "start" function
automatically knows if it has to instanciate an animation or restart
an existing one.
Animation start should only be performed by instanciating an Animation
(thanks to new) or by calling the restart method, to insure the
willStart method is always called. Anyway, the best way to start
animations is to let the system handle them, using the "selector"
attributes in your Animation definitions as before.
See in-code comments for details.
When refunding a supplier invoice with tax cash basis and no cash flow,
a movement for the cash basis tax was created.
Only entries with cash flow must be created for cash basis taxes.
opw:693453
On a account journal, as no default value is set, the label appears in bold on the form, and the value is not displayed (because equal to False)
Add a default value 'no_feeds' on the selection field
We add the filter during the instantiation of the search view by the "Discuss" client action
because we can't access the partner_id in the xml filter definition.
children_quant_ids is a computed field that does a search based on current
record id. However this causes a traceback when creating a record as
there is no id. This commit fixes this issue.
Those fields were stored computed fields before. However store has been
removed while migrating to the new API. We need a search function if we
want to be able to search on those fields and to use domains.
Domains are necessary to take packages from the right source locations.
The computation is done by searching the packages with the
"location/owner/..." domain and by returning a parent-of domain
in order to include all parent packages too.
When uninstalling a module followers stay in the database because there is no
real link between ir.model and followers. Adding a m2o ensure followers are
correctly removed when uninstalling a module.
res_model fields is kept as a stored related field. This allows to keep
compatibility with almost all code using / searching on followers. Only
followers creation is changed a bit. As follower creation is done mainly
through a dedicated method few changes are required. Yey. Mat should be
happier now.
fix test
When on a page event for example, when the user choose "Edit menu",
a modal is first opened to ask which menu to edit (the top menu or
the event menu ?).
This feature was broken with a web_editor refactoring. Indeed, the
dialog was converted to use the standard dialog class but the
widget was still inserted in the DOM thanks to "appendTo" instead of
the modal built-in "open" method, preventing it to be properly opened.
* web_editor, website_portal_sale, website_project,
website_project_issue, website_project_issue_sheet
- Use bootstrap grid the right way (missing row)
- Use table-responsive for website portal tables
- Remove web_editor table layout style if inside a table-responsive
in mobile mode
Commit 0b87f76628 introduced in 9 some new
controllers in hr holidays. They are used to activate some workflow signals
through dedicated controllers.
However hr holidays workflow have been removed meanwhile at commit
6a8e4c6119. This commit fixes the forward-port
by correctling calling methods instead of trigerring workflow signals.
With a9bd9ab1 the access action was refined depending on the user.
But when sending a mail about a sale order, this lead to an issue since
a mail template is rendered with the current user and not the mail
recipients.
So in the case of a sale order, the recipient could not have a button
leading to /my/orders/{order_id} whilst he should have, because the
user used to render the mail was the sender (which was an employee and
not a share user).
This commit adds a context key "force_website" which force the action to
an available /my/orders even if the sender is not a share user.
opw-691040
Nicolas Martinelli