[This other commit] introduced a method to serve Google fonts from the
local server. Then it has been back-ported to previous versions with
[this commit].
Unfortunately, the font was not identical when the user chose to load
the font from Google servers versus from the local server. This
discrepancy was due to a missing parameter when downloading the font
file to serve it from the local server. This commit fixes the issue by
adding the missing parameter.
Steps to reproduce the issue fixed by this commit:
- Drop a text block onto a website page.
- Make the text bold.
- Go to the theme tab.
- Change the font to https://fonts.google.com/specimen/Poppins
=> The text style changes depending on whether you checked the "Serve
font from Google servers" option or not.
[This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd
[this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3
opw-3775683
closesodoo/odoo#157800
X-original-commit: be2d27e69d7928a46d49a7ef0a3c4b93932a36b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
During the copy of provider if the journal is set, it create a new account.payment.method.line, and if you change the company of the new provider you have an error when you try to create a new journal.
closesodoo/odoo#157767
X-original-commit: 0357c9ec749d893ba1d7913903fd0c45df400662
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Create an invoice to partner A, confirm
Create an invoice to partner B, confirm
From Invoice list view, select just one invoice and hit register payment
It will be possible to only select journals having inbound payment
method
Now select both invoices and hit register payment
It will be possible to select any Bank journal, even if both invoice
payments should be incoming
opw-3757686
closesodoo/odoo#157732
X-original-commit: 88f43a454f3cd9207aa62e2e58b67bcfdf0fcb59
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
[FIX] microsoft_account: accessing the url without any post data
When a user tries to access the URL directly, at that time the value of
dictionary `kw` is not available. So the error will be generated.
Error : KeyError: `state`
This commit will solve the above issue by raising the `BadRequest` if the value
of dictionary `kw` does not available.
sentry-4377121133
closesodoo/odoo#157720
X-original-commit: 382b64c2f14073cfff1a8ef9290b5c7834d52188
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
------------------
- Have Website and Mail Group installed
- Send Guidelines for a mailing list through the Website app
Issue
-----
{{ object.mail_group_id.name }} appears in the body of the "Mail Group: Send Guidelines" mail template instead of the actual mail group name.
opw-3778512
closesodoo/odoo#157772
X-original-commit: fe05e7c6acf02986a154af1235ac244a7686b30b
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
When the cookie bar is activated, the optional cookies are deactivated
by default, unless you click on I agree.
This causes issues regarding UTMs:
- You can have blocks to show only if an UTM cookies has been set
- UTM should be added on sale order for instance when reaching the
website through a link with an UTM and then buying something
Steps to reproduce (utm on quotation):
1. Install ecommerce
2. Go to Settings/Website
3. Activate Cookies Bar
4. Open a private tab
5. Go to /shop?utm_campaign=Sale
6. Click on I agree on the cookie bar
7. Buy a product
8. Go back to Sales App in backend
9. Find the last public user quotation
10. Go to other info tab
11. The medium field is empty
Steps to reproduce (utm based visibility):
1. Drag & drop a snippet on a page (let's say the /page)
2. Set that snippet visibility to "Visible only if utm campaign is
"Sale"
3. Repeat step 2 3 4 from above
4. Open /page?utm_campaign=Sale
5. You will see that the block is not shown despite accepting the
cookies and having the correct utm set.
Note: we don't want that clicking on I agree reload the page, it would
solve everything but would have poor usability.
Note that with the default cookies bar, you could still naviguate to
another page, and accept the cookies later, in which case the UTM would
never be set since they would not be in the URL anymore.
It's an acceptable limitation, if that's a real issue to someone, they
have to set the popup layout to a blocking one, not the small non
intrusive one.
Fix:
When closing the cookie bar, forcing the info in the URL to be stored in
the cookies if the key is a UTM.
opw-3681927
closesodoo/odoo#157711
X-original-commit: 8c31c2b08ed84ccdb97af628d9db7f6c67c6d830
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Antoine (ande) <ande@odoo.com>
Steps to reproduce:
- Create an empty database (without demo data)
- Install stock_account
- Go to Invoicing settings
- Select Austria as Fiscal Localization
- Go to Apps
- Try to upgrade stock_account module
Issue:
A traceback is raised.
The module tries to create the default stock accounts properties on
the main company, but they already exist, which triggers a violation
of the SQL unique constraint (ir_property_unique_index) of "ir.property"
on the combination of (fields_id, company_id, res_id) fields.
Cause:
When "stock_account" module is installed/upgraded, the default stock
accounts properties are created for the main company with forcecreate="True"
option, which means they will be created if their "xml_id" doesn't exist, even
if they are declared inside <data noupdate="1">.
In this case, they are created with their "xml_id" at the module installation
with the following values:
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: False
When the Austrian localization (or other localizations defining their own
stock accounts properties) is selected in the settings, these default properties
are deleted and replaced by those coming from the localization package with
some similar values but without "xml_id":
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: [depends on the localization package]
Then, when upgrading "stock_account" module, as the "xml_id" of the default
stock accounts properties cannot be found anymore, the upgrade process will
try to re-create them and will trigger the SQL unique constraint.
Solution:
Move the creation of the default stock accounts properties in a python function
to check if the default properties already exist based on the combination of
"company_id", "fields_id" and "res_id" fields and not based on the "xml_id".
opw-3682320
closesodoo/odoo#157703
X-original-commit: 7e710e4effae6dc812a9304090b5796b39fed640
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Before this commit, there was no message in the logs when the import of
a data module is finished. This commit adds a log info to state that the
module is now in the db.
closesodoo/odoo#157687
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
This change allows for locked purchase orders to be matched with OCR
closesodoo/odoo#157569
Task: 3798080
X-original-commit: 59fe446aee1ee6d634aa286adc261a3c7f547d14
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Joris Makauskis (jmak) <jmak@odoo.com>
Before this commit:
POS online payments uses the logged-in user or the public user,
even when a POS order customer might also be present.
After this commit:
We check the partner_id for POS orders and give it
precedence over both the logged-in user and the public user.
task-3805695
closesodoo/odoo#157562
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue
-----
In a POS session, some buttons of the numpad and some fields in the client editor form are not translated.
opw-3783252
opw-3756593
closesodoo/odoo#157509
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Steps to reproduce:
-----
1. Have lunch app activated
2. Settings > Technical > Scheduled Actions
3. Run manually a scheduled action to send an automatic email to a lunch provider with "send order by" not equal to email.
** Traceback error **
Changes
-------
The user will see an UserError instead of a traceback.
opw-3751229
closesodoo/odoo#157305
X-original-commit: 13792ee52f96d739ef1b7af0f1323906b1a39ee4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Steps to reproduce:
- Install timesheets
- click on all timesheets
- open search view
Issue:
- in search view 'my' filters block should be at the top of the list
Cause:
- misplacing of the name month filter causes the issue.
Solution:
- if we replace that filter below the group then the issue will be solved.
task-3772684
closesodoo/odoo#155714
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since this commit [1], the two searchbar snippets are broken.
The search bar input seems invisible because it shares the same color as
the default snippet background and has no border. This style matches the
search inputs used in apps (like the "/shop" search bar), which isn't
affected by the "Input fields" settings in the "Theme" tab.
To resolve this issue, this commit introduces a new option to choose
between the "light" style (similar to "/shop" search bars) and the
"default input style" for the 2 "Search" snippets.
The "default input style" is automatically applied when the "Search"
snippet (excluding saved snippets) is dropped to address the issue
caused by the light-on-light color scheme.
Steps to reproduce the issue:
- While in Website edit mode, drag and drop a "Search" snippet onto the
page.
- Bug: The input appears invisible due to the lack of a border and a
background color identical to the snippet's section color.
[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20
task-3662985
closesodoo/odoo#154435
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
In Knowledge, embedded views anchors have a `data-behavior-props` attribute
containing information on how to render the embedded view. That attribute is
sometimes updated, and during a collaborative session, receiving such an update
as a collaborative step would trigger a full sanitization of the embedded view,
possibly discarding some transient content that could break the view, even
though it caused no security issue since it is all rendered on a per client
basis (each client fully renders its own view).
The proposed solution is to sanitize only the attribute of the node and not its
content during `_safeSetAttribute`, which is reasonable, because the node
content is already sanitized recursively for `add` mutations.
task-3060490
closesodoo/odoo#157669
X-original-commit: d9e3d7bdb6e13e6049a86ed08160daccf0fcbcc8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce:
- Install "French" for the website
- log out and log in as demo
- Go to the front-end and click on "Courses"
The design of the karma wheel is broken because the translation for "Get 7.5k< xp to level up!" displayed in the wheel is too large ("Obtenez 7.5k xp pour passer au niveau supérieur"). While in French the text go outside the wheel and it appears clearly broken, it is also the case in English as the rank name is hidden due to the length of the text (for example when gaining one karma: 7.49k is displayed instead of 7.5k which takes more place).
To avoid modifying the template "profile_next_rank_card" that could break community overrides, we solve this problem in css by increasing the karma wheel size and the precentage of width occupied by the text inside the wheel. We also reduce the vertical margin between the rank name and the descriptive text and reduce the line height to avoid the text to overlap with the wheel. And if the text is still too large for some language it will be truncated and an ellipsis will be used.
Technical note: we do the change in website_profile.scss (and not in website_slides.scss) because it applies to both karma wheel: the one on course home page and the one in the profile page.
[FIX] gamification: fix incorrect next rank
How to reproduce:
- Install website_slides with demo data
- Connect as admin
- Go to the front-end and click on "Courses"
The karma wheel shows 100%, "master" and a karma of 2.5k xp while it should be: 4% on the wheel, "Doctor", 2.5 / 10k (karma_min for master is at 20k and next level is doctor at 10k).
We solve that issue by fixing the method that determine the next rank (see technical note for more details).
Technical note: the problem occurs because the admin user has the rank 4 but its field next_rank_id is null while there is a level 5. In that condition, the method _get_next_rank returns an empty recordset while it should return the rank 5. We simplify that method to always return a rank if there is one suitable (if you reach the last level, there are no next level).
(Initial PR in saas-16.1: odoo/odoo#151372)
Task-3617054
closesodoo/odoo#157655
Forward-port-of: odoo/odoo#157585
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
How to reproduce:
- Install "French" for the website
- log out and log in as demo
- Go to the front-end and click on "Courses"
The design of the karma wheel is broken because the translation for
"Get 7.5k< xp to level up!" displayed in the wheel is too large ("Obtenez 7.5k
xp pour passer au niveau supérieur"). While in French the text go outside the
wheel and it appears clearly broken, it is also the case in English as the rank
name is hidden due to the length of the text (for example when gaining one
karma: 7.49k is displayed instead of 7.5k which takes more place).
To avoid modifying the template "profile_next_rank_card" that could break
community overrides, we solve this problem in css by increasing the karma
wheel size and the precentage of width occupied by the text inside the wheel.
We also reduce the vertical margin between the rank name and the descriptive
text and reduce the line height to avoid the text to overlap with the wheel.
And if the text is still too large for some language it will be truncated and
an ellipsis will be used.
Technical note: we do the change in website_profile.scss (and not in
website_slides.scss) because it applies to both karma wheel: the one on course
home page and the one in the profile page.
Task-3617054
X-original-commit: f32eabf55db4db4d46b45032c76bfa17dfce475f
Part-of: odoo/odoo#157655
How to reproduce:
- Install website_slides with demo data
- Connect as admin
- Go to the front-end and click on "Courses"
The karma wheel shows 100%, "master" and a karma of 2.5k xp while it should be:
4% on the wheel, "Doctor", 2.5 / 10k (karma_min for master is at 20k and next
level is doctor at 10k).
We solve that issue by fixing the method that determine the next rank (see
technical note for more details).
Technical note: the problem occurs because the admin user has the rank 4 but
its field next_rank_id is null while there is a level 5. In that condition, the
method _get_next_rank returns an empty recordset while it should return the
rank 5. We simplify that method to always return a rank if there is one
suitable (if you reach the last level, there are no next level).
Task-3617054
X-original-commit: 6639005e660d0516a7624bd274c27e897797d614
Part-of: odoo/odoo#157655
Some translations were missing or incorrect for the VJ grid
in the Tax Report.
task-3724926
closesodoo/odoo#157622
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Refactored the owner_id check in the stock_account module to make it more flexible for future updates.
Before, any changes or additions to how ownership is checked required overriding the whole method.
Now, it's easier to extend ownership checks without such heavy modifications,
paving the way for more straightforward updates and customizations related to inventory ownership.
closesodoo/odoo#157614
X-original-commit: b01b73d58f57930bbfa705f5206e6e57f3816aa5
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
context of the creation of a new record
closesodoo/odoo#146019
X-original-commit: c3aea407ccf9903ea9b43edfdd0289b63c478ffb
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
- Click on the footer and enable footer "Slide Hover" option
- In the theme tab, add a theme bg image
- Drag & drop a "Text - Image" snippet (or any snippet without a bg
color set, or any snippet with a bg color set and just remove it)
- The snippets and page layout in genral will receive a forced color
instead of using the bg image set.
This is because with the slide hover option, the bg has to be moved from
the `#wrapwrap` to the `main`. Indeed, it's the main which is scrolling
hover the footer, not the `#wrapwrap`. Without doing that, the elements
hover the footer would have a transparent background and would not hide
the footer.
But the bg image was not considered when doing it, only the bg color.
opw-3704746
closesodoo/odoo#157638
X-original-commit: 68c8a7f48ac955a8e9e4f1fc8cb1c76af54116b3
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
1. Go to the website
2. Drag a snippet that contains an image
3. Select the image block
4. Go to customize the image
5. Go to transform - select crop image
6. Crop and apply changes -> Overlay is hidden
Before this commit, after cropping an image the overlay was hidden. To
make the overlay visible again, you have to click elsewhere on the
snippet and then click on the image again, because the overlay was being
hidden.
When we perform an image crop, we activate the `hide_overlay` action,
which subsequently eliminates the `o_we_overlay_preview` class. This is
due to the fact that, during the image-cropping process, the
`previewMode` is set to `false.` However, if we wish to keep the overlay
visible, We can simply avoid triggering the "hide_overlay" action.
task-3392225
closesodoo/odoo#157635
X-original-commit: 2075b4c957a8e2d03fcfd8bfab99be1e49c31ca9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Enter Website edit mode.
- Drag and drop an "Image-Text" snippet onto the page.
- Grab the right edge of the right column of the snippet and extend it
to the right until it overflows the iframe and hovers over the editor
panel.
- Release the mouse, then hover over the iframe again.
- Bug: The "mouseUp" event was not triggered, and the column resizing
still occurs.
This bug occurs because the "mouseUp" event was attached to the
<body> of the iframe and not to the window of the iframe.
Indeed, for mouse events to be triggered outside of an iframe, they need
to be attached to the iframe's window.
This fix is not necessary before the version 16.0. Before V16.0, the
page preview and the options panel shared the same window. It's only
since this commit [1], where we moved the page preview into an iframe,
that the bug occurs.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
taks-3562970
closesodoo/odoo#157627
X-original-commit: e6be732450d9ef662a48ba074e1ca1ad32e35c04
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Add the possibility to call the send & print with *only* a set of options.
All other checkboxes are therefore set to False, instead of their default computed value.
closesodoo/odoo#157532
Related: odoo/enterprise#58574
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Create a new Journal Entry
Add a 100$ debit line 1
Add a 100$ debit line 2
Add a new line: system will suggest 200$ credit line 3
Save
Delete line 3
Change line 2 amount into 50
Create a new line
Issue: the system will compute a credit amount of 50$
This occurs because in the onchange we work with a new record
representing the set of changes
Commands sent by the orm are:
- DELETE of line 3
- UPDATE of line 2
So in the new record we don't have information on line 1.
A solution is to recover the data from the stored record
opw-3757415
closesodoo/odoo#156875
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce:
- Install planning app.
- Go to planning app, and convert the view to List.
- Group by Resource -for example-.
- Notice how the allocated time values are mis-aligned with the header label.
Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.
The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
- both firstAggregateIndex` = `lastAggregateIndex` = -1
- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1
- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.
opw-3764616
closesodoo/odoo#156647
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Get to a list view where there's a monetary field AND the related currency
field in the same list.
Then insert the list in a spreadsheet.
=> Either the currency format is not fetched or the currency name, depending
on the order in the list.
Bug introduced by 8777973e
opw-3770057
closesodoo/odoo#157623
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Negative days are no longer allowed in the Payment Terms since 16.2, although it was possible before.
There is no need to block user behaviour if they require negative days (for example, days before end of the month), as the payment term works as expected with negative days.
To fix, we remove the constraint _check_positive.
To reproduce the issue:
- Go to Accounting -> Configuration -> Payment Terms
- Edit/Create a Payment Term with a negative value in the 'After' column
- When saving, a Validation error appears
task-3751491
closesodoo/odoo#157600
X-original-commit: fe1399a1821a05638c638fc4f0437a7aed70e260
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In all cases, we will fetch the record since we display the name, so it
has no extra cost to slug the record instead of the id, and it will
prevent an extra redirect from /tag/1 to /tag/name-1 on click.
opw-3752989
closesodoo/odoo#157578
X-original-commit: c406220277a3005cde34a44ba733d470769c2dc4
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Steps
-----
1. Create a time off request, approve it and add a document.
Issue
-----
The details of the time off request are not visible when the attachment preview is displayed.
opw-3792894
closesodoo/odoo#157024
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Issue: When editing with the editor an event and removing the title
we get an issue since the url that we usually got is formatted like:
'/event/title-3/register' where title is our event title and 3 the id,
but when leaving the title blank the url will change to be like:
'/event/3/register' in this case the match will no longer find anything
since we no longer have a '-' on our url.
Steps to reproduce:
1. Install website_event and go to the website view of any event.
2. Edit the event, and leave the title blank.
3. Save, and try to edit again the same title.
Solution: We can directly get the id without the preciding '-', in this
case we will get the id in both cases without having mismatch error.
opw-3783998
closesodoo/odoo#157534
X-original-commit: ed236a2097f962dbb39f3cb0b8b9f099285fa0e3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The cost of sales accounts need to have the type expense_direct_cost for the Gross Profit calculation in the Profit and Loss report to be correct
closesodoo/odoo#155374
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In this pr I renamed account 220100 to KRA - VAT payable and created the new KRA - VAT receivable accounts. These accounts are now used as the Tax Payable and Tax Receivable accounts on all the tax groups
closesodoo/odoo#153646
Task: 3725559
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit, it could happen that the More dropdown was
displayed, but it only contained a single stat button. This isn't
what we want, as that single button could simply be displayed
instead of the More dropdown toggler.
Task 3778382
closesodoo/odoo#156241
Related: odoo/enterprise#58565
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce:
- Create a shiping method based on rule
- Set margins and then swith back to fixed price
Bug:
since this PR https://github.com/odoo/odoo/pull/108794
margins aren't displayed on the form anymore for fixed price
but they are still set on the model if we edit the delivery type
opw-3759128
closesodoo/odoo#157452
X-original-commit: 79bc772c8d48f64e0bd41fa0f5a40b1cd853293f
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Emphasize the preview with colors and field borders to:
- visually outline the preview result
- clarify to the user that there are editable fields which customize the preview
closesodoo/odoo#155367
Task: 3751514
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit, when an error occurred during the installation of a
data module, there was no displayed error nor a rollback to remove data
already installed from the module.
This commit makes sure that, if an error occurs, it is displayed through
a UserError that will do a rollback to remove every record from the
module.
closesodoo/odoo#148823
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
In the German localization, "Sales Order" MUST be translated as
"Auftragsbestätigung". In all other cases it can remain as
"Verkaufsauftrag".
Term was previously corrected but then overwritten by accident during
fw-port that used old translation.
closesodoo/odoo#157496
X-original-commit: b4cd19a456242dea6ad7bddc2efaf17382ffb453
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
In rework of accruals plan, we removed the possibility to set a time off type on the accrual plan directly.
The field has been removed from the form view, but not from the list view.
closesodoo/odoo#157366
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit the Email Sent Count (located in the Communication
tab of the event view) wasn't including emails sent to the attendees who
weren't confirmed.
[This commit changes]
Event mail scheduler will include seats_uncofirmed into calculation of
the mail_count_done which is the count of emails sent. This is
reflecting the actual number of emails sent.
[Reproduce]
- Install event_mail,event_sms
- Create event E starting in time T (Events/Events)
- Add an "Unconfirmed" attendee (Modify state via database write)
- Add an E-Mail in the Communication tab of the event E
- Set Interval time > T,
- Template: "Email Reminder"
- Trigger "Before the event"
- Run scheduled Action sending email (Scheduled Actions / Event: Mail Scheduler)
- BUG: email sent, but not included in the sent count in the communication tab of the event E
opw-3693626
closesodoo/odoo#157229
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
A subcontracting BoM sometimes shows negative values in Overview, if
components are available in subcontractor's location.
closesodoo/odoo#144702
Task: 3607854
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The condition to decide which moves to consider to create new
orderpoints is incorrect. For example any move from a location that
is sublocation of the main warehouse location should be considered
as a out move. The inverse condition doesn't make much sense.
closesodoo/odoo#157459
X-original-commit: 7c123a5c1d8ed8bf856d4701a972f59737323646
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install Sales, Accounting and Inventory apps.
- Go to Inventory > Configuration > Products > Product Categories.
- Open All / Saleable / Office Furniture and:
- Set the Inventory Valuation as Automated
- Set the Costing Method as First In First Out (FIFO)
- Go to Inventory > Reporting > Inventory Valuation
- Open the toggle header then Click on the plus button at the header.
- In the popup shown -Notice how the current value is 0-, set:
- Added Value to 1000
- Counterpart Account to 600000 Expenses
- Click on REVALUE, a new report appears.
- Open the newly created report > Other Info, open the Journal Entry
- In the Journal Items tab, notice the label says that `the valuation was changed from 1000 to 2000` while it should be `the valuation was changed from 0 to 2000`.
Investigation:
- the `current_value_svl` field is related to `product_id.value_svl` https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L34
- Which get computend using `_compute_value_svl()` depending on `stock_valuation_layer_ids`
- When we revaluate, we trigger `action_validate_revaluation` that performs this line https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L110 creating new stock.valuation.layer triggering the `_compute_value_svl()` method setting the product `value_svl` to the updated value (current + added) which then updates `current_value_svl` being a related field
- That's why now `current_value_svl` is the new value and not the old one.
opw-3715522
closesodoo/odoo#157450
X-original-commit: 065b6632b133d780543c9f40beb536c2ff37ff52
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Issue -->
In `_onClickSaleOrder`, we load in the partner on the sale order using
`load_new_partners()`. However, the search on the `res.partner` model made in
this method has the potential to return every single `res.partner` record
because of the domain that it uses --> https://github.com/odoo/odoo/blob/6c2dd5fbd9898f0efecdc35593af69bfd7d4eb50/addons/point_of_sale/static/src/js/models.js#L783-L785
After doing so, we check if the parter has been loaded and we grab the id using
`get_partner_by_id`. If the partner is not loaded, we use `_loadPartners` to
load them.
Since we are already checking and reloading the partner on the sale order
using `_loadPartners`, using `load_new_partners()` earlier is redundant.
Solution -->
Remove the try-catch block that loads multiple `res.partner` records during
the process of clicking a sale order via POS.
opw-3619941
closesodoo/odoo#157469
X-original-commit: b47e7bdd15e0738b479153fec495d009aeae9967
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Aditya Dasgupta (adda) <adda@odoo.com>
In one2many, for the view, the attribute to hide a field should
be column_invisible and not invisible
closesodoo/odoo#157356
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Guillaume-gdi