There was a first version of mrp_subcontracting at rev [1] and now
there's a second verion at rev [2]. As the second version sensibly
changed the flows and models AND we don't have the time to backport the
changes AND saas-12.3 will be released on the saas, we chose to remove
the module in saas-12.3 to not have to support both version once v13 is
released.
[1] d91db5bde6
[2] 9b6a5398dfclosesodoo/odoo#35898
Signed-off-by: Christophe Simonis <chs@odoo.com>
In v10.0, it was possible, and kinda work, to have
```
<t t-name="kanban-tooltip">
<ul class="oe_kanban_tooltip">
<li><b>Project:</b> <field name="project_id"/></li>
</ul>
</t>
```
In v11.0 onwards, this "feature" has been dropped, since in kanban records
it doesn't make much sense to a field defined/displayed that way
The right way is to call
`record.(field).(raw_)?value`
This commit adapts the only two modules still having kanban-tooltip classes in their views
OPW 2055132
related to #29802closesodoo/odoo#35869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If an event track had a speaker assigned who had an email, and the
email field in the track itself was empty, Odoo was suggesting the
user to send an email to an empty recipient, making an error
Now it only suggests the email if there's one.
Fixesodoo/odoo#35941
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, the adaptation of Deferred to Promise was not well done
Hence, the change in video playing status was not handled correclty
i.e. When a video arrives to its end, the next slide or the questions should be displayed
After this commit, when a video is finished, the next slides is displayed
OPW 2052971
closesodoo/odoo#35863
Signed-off-by: Christophe Simonis <chs@odoo.com>
If you change the color of a link with the editor without using the link
edition menu, this do not work (which might be expected), but if the
text outside the font had been colorized, the font will be applied
outside of the link only.
This is unexpected since if we have: "hello <a>cruel</a> world!", if we
select only "cruel" and change color, the change only happen to "hello"
and "world!".
With this changeset, an anchor in the ancestor prevent to use an
ancestor font tag to change color (which prevent the issue).
opw-2044551
closes#35862
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Same cause, error, rationale and fix than 0ec0a4a32e
#OneCharacterPatch, reloaded
opw-2056251
closesodoo/odoo#35857
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
When you are adding a line on your sale order that is a delivery line,
the carrier is not always set on the sale order which means that when
the carrier is not explicitly set on the sale order, the carrier won't
be set on picking created from the sale order.
When you are using the wizard on sale order, it works, but when the
carrier is selected on the e-commerce, it is not set on the sale order.
To avoid such difference in behavior, we are writing the carrier_id of
sale order in the function 'set_delivery_line' insread of the wizard and
e-commerce.
closesodoo/odoo#35855
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Since commit e8916a817c, it was not possible anymore to go through the
ecommerce checkout when `website_sale_delivery` module was installed.
Indeed, it would raise a traceback on the confirmation step if more than one
delivery carrier would be available (different qweb if more than one carrier).
Thus, it would not be possible to click on pay now and buy the product.
This commit fixes it and improves the current test to ensure such flows are
working.
closesodoo/odoo#35577
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If partner.vat is an empty string, python evaluates it as falsy and doesn't check the remaining of the line. This makes the framework to send ["", ""] as values for the many2one to the browser instead of false.
By forcing to have True or False, this is not a problem anymore as bool() will be False, and False will result in the correct value in the read.
closesodoo/odoo#35807
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In case of large cart and promotion program with a discount reward
of percentage type, we are rewriting the reward order lines
multiple times while we can do all in one update.
opw-2038791
closesodoo/enterprise#5086
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
X-port/Cherry-pick of odoo/enterprise@243e66663a
Create two models, `object` and `category`. The object have a Many2One
to the category. Override the `search` on the category so it returns a
subset of the records if a context key is present. Create an IR Rule on
object with the following pseudo-domain: `categ_id in category.search([])`.
Search on object with the context key present. Even if the context
should only be applied to category, it is applied to object too thus
there are some object missing.
When evaluating the domain of IR Rules, the current user is propagated
with the current environment context. API calls triggered by the domain
are called with the given context, possibly populating the cache with
different records than it would normally does without the context (i.e.
at `addons/point_of_sale/models/account_journal.py#L19-L23`). Following
requests do use that invalid cache thus return invalid results.
Forcing an empty context on the user used during the evaluation of the
context ensures the IR Rules are working as they should and is
future-proof (cf `load_company` v13 context key)
opw-2041667
closes#35123closes#35125closesodoo/odoo#35667
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Hugo Adan <hugo@vauxoo.com>
Before this task,
There was no warning message when invoice date is set in
future.
task-2053068
closesodoo/odoo#35796
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Determine `model._rec_name` before the dependencies of the fields. The
compute method of the automatic field `display_name` uses a callable
depends that retrieves `model._rec_name`.
closesodoo/odoo#36476
Signed-off-by: Christophe Simonis <chs@odoo.com>
portal uses methods defined in auth_signup
without depending on it (probably counting on the autoinstall)
So before this commit, you could uninstall auth_signup
but every flow involving portal - making share urls - crashed
This commit adds the dependency
OPW 2064883
closesodoo/odoo#36477
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before that, there was no way of opening the product related to an invoice line once the invoice had been validated.
closesodoo/odoo#36336
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
1) Improve readability / performance of moves checks
The queries checking the move name & the duplicate vendor reference was complex
and unefficient for no reason.
2) Recompute amount_currency when reversing invoice
When reversing an invoice, the amount_currency wasn't recomputed even when dealing with
a refund date having another currency rate.
3) The refund must not keep the payment ref of the reverted invoice.
The payment ref is stored inside the receivable/payable line's name. However, when
duplicating the invoice to create a refund, this must be emptied until a new
payment ref will be set.
4) Reintroduce user_id field on account.move
The field user_id has been renamed to invoice_user_id. However, some mail templates
need to access the generic user_id field for multiple models.
5) Fix 'misc' Journal Entry totals
Misc journal entry must have an amount total always positive and not signed.
Furthermore, we don't know how to compute the amount_untaxed/amount_tax so don't
compute that with such entries.
6) Fix cancelling an exchange difference entry / tax cash basis entry.
When cancelling an exchange difference entry, the reconciliation is undo and then,
the exchange difference entry is reversed. Same for tax cash basis entries.
issue: https://github.com/odoo/odoo/issues/35841
7) Fix creation of cash basis entries for reversed journal entries.
When reconciling entries with one being the reverse of the another one, cash basis entries
for taxes must not be created. However, it must be the case when reconciling the reverse entry
(like refunds) with something.
issue: https://github.com/odoo/odoo/issues/35276
8) Fix matching rules ignoring the structured communication.
Since account-pocalypse, the structured communication is landing on the name of the
journal items. Then, the matching rules must consider it.
closesodoo/odoo#36062
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, a fixed tax amount was incorrect in invoices in a multi-currency
environment as the amount was applied both in company's currency and in foreign currency.
In this commit, the amount is converted when dealing with a foreign currency.
Before this commit, the tax computation was done in invoices using the balance of each base lines.
However, when dealing with python tax having sometimes an amount only dependent of the price_unit,
we need to handle the case when quantity is zero.
issue: https://github.com/odoo/odoo/issues/35358
Since the base in compute_all could be negative but is signed to perform the computation,
the price_unit should follow the same logic and be signed when evaluating a python tax.
Before this commit, the price_unit was equivalent to the base line balance and then, was negative
in case of a customer invoice.
E.g. For an out_invoice of 100, the price_unit is 100 but the balance is -100 for the base line.
Then, the computation is done using a base of 100 but having a sign of -1. However, when evaluating
a python tax dependent of the price_unit (here the balance), the price_unit was negative and then,
the tax amount will have a wrong sign at the end.
UTM fields are available in the invoice without sale_crm. That's why just apply
search_read on account.move instead of doing
--> search on sale order
--> map on invoice_ids which is computed
--> search_read on account.invoice.report
to get sale_invoiced_amount.
Currently, stat button 'Invoiced' is not redirecting to invoices tree
view because of wrong action and domain parameters. Thus we, set proper
action and pass valid parameter to get that invoices tree view.
Task 1919391
closesodoo/odoo#35296
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
It happens a lot that we access to the employee timezone to compute
presence states, leaves, ...
Instead of sudoing all those accesses, it looks better to expose this
data in the public profile.
closesodoo/odoo#35811
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When accessing a SO's tasks from Contacts (the partner_id's page), and
calling action_view_task, the active_id first corresponds to the contact's id.
Therefore, if a project.project exists with the contact's id, one can access
the SO's tasks, but otherwise, we get the error
Record does not exist or has been deleted.
(Records: [partner_id], User: ...)
Thus, if there is one corresponding project, we first update the context:
active_ids is set to project_id,
allowing access to the SO's corresponding project's tasks.
Note that the same thing is done lower:
eval_context.update({'active_id': task_projects.id})
which is too late to avoid trying to access the wrong record.
In the case where there are more than 1 corresponding projects (or if
there are no corresponding tasks), we don't have the issue.
OPW 2052559
closesodoo/odoo#35792
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In some cases, the first request of a test is made before the
proper setting of the cookie. In that case, Odoo picks a new session,
leaving the request unauthenticated.
closesodoo/odoo#35780
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
- Take a quizz survey, and fail it
- Go to Answers
- Print the Certification
Even if the quizz was failed, the certification can be printed.
There is no option to prevent printing a PDF, therefore we need to print
a different template.
opw-2049481
closesodoo/odoo#35769
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Christophe Simonis