Removes the route slides/channel/enroll, (slides_channel_join_http method).
The attendees are enrolled in front-end through slides/channel/join,
used in different places through the Join channel button and javascript.
The old route is not used anymore.
Task-2508019
COM PR - odoo/odoo#70291
"ValueError: External ID not found in the system: payment.payment_provider_
stripe" is generated because the user deleted the Stripe payment provider
record and its corresponding model tried to access the record of it.
Steps to produce the error:(in >=16.0)
1. Install e-commerce
2. Install 'Payment Provider: Stripe'
3. delete the Stripe from payment Provider
4. Go to the website > Reporting > e-commerce
5. Click Activate Stripe on eCommerce Dashboard
This commit solves the above issue by preventing the deletion
of the payment provider if it has a external reference.
sentry-4041178833
closesodoo/odoo#120534
X-original-commit: 7082ce2460494891e8e063c11678226b164f99e7
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
By this commit, If a user edits the message body or changes
the message attachments, the edited label in the blob,
shows the last edit Info.
Task-2664848
closesodoo/odoo#117896
Related: odoo/enterprise#40208
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
What are the steps to reproduce your issue?
- Create a product with more than one attribute.
- Let say color White, black and purple
- Create a 'draft' invoice for the purple product variant
- Remove the 'purple' attribute value from the product
- It will archive that variant (because the account.move linked to it)
- Try to delete the attribute value from menu Sales > Cofinfiguration > Attribute
What is the current behavior that you observe?
- technical error message
What would be your expected behavior in this case?
- non-technical message for end-users
Solution :
- Change both message to tell user he cannot delete the value if the value has been referenced somewhere else.
opw-2623583
missing forward-port of db1e52f0234f73e1bda22a411baba7b1f0994d5a
closesodoo/odoo#120495
X-original-commit: 0c8c43d50a574d73d9d5ac925eb16faf730a76ba
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
The edi attachment (for every format in `account_edi_ubl_cii`) contains
a tag indicating whether the invoice is fully/partially paid.
Before this fix, when this tag was filled, a down payment section was
created on the invoice. For a fully paid invoice, the resulting amount
was then 0, so the invoice was marked as "Paid".
This was wrong. The correct amounts need to be kept on the invoices.
This fix no longer creates a down payment, instead a message is logged
in the chatter.
task-3264843
opw-3248200
closesodoo/odoo#120485
X-original-commit: 47333b5b13823ac2812a120f2cb443cb68d7d92c
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Steps to reproduce:
- install website_sale and website_sale_loyalty;
- activate Payment Providers Demo and Wire Transfer;
- put them in 'test mode';
- go to ecommerce;
- add a gift card;
- process the checkout.
Issue:
Depending on the configuration of the payment acquirer used,
sometimes the amount displayed is doubled
(in the display of the gift card amount
after the payment process in brackets).
- Demo in test mode: amount will be doubled
- Wire Transfer in test mode: amount will not be doubled
Remark:
The amounts are correct in the backend.
Cause:
Sometimes the `action_confirm` function is used and sometimes it is not.
When you enter it, the points of the coupon are already set.
Therefore, we add the amount again in the `_get_real_points_for_coupon`.
Solution:
Display the information of the gift card only
when the sale order is validated.
Therefore, there is no need to bypass (with `post_confirm`)
to add the points that will be valid when the sale order is confirmed.
Because with the display correction, we won't see the points.
opw-3166164
closesodoo/odoo#120227
X-original-commit: b3322ecc020e027c1b71ec3a222b8c2e5d0ee97e
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
The refactor of the kanban quick create implemented in
https://github.com/odoo/odoo/pull/117449 introduced a traceback when
creating a task from the My Tasks kanban view due to the presence of
'default_personal_stage_type_ids' key in the context.
This commit fix that by removing this key from the context in the
customization of the kanban view for project.task model. It also add a
js tour test to ensure that personal tasks can be created from the quick
create form in the My Tasks kanban view.
Steps
=====
- Install module project
- Go to the view "Tasks -> My Tasks"
- In the main Kanban View click on "New"
- Enter a Task title and clicl on "ADD"
Issue
=====
A traceback appears indicating that the value of the field user_id is
missing for the model project.task.stage.personal and the task is not
created.
Cause
=====
In kanban and list views, when the records a grouped by a given field, a
key is added in the context when creating a record from one of the
resulting categories. This key is of the form:
`default_fieldGroupedBy: current_category_value`
In the case of the view My Tasks, the records are grouped by their
fields personal_stage_type_ids (M2M). Therefore, the key
default_personal_stage_type_ids will results in a write in that M2M
table when creating the record. But the way personal stages are managed
in project is as confusing as it is mindblowing and the M2M table
storing the relation between task and personal stages is also the table
that store records from the model project.task.stage.personal. And this
model also as a field user_id that is required. Therefore
at creation of the project.task record with that key, the orm will miss
a user_id for the newly created project.task.stage.personal.
Fix
===
The correct way to add/modify a record project.task by setting its
personal stage is actually to use the already existing methods of
project.task, i.e. _inverse_personal_stage_type_id. Therfore, instead of
modifying directly the M2M relation, update the computed M2O field and
let the inverse method to the job of personal stage assignment.
To do that, the value contained in the context for the M2M relation is
copied in the write value of the M2O (personal_stage_type_id) and the
key in the context corresponding to the M2M relation is deleted.
task-3281005
closesodoo/odoo#119055
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In the website menu editor and in the studio menu editor, the user can
drag & drop the elements that constitute the menu of his website/app.
Users can also put a menu into another menu to create a sub-menu. For
the website, we allow two levels of menu but not more. For studio we
allow 5 levels of menu. When the user starts to drag an item, dropzones
can be drawn on the prohibited level (3 in website, 6 in studio) while
he can't create this level of menu. This commit adds a css rule to hide
those forbidden dropzones.
task-3251032
closesodoo/odoo#120497
X-original-commit: dac80feb84d213e5e0a1aa140fa019944ea4e826
Signed-off-by: loco-odoo <loco@odoo.com>
Before some translations didn't work in the point_of_sale because in owl
you can't use t-set to manage translations. In cashMovePopup, _t was
used at a time when loading translations is not yet guaranteed.
Now we have changed _t to _lt to ensure that the translation is done
correctly. For the t-set, we have added the translations in static
properties of the concerned components.
closesodoo/odoo#120403
X-original-commit: b2b9f760844304858aa64c51e7bda87190b11386
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, when posting a new message in a channel in the
discuss app, a chat window of this channel was automatically open.
This happens because new message from self where considered
new messages in a channel, and all new messages in a channel
were automatically opening a chat window.
This commit fixes the issue by not making self-authored messages
automatically open the chat window.
closesodoo/odoo#120478
Signed-off-by: Debondt Didier (did) <did@odoo.com>
Current behavior:
An accrual uses all planned leaves to calculate how many days it can
give, even if the leaves are planned in the future and could be
cancelled.
Desired behavior:
An accrual should only take into account leaves that have already been
taken or already started, and ignore future leaves.
After this commit:
New context key 'ignore_future' for method _get_employees_days_per_allocation
decides if future leaves should be taken into account or not. Some
use cases need to take into account future leaves, others don't.
task 3207843
closesodoo/odoo#120456
X-original-commit: d917a406fc7933af852ad5338533b93fc3fd2218
Related: odoo/enterprise#40678
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Remove lunch hours from work intervals so that overtime is not calculated when it's not due
tests adapted to take into account lunch period
task 3217799
closesodoo/odoo#120455
X-original-commit: 97c052432a25a1461de23fd8ab0c73ffe9b084ff
Related: odoo/enterprise#40677
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Install `E-learning` module
- Create a user X with only "Officer" as rights for `E-learning`
- Login with user X
- Go to `E-learning` and open any course
- Ensure that the user X is not the responsible and that the course
enroll policy is set to "On invitation"
- Invite any user not already a member
Issue:
No user was invited (not added as member) and no warning message
raised.
Cause:
Due to the ir.rule "Channel: officer: create/write own only", the
`Officer` user can only edit (and therefore invite members) on
courses where he is responsible.
Solution:
Add a param `raise_on_access` (set to False by default) to the
`_action_add_members` & `_filter_add_members` methods.
In the wizard, call the `_action_add_members` method with the
`raise_on_access` param set to True so that the error is only raised
in this flow.
opw-3133733
closesodoo/odoo#120114
X-original-commit: 515912108aef86376349df5eee51b4a5d664d2a4
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
# Steps to reproduce
* create two 17% sales taxes. We'll call those taxes `17a` and `17b`.
* set rounding method to global
* create a SO with the following 2 lines:
* Price = `50.4`, Taxes = `17a`
* Price = `47.208`, Taxes = `17b`
* note that the total tax amount on the SO is `16.59`
* confirm and invoice the SO.
You should see that the total tax amount on the invoice is `16.60`. The
invoice and SO should have the same tax amount.
opw-3179228
closesodoo/odoo#120224
X-original-commit: 715d0e269c3d42a5e25f8ddf648d275069354aaa
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
Co-authored-by: Yolann Sabaux <yosa@odoo.com>
Until 15.0, to show the behaviour of the QR billing in Switzerland, you had to manually configure a bank account for CH company and create a QR Bill compliant customer before creating an invoice, which was time consuming in the contaxt of a demo.
Updated the demo company's bank account and added an adequate customer to ease the process.
task-3264826
closesodoo/odoo#120349
X-original-commit: 69aab9f4db89f8bf3ba8f29a96fbf9eabd4bac4a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Because we are flushing, and because the business code might be flushing
elsewhere (i.e. to validate constraints), the fields depending on the
sequence field might be protected by the ORM. This is not desired, so we
already reset them here.
The symptoms were that sometimes the related field `move_name` on
`account.move.line` would stay at `/` even after the new `name` was
given.
closesodoo/odoo#120488
X-original-commit: e7db87db57e4f98719602502d80948a5ed51adc2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
How to reproduce:
- Activate l10n_be and go on a Belgian Company
- Activate Quick Encoding on Bills
- Setup account 600000 with taxes 12% (Sales) and 12% M (Purchase)
- Create a Bill
- Put 112 as the amount Tax Incl.
=> Both taxes are put on the line, which makes no sense, resulting
a sale tax on a purchase document.
It was forgotten in https://github.com/odoo/odoo/commit/85d89a986b6adcf9d0ac0ce57599d4b2678b59a3closesodoo/odoo#120486
X-original-commit: 04287db0045eefed1b03e04d745874caf206731f
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit addresses an issue with the checkout form displayed on the
portal page of the Subscriptions app: when only one payment provider was
available for checkout, and it required an inline form to be displayed,
the latter would not be shown, and customers were able to hit the "Pay"
button, resulting in a client error. The problem was that Subscriptions
now simultaneously displays two payment forms on the same page, one for
checkout and one for managing payment methods, which was not supported
by the payment engine.
closesodoo/odoo#120482
X-original-commit: 91d701e34a25d2ceada1679f36a9cdbb96c6c019
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the issue:
1. Project> select Project > Task> List view
2. Studio list view > Add existing properties field
3. Go back to list view > Favorites > add to spreadsheet
4. New Spreadsheet > Will receive error
opw-3284273
closesodoo/odoo#120473
X-original-commit: 5eb80e34db2e54b56164ea4b98bea3cebb09312b
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
This commit adds to the Record Component, the possibility to pass
the onWillSaveRecord/onRecordSaved props that will be
triggered before the save of the Record and after it respectively.
closesodoo/odoo#120448
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce:
- Install crm
- Go to settings and activate leads in crm.
- Go to leads list and select any lead, now mark it as lost.
Issue:
It will ask for lost reason. But if we do it from the Leads form view,
we don't get to set any reason. I discussed with the PO and we don't
want to add the lost reason in the leads.
Solution:
Modified action of lost so it takes leads into account.
opw-3119748
closesodoo/odoo#120033
X-original-commit: 3834577a8beec2f9eb4a30dd8a0ae72403041af5
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
This commit allows the course manager to add prerequisites
courses to a course so that the final user will be notified
on the frontend he has to take some courses before the one he
wants. He could however request access to the course and
take it without taking the prerequisites before if the access
has been granted.
Task-3213628
closesodoo/odoo#114710
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose:
The purpose of this commit is to change the current behavior of days to close
graph generating from customizable desk demo data.
Specification:
For the opportunities, the day_close field is a compute field depending upon the
date_closed field. For the customizable desk demo data, the date_closed field
pre-existed, due to that customizable desk opportunity was not won or lost but
the graph report was generated.
so, this commit fixes the current behavior for customizable desk opportunity.
Task-3278039
closesodoo/odoo#120433
X-original-commit: e368725b3a042c4071986d0c8d49f724d76a7416
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The fix introduced in odoo/odoo#119017 was no longer taking into account
the refused/archived applications, showing a negative number in some
cases.
task-3293460
closesodoo/odoo#120426
X-original-commit: 55e279f96c9d878103657f437222066ae74dcf0f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
All figures coming from the accounting dashboard should be, by default, excluding the unposted entries since this is the default filter when opening the reports.
opw - 3268676
closesodoo/odoo#120424
X-original-commit: fd20e65fbfeadcc477ea7179900741dd6e98cf16
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: LucasLefevre <lul@odoo.com>
Prior to this commit:
When the mobile preview is clicked in the mailing template of the marketing
automation, the preview is empty. The preview is seen after closing all the
dialog boxes, but it is still not obtained as expected.
Post this commit:
The mobile preview is working properly while clicking on the preview button.
Task-3272504
closesodoo/odoo#120415
X-original-commit: 095b456bf518a6730b5b0039fef40f4cfe8e3511
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit changes the label of the delete modal confirm button from 'Ok' to
'Delete'.
TaskID-3264614
closesodoo/odoo#119025
Related: odoo/enterprise#40487
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Improve some aspects of the recent res partner bank improvement:
- the url toward the docs open in a new tab
- fix the account creation by disabling the readonly when trusted
while the record isn't existing in the database yet
- improve the visual of the setting by putting it in the accounting
section
closesodoo/odoo#120423
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Fix the rank image display which has currently
disappear by making it appear again in the xp circle.
Also making sure the xp circle tooltip is correctly
showing on hover.
Task-3285548
closesodoo/odoo#120408
X-original-commit: e96bd5a7ee4397440503ab4605f2df29d3a2d6f2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The first two arguments of the call() function of the orm service
have been inverted.
This is fixed.
closesodoo/odoo#120404
X-original-commit: 0a4e035083d6d3d62d0041fad62f71668dd77d7e
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Monnom David (moda) <moda@odoo.com>
Before this commit:
Files that should be ignored in the manifest but aren't (js library for example)
it can happen that files have huge lines, the regex to substract the
comments will overuse memory.
For example, a file of 13M with a line of more that 8M characters, the
memory consumptions peak at 1.7G
The results might be different, but it's an acceptable compromise
closesodoo/odoo#120376
X-original-commit: 63b13af2e49a83168d4304a06b6489c4b86eabf6
Signed-off-by: Thibault Francois <tfr@odoo.com>
== Issue ==
A business code error was detected by the internal team on our
production. The cache and assets where invalidated !WAY! too often for
the past months.
It was hard to figure but finally the error was tracked down to be
located in the assets retrieval stack of our code when a database is
accessed through multiple different domains.
In our production use case, whenever one was accessing `odoo.com/web`
after someone accessed `accounts.odoo.com/web`, the assets would be
invalidated and recomputed, again and again, whenever someone accessed
the backend on a domain after someone else did with another domain.
Obviously, on our production, this could be occuring multiple time per
minute.
Technically, this is because the "assets retrieval stack" had a mismatch
in multiple endpoint when trying to find if a current website was
involved (serving for the frontend).
Some business method were using `env.context.get('website_id')` while
others were using `env['website'].get_current_website(fallback=False)`.
From there, when the code was called without a `website_id` in the
context, `get_current_website()` would still return a `website_id` when
called from `http://odoo.com` as there is a website having its domain
set to it. `get_current_website()` is then finding it and returning it.
But it would not when the user is on `http://accounts.odoo.com`.
Since we have a custom scss override (done through our website builder,
basically an ir.asset linked to a "url type" attachment:
`/website/static/src/scss/options/colors/user_color_palette.scss`) for
our website to define the website colors which is shadowing the scss
file from disk.
So, depending of the host/domain, either the real file disk for this URL
or the ir.asset linked to our website for this URL would be fetched to
generate the bundle hash (which is basically the last modification date
of the files/attachments).
Obviously, the file on disk and the ir.assets have a different last
modification date.
The system would then consider the assets as outdated and would
regenerate it.
You can see it in the logs where the attachment id of the assets URL
would get higher and higher everytime you access the DB through another
domain.
Using `get_current_website(fallback=False)`:
- `_get_related_assets()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L14
- `filter_duplicate()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L41
- ..
Using `get_current_website()`:
- `_get_custom_attachment()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/assets.py#L162
- ..
Using `context.get('website_id')`:
- `_get_asset_url_values()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_qweb.py#L23
- ..
== Fix ==
A fix could have been to aligned those to use the same way of retrieving
the website but it would be too fragile (definitely some other places
where the same bug is involved but not yet found).
What is done in this commit is something we wanted to do for a long time
(see [1]) but was based purely on guess and feeling rather than concrete
bug / use case, but now that we found a real use case, we will do it:
- It doesn't seems to make sense to consider the request host/domain
when we are in the backend
- Same for the forced session, those should only impact the frontend
calls.
But this seems to have too much impact in stable to be changed, as it
would require to check every caller to also check for the session if
it makes sense. This will be done in master as not really needed to
prevent the critical bug fixed here.
- When something wants to alter the backend with a website, it should
explicitely be passed in the context, which is still considered
regardless if it's a backend/frontend call.
- If something needs to consider the forced website in session in the
backend, it should explicitely check it, not relying on
`get_current_website()`.
== Step to reproduce ==
- Start a db with website installed
- Enter the website builder in edit mode and change the "Theme Colors"'s
first "Color Presets"'s background color (it is white by default).
- Set the website domain to `http://127.0.0.1:8069/`
- Go to `http://127.0.0.1:8069/web` and login
- Go to `http://127.0.0.2:8069/web` and login
- Now start refreshing those 2 pages one after each other.
Everytime you will refresh the page, it will take a very long time
(~5-10 seconds) before loading the page, and monitoring the logs will
show something about invalidating the cache and huge query count.
== Benchmark ==
For the explained "multiple domain access" case, the backend /web will
now be loaded in less than 10ms and with ~10 SQL Queries when website is
installed, while it was taking ~4 seconds and ~200 Sql Queries before
the fix.
Before the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 222 0.135 3.840 <-- 222 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.101 3.692 <-- 181 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 215 0.121 3.704 <-- 215 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.100 3.616 <-- 181 Queries, ~4s
```
After the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 101 0.043 0.353 <-- 101 Queries, ~0.3s
GET host2.com/web HTTP/1.1 200 - 11 0.004 0.007 <-- 11 Queries, ~10ms
GET host1.com/web HTTP/1.1 200 - 11 0.003 0.005 <-- 11 Queries, ~10ms
GET host2.com/web HTTP/1.1 200 - 11 0.003 0.008 <-- 11 Queries, ~10ms
```
[1]: https://github.com/odoo/odoo/pull/94161#discussion_r904780031 (Also other PR/task but couldn't find those.)
closesodoo/odoo#120364
X-original-commit: 28dd35eb3c681b630f0b3c109a7d8209f9fa42d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Go to a website page > Add a 'Form' block > Add a new 'Selection'
field.
- Go to the page (in 'edit_translations' mode) > The selection field
options are not translatable.
The goal of this commit is to make the select options translatable
by adding an intermediate `.o_translation_select` element.
This element will handle option's text translations from the linked
`<select/>`. The final values are copied to the original element
right before save.
opw-3233360
closesodoo/odoo#120363
X-original-commit: 5ff53d7f289ec531f8369a47d02bd58252bb98a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Current link in settings leads to 404 error page,
changing the path to the right one
opw-3279614
closesodoo/odoo#120356
X-original-commit: beffb2fcab99439c9bf9b398e500e2437e38f9f9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In case you write user_id = False on the sale order,
It will match the first sale team without sale team manager.
It is because False != None.
After this fix, we check if user_id is Falsy instead of None.
closesodoo/odoo#120346
X-original-commit: 8adde86c719b2dc76e21e440c32de1307e5c4da3
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Stock valuation layers are generated for storable and consumable products. However, given that we don't keep track of its quants we hide those layers by default.
by adding a domain [('product_id.type', '=', 'product')].
On the dashboard, such domain is currently not present. As a result, our inventory valuation value is not the same if we look at it though the dashboard.
This commit adds the same domain so that the value of the inventory shown is always the same (which means not including consumable products).
OPW-3275521
closesodoo/odoo#120267
X-original-commit: d392087941367d93ef63fd0ccdb0b988b338218c
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
avoid overriding payment views by creating new computed field in the payment provider property and override it if needed in inherited payment models
task-3120983
closesodoo/odoo#116573
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This task change the people who can edit a calendar event.
This calendar event currently allow every user to modify every
event in the calendar. This cause issue where one user can
modify the time-off event for other employees.
This PR change the right to modify an event from the calendar
view in the calendar app. With these changes, only the people
attending an event will be able to modify it from the calendar
view.
task-id : 3185743
closesodoo/odoo#112964
Signed-off-by: Arnaud Joset <arj@odoo.com>
This commit fixes a few things in the UI:
- The format selection labels could be confusing to users, for example the word "billing" is not necessary here. Now the labels are clearer and structured in a similar way.
- `peppol_endpoint` is recomputed whenever there is a change in the vat but we do not want to make changes if there is already some value in this field. This commit adds a check for whether `peppol_endpoint`is already filled in.
- Same for the `peppol_eas` field - should not be changed if it's already there.
- Both of these fields should be logged in the chatter when changed
closesodoo/odoo#120344
X-original-commit: f749033466c674d91722a2ac753645955da04bad
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Steps to reproduce the bug:
- Go to Decimal accuracy:
- Select the “Product Unit of Measure”
- Set the Value to “4”
- Create a storable product with BoM:
- add any product as component
- save
- Click on the BoM overview widget
Problem:
The “Product UoM” precision is not used
opw-3288403
closesodoo/odoo#120296
X-original-commit: 837a6ca90d6944f9faf4b28e69703f5310c6ec6a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this PR, using the message component wihtout a thread could crash because
props.thread could be undefined (as thread is an optional props).
This PR just add the guard.
closesodoo/odoo#120233
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
*: barcodes_gs1_nomenclature,point_of_sale
In this commit, we are converting the `BarcodeParser` to js class. As a
consequence, instead of having 2 options of instantiating the parser -- via
nomenclature_id or via nomenclature -- we are removing the first option.
Instantiating the parser will now only require the built nomenclature object.
This is possible because in all the pathways where the parser is instantiated,
the web services are ready, meaning `rpc` and/or `orm` services are ready. As a
result, the consumer of the parser can just build the nomenclature object itself
by fetching the nomenclature details from the server. A helper static method
called `fetchNomenclature` is introduced in the `BarcodeParser` class to aid in
building the nomenclature object it needed.
Furthermore, the methods that return the required nomenclature and rule fields
are converted to static fields which can still be patched (check
barcodes_gs1_nomenclature in enterprise).
closesodoo/odoo#120228
Related: odoo/enterprise#40582
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Noe Antoine