Before this commit:
When importing `stock.quant` with two lines with the same product and
different counted quantities, only the last line is taken.
After this commit:
Each line creates a `stock.quant`, even if a similar Quant exists.
The records will be merged at a later time by `_merge_quants`.
Steps to reproduce:
1. Create a storable product
2. Go to Inventory > Operations > Inventory Adjustments
3. Create a file with two lines with the same product,
and different counted quantities
5. Favourites > Import Records & upload the file
OPW-3340017
closesodoo/odoo#126480
X-original-commit: 45f7368222ead5df600992c66f0da56b3a7e959a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.
In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.
The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.
NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt
opw-3144519
closesodoo/odoo#126474
X-original-commit: e3a5b46c7b4f5030e165a6d943ec2275aea5d583
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Currently, it's not possible to check the 'Peppol Bis 3' option on the
journals of Italian companies, since Italy is not present in our mapping
`COUNTRY_EAS`.
The EAS for Italian companies may be the codice fiscal (code: 0210) or
the VAT number (code: 0211). See
https://peppol.agid.gov.it/en/news/expiration-validity-codes/
Use the VAT number by default, and add it in our mapping such that the
option now appears for Italian companies.
opw-3346572
closesodoo/odoo#126462
X-original-commit: 92784a0a230c7e93e3ed9fb215376cbbf5ba1362
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Adding base translation files for l10n_sa_edi as well as arabic translation
closesodoo/odoo#125610
X-original-commit: 52e96a5ca8a051d8a1a57e1606b4b1b9e810ba7f
Signed-off-by: Josse Colpaert <jco@odoo.com>
- kanban view progressbar based on status
- new first column 'New' with the welcome mail template
- create date column renamed to 'applied on' and moved to front
task 3346175
closesodoo/odoo#123293
Related: odoo/enterprise#42098
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This traceback raises when user not selected 'Employee' and only selecting
'Check In' and 'Check Out', while creating a new attendance.
To reproduce the issue:
1) Install hr_attendance
2) Open Attendance and create a new record
3) Give values to only 'Check In' and 'Check Out'
Error: "AttributeError: 'bool' object has no attribute 'upper'" appears.
On '_compute_worked_hours' method calendar variable is getting value from
employee_id and that calendar timezone is used to get timezone.
https://github.com/odoo/odoo/blob/937d207028ab9bc1d3d332dc6dfe25f0de045026/addons/hr_attendance/models/hr_attendance.py#L50-L60
Therefore in the above use case, when triggering the compute method,
because of 'calendar' is depending on 'employee_id' and when
employee is not selected, it will leads to the above traceback.
Sentry-4274226351
closesodoo/odoo#126465
X-original-commit: 31491e40d2505c03d76e6c802435ad1dafa71c52
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Latams need more fields for VAT and Odoo Milk broke
how these fields are displayed.
opw-3382698
closesodoo/odoo#126461
X-original-commit: 960d47ccc9db2ae69836a5f1ed7bff163b051a42
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before, when instantiating the taxes for France in a Belgian
company through a French fiscal position (multi-vat),
a traceback would be shown because the cash based transition
account would not be retrieved in the correct way.
By checking the existing accounts (which
are created on the fly for multi-vat) instead of browsing the record
and also, by allowing no account at all, we avoid tracebacks and the
taxes get created.
closesodoo/odoo#126473
X-original-commit: 85f45e37c4ad9503dcc96c321d26504bce3de2c0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
before this commit, The Kanban view for project tasks includes a subtask button,
a remaining hour timer, an activity button, and assignees in its lower section.
However, when the task has subtasks and timesheet entries, these buttons appear
in the Kanban view, causing the view to lose its structure somewhat.
This commit includes reducing the right margin of the activity button and
remaining hours to provide enough space for other elements in the kanban view.
Additionally, the Lock Icon for private tasks has been given a left margin to
separate it from the activity button
task-3289941
closesodoo/odoo#126446
X-original-commit: eff472e39642bb29e5d4615fcfe1255c00ffc5ef
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
In the portal view of the project AGR project has 11 Tasks on the list view
but when you click on it, inside there are 12 tasks, not 11
Cause:
The Kanban view of the project includes a button for task
count, which displays the total number of open tasks in the project.
It seems that the task count button displays the correct count because the form
view of the task includes a default filter for 'Open Tasks'.
The form view of the project-sharing feature does not have the default filter of
'Open Tasks'. As a result, the count displayed by the task count button in the
kanban view is different from the count displayed in the list and Kanban views.
Fix:
In this commit, a default filter is passed through the context to ensure that
the task count displayed by the task count button is the same as that displayed
in the list and Kanban views.
task-3289941
X-original-commit: 96304e9b237c06a5d0b459d304df3afbf7607f04
Part-of: odoo/odoo#126446
The code snippet removed by this commit had no useful effect, as
`selection.addRange(range)` a few line above triggers
`OdooEditor._onSelectionChange`, which repositions the toolbar
elsewhere.
The result was a "glitch": the toolbar would briefly be displayed over
the top left corner of the media before finally being displayed above
(or below) it.
This commit removes such undesirable effect.
task-3347942
closesodoo/odoo#126445
X-original-commit: f0272411f6cab059cc8bc2ceed37d9ce59ffe80c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit the position of the arrow was incorrect when the
editor is inside an iframe.
For the calculation of `arrowLeftPos` we need the difference between
the selection rectangle border and the toolbar's left position.
While `correctedSelectionRect.right` is relative to the current iframe's
borders, `left` is relative to the top document's window, as it has been
offset with `parentContextRect.left`. We need both values to be relative
to the same referential in order to make this calculation make sense.
task-3347942
X-original-commit: 8bad3a3fb00d59498455205e8d286a38adaf1335
Part-of: odoo/odoo#126445
Before this commit, an error in the toolbar position happened when the
editor was inside an iframe and the iframe's window had scroll bars.
Steps to reproduce:
- go to the Market Automation app (enterprise edition)
- create new campaign
- add new activity
- create a new mail template by typing a name and selecting "create and
edit"
- select the "plain text" theme
- add a lot of content in order to have the scroll bars
- scroll down
- select something to display the toolbar
The `scrollX` and `scrollY` variables in `_positionToolbar` are ment to
correct the floating toolbar position in case the document in which the
toolbar is mounted has some scrolloffset.
As the floating toolbar is always mounted on the body of the top
document, this is the document to watch for scroll offsets, and not the
inner document when the editor is mounted inside an iframe.
task-3263463
X-original-commit: fb080218def7c47e7b96cf284d613fc03b8325f6
Part-of: odoo/odoo#126445
When a field had an error (required, wrong format etc), upon submission
of the form there would be a JS traceback preventing the page to work
anymore (the Donate button would spin forever).
This is because the code was not adapted to the Bootstrap 5 migration.
It seems like this code to update the config's content is not required
anymore, as without it the content is correctly updated through the
existing `.popover()` call a line above.
You can ensure that by simply omitting your email and send the form, it
will tell you that the email is required. Then just type "a" in the
email field and send again, it will tell you that the format is not
correct.
Somehow, it seems to also be the case in Odoo 15 in Bootstrap 4,
removing those line do not break that.
Some fixes were made at [1] and [2] about the same issue but somehow
people just fixed their own case, while grepping `.config.content` would
have easily found this one too.
[1]: https://github.com/odoo/odoo/commit/37546006940f99c8860e89997ed7a623abd5fa72
[2]: https://github.com/odoo/odoo/commit/0cff1dc2967cafeb8964ed0802c309d3bb7f7525
opw-3381196
closesodoo/odoo#126444
X-original-commit: 9e46ceea801d5044f5db4fee65d5980c64cfa23b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In case we use multi company and a user does not have an employee
in every company which is quite normal (mostly you are employed with
exactly one company), the calendar is skipping the provision of the
unusual days like public holidays or the working schedule.
To be able to access and see the calendar in such a case we fallback
to the company calendar and fixed a domain for the public holiday
retrieval whereas the public holidays are not assigned to an employee
but the company or the companies chosen to be displayed.
closesodoo/odoo#126420
X-original-commit: d80a3965b7356f9d6b1294cf428667a1057a272b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When processing the buttons in the header of the arch,
the listArchParser did not use the method on this.
This was a significant drawback when trying to extend
the behavior of the parser.
After this commit, the processing of the button goes
through the existing method on this, making it possible
to extend that behavior. Note that for the processing
of the other buttons in the arch, this modification has
already been done earlier.
task-3072937
closesodoo/odoo#126400
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
+ update PO and POT files
+ unify i18n and i18n_extra
+ rewrite traditional Chinese to simplified Chinese
closesodoo/odoo#126396
X-original-commit: 02c6c2bed691f263a383636c5209aba5c8c6cf57
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The customer was having an issue where they would create an expense from an email with the wrong cost on the expense.
Then when they would try to change the price on the expense record it would seem find all the way up until the journal was posted.
Issue:
When creating an expense from an email the unit_amount is updated instead of the total_amount.
This would cause issues if you had an attachment because when you would attempt to change the amount through the front-end this unit_amount would never get updated because it was set and there was an attachment (line 265).
However, when you would create a journal entry from this expense, because it has the unit_amount != 0 it would provide the unit_amount instead of the total_amount.
Thus propogating the original number from the email even if it was updated between the time of posting and the creation of the expense from the email.
Solution:
Implement an inverse function on total_amount that will update the unit_amount to total_amount_company.
This will cause the unit_amount to stay up to date with the total_amount while also taking into account currency.
opw-3286372
closesodoo/odoo#126388
X-original-commit: c2588824edc732bea40b1a8f6e5248b3d318b361
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
In the website settings, one of the fields allows you to switch settings
from one website to another. Unfortunately, as soon as the user did this
the record was considered to have changed (dirty) and therefore required
a save when it wasn't necessary. The previous commit prevents the header
settings (like the website switcher) from dirtying the record. This was
really necessary because as soon as a user had several websites, it was
impossible for him to access certain settings on all these websites
(except the first one). As soon as the setting performed an action, a
save was required (because the record was dirty) and the user was
redirected to the settings again.
Steps to reproduce the issue before the previous commit:
Install website
Have multiple websites
Go to Settings > Website Settings
Change the website
=> The user is notified that the record has changed and needs to be
saved, which is not true. So far it's annoying but not critical, but if
the user continues:
Activate the "Extra step during checkout" option
Click on "Configure Form"
=> The Save/Discard dialog appears because the record is dirty.
Click on "Save"
=> The user is redirected to the settings page again and cannot access
the form configuration of the second website. (it is the same issue for
most of actions).
The previous commit fixes the issue and this commit adds a test to
ensure that the users are able to change settings of multiple websites.
task-3265100
closesodoo/odoo#126387
X-original-commit: bed37396839891da04126a71b3d6a6e5e56672b0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When a user changes a header setting, the record should not be marked as
dirty. If the user clicks on a button, the save dialog should not be
shown.
Next commit will bring a functional test and "steps to reproduce" of
this issue in website.
task-3265100
X-original-commit: 1a64fd83f8be677b76ad97a11928859c63709972
Part-of: odoo/odoo#126387
Co-authored-by: "Guillaume (gdi)" <gdi@odoo.com>
Steps to reproduce, on SaaS only, not reproductible in standard:
1. Start a new SaaS Trial on saas-16.3
2. Install helpdesk, setup an incoming mail server
3. Send an email, one that should create a new helpdesk ticket
4. Traceback, request has not 'is_frontend` attribute.
This commit doesn't solve the root issue, it only makes it possible to
use helpdesk again. Using getattr/hasattr to access request.is_frontend
SHOULD NOT be necessary since [HTTPocalypse] BUT there are some rogue
controllers that bypass the normal flow of execution and fail to meet
the expectations of the new http stack.
This commit only makes the code robust to a missing attribute in this
very case as this is a recurring problem (unusable helpdesk). The root
problem is unlikely to be located nor in http_routing, nor in helpdesk.
THIS SOLUTIONS OF USING `getattr`/`hasattr` TO ACCESS `is_frontend` MUST
NOT BE REPLICATED ELSEWHERE WITHOUT PRIOR CONSULTATION WITH PEOPLE IN
CHARGE.
[HTTPocalypse]: https://github.com/odoo/odoo#78857
See-also: https://github.com/odoo/odoo/pull/99667
See-also: https://github.com/odoo/internal/pull/1902
opw-3359740
opw-3365843
closesodoo/odoo#126386
X-original-commit: c808719619167a582dd28420ff2979b57102d2ab
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
As the leave is deducted from the needed time to work
in case for example Home Office which is configured as
working time (other) is handled like a real leave (absence)
which will lead to an extensive overtime instead the difference
to the work entry defining the work time.
A domain clearing out this missing link and variation
cleans up this misalignment and therefore overtime will
be computed correctly.
closesodoo/odoo#126373
X-original-commit: 02a679d6ab7db49c8338471e5fc85c1141f8e877
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Currently, if we have a look at the field "Due date" Or "payment terms", the placeholder "terms" seems confusing, no one knows that it will open the "payment terms" list from there as a label of the field is "Due date"
closesodoo/odoo#126362
Task-id: 3340547
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This PR fixes an alignment issue for the attachments in the
chat windows. Indeed, those attachments were always displayed
to the left while it should be to the right in case it was
uploaded by the current user.
closesodoo/odoo#126355
Signed-off-by: Didier Debondt (did) <did@odoo.com>
The ZATCA edi has an onboarding process which happens per journal.
A private key is generated for the company and with the data from
the company and journal a CSR is made to get a certificate to sign the
invoices. In that process that contains multiple steps (see account_journal.py),
we also have to send the compliance files which are some example (simplified or not)
invoices/debit and credit notes. We have a separate folder with those files
and also use them in the tests. For the onboarding, they still need to be signed however.
For the sending of the customer invoices themselves, UBL 2.1 is used, but
with ZATCA style adaptations. That is why we inherit from that class
to be able to add those specific adaptations. This UBL needs to be
signed XadeS and in this case we need to do the hash with the sign information
present but with empty tags.
For ZATCA invoices, as is the case with Ticketbai, the previous hash is needed
for the next invoice and is stored per journal. (so we have a chain of hashes)
Tests written by Simon (smdc)
closesodoo/odoo#126353
X-original-commit: caf6b0f2e09e7175221894cbb6d22bd6306c4e53
Signed-off-by: Josse Colpaert <jco@odoo.com>
For SA, we need to be able to filter on the taxes exported, as
certain taxes should simply not be reported in the UBL.
X-original-commit: 6019e809b4eedfd5ba56e5f8b39ac4e830131390
Part-of: odoo/odoo#126353
+ to VAT Taxes to comply with ZATCA and provide a better demo VAT number
X-original-commit: 03a0179dbbcda153f5212d104a9550568ed5d222
Part-of: odoo/odoo#126353
How to reproduce the bug
========================
1.Open the register page of an event
2.Do not pick any ticket
3.Click Register
=> an traceback is raised
Technical
=========
'?.length > 0' statement was checking the length of the array instead of the
values of the array.
This issue comes after this https://github.com/odoo/odoo/pull/120437
After this commit:
==================
Now the traceback will not raise.
Task-3329432
closesodoo/odoo#126352
X-original-commit: 1c47606cf1cd56c4d0980c7419c508e37c90f58f
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
-------------------
- create a stage without selecting a project.
Issue:
------
The new stage is inaccessible.
Cause:
------
When the project is not defined, the following ORM command is used:
`[6, False, []]` for the `project_ids` field.
Solution:
---------
When we create a project stage (project task type),
it is essential that we link it to a project.
Add the possibility to override `_get_default_project_ids`.
Set default project as first fsm project if not project in
the context.
opw-3322992
closesodoo/odoo#126338
X-original-commit: 69c09684e37accdaf1248f31a7c97f0c20434b76
Related: odoo/enterprise#43134
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
It was possible to create inconstancies in accounting entries by forcing to sum apples and pears.
Steps to reproduce
1. create a journal entry using at least one account with a secondary currency set
2. balance and save that move
3. change the secondary currency on the line and force it to a different value than the one on the account
4. save. You'd expect an error pop up but the constraint doesn't trigger and you're allowed to save/post
opw-3340697
closesodoo/odoo#126336
X-original-commit: e6581f39ec5d550db924aa7a86dd12f511f87958
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Go to Accounting > Vendors > Vendors > Accounting tab > Add a new bank account
- Enter a bank Account Number
- Toggle Send Money
- A validation error is thrown
This is because the widget `boolean_toggle` triggers a save
at each change of value by default, so it needs to be desactivated.
opw-3306639
closesodoo/odoo#126333
X-original-commit: 1717a3ee9d2455eaa61010765be08707a491c93f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
With [1] and [2], the colorpicker / colorpalette were implemented. In
both cases, for the custom colors hue / saturation / lightness selection
we listened to mousemove/mouseup events on the whole body / document.
That is to be able to start dragging the color cursors from inside the
colorpicker to anywhere on the screen (the cursor being confined into
their own box of course).
Problems occur when iframes come into the equation. Indeed, from that
moment, listening to mousemove events on an unique document is not the
way to go as mousemove over inner iframes will be ignored. This should
not be the case anywhere in 15.0 (that this original commit targets).
The only iframe there should be the mass_mailing one and in that case,
the colorpicker is inside the iframe so it should not be a problem.
However, [3] (then fixed by [4]) were meant to tackle a similar problem
(although [3] seems to say the goal was to ignore mousemove outside the
iframe which is the opposite of what this current commit tries to do:
listening on the whole screen). However, by doing so, a memory leak was
created as the document on which the events were bound was not properly
cleaned as the `destroy` which unbinds the events was not adapted. That
is the main reason why this commit targets 15.0 (although, the solution
here still makes sense generically in 15.0 and should make the code
simpler and easier to understand).
In 16.0, however, the iframe situation is a problem: the website builder
colorpickers are now in the main document but the edited content is
inside an inner iframe. In that case, listening to the main document's
mousemove/mouseup events makes the colorpicker only work when not
hovering the edited content (which could be acceptable but not perfect).
Note that during that website builder refactoring, [5] worsened the code
of [3] and [4] to do exactly that. Later, [6] was made to solve an
unrelated problem and actually woke up that worsened code, not
understanding what the new undocumented `ownerDocument` option was for
(it will stay like this in stable from now on, as it will be not used
anywhere anymore... hopefully). Because of that, the situation became
the opposite: dragging inside the colorpicker did not work until the
edited content was hovered. And because of that functional fact, an even
more visible problem was created:
- Click on a snippet
- Select a custom background color using the hsl selection
- Hover a non custom color (like nearly always the case "by mistake"
after configuring a custom color, your mouse just moves over the non
custom colors) => your custom color is lost
This was because the chain of events that were listened inside the
colorpicker were gone (because of the combination of [5] and [6]). In
the end, this only revealed the shortcomings of the implementation in
[1], [2], [3] and [4]: we should not try to search which frame we have
to listen to: we should listen to the whole screen. This commit solves
the issue by listening to the top window document and all its inner
iframes, also fixing the memory leak mentioned earlier.
task-3332711
[1]: https://github.com/odoo/odoo/commit/29f0c0a186a9a60d6e5b7f026c305d689b6fc807
[2]: https://github.com/odoo/odoo/commit/99910b526ed792235a778863b993d10cf4e77cd7
[3]: https://github.com/odoo/odoo/commit/4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
[4]: https://github.com/odoo/odoo/commit/f1b26335a286a47f685b7830db97c21e6fefd68b
[5]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[6]: https://github.com/odoo/odoo/commit/418c1178301e28b4bd1412da6d0558e219060830closesodoo/odoo#126313
X-original-commit: e03158e6da45d83c977b7cf51f0f998343dc6fd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It is more conventional to bind extra events in the `start` of widgets
instead of in their `init`. Indeed, the handlers often make sense only
if the widget is already in the DOM.
Related to task-3332711
Part-of: odoo/odoo#126313
This PR fixes some issues present in the livechat demo data:
- anonymous name should be given to the channel, and should be the
name of the visitor not the one of the channel.
- odoobot should not be a member of the channel (done by default
when creating a channel but making those channels that are supposed
to be one-to-one channels a group channel)
At the same time, this PR fixes an issue with the thread model that
contained clear commands instead of null value.
part of task-3332872
closesodoo/odoo#126219
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This PR adds the possibility to go the oldest unread livechat
thread when pressing tab on an empty composer.
part of task-3332872
closesodoo/odoo#125922
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Before this commit:
The font-family style of buttons and links could not be changed.
After this commit:
The fonts of a buttons and links can be changed.
Task - 2841732
closesodoo/odoo#121926
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In order to add the l10n_cl_edi_pos module we had to adapt some
things in the PoS module. This task changed the error handling of errors
sent to the server from the payment_screen. This led to some changes in
payment_screen.js and partner_editor.xml. It also add the mechanism
of not allowing an single order to combine refund and normal sale
in some localization if needed (needed for Chili).
closesodoo/odoo#121151
Related: odoo/enterprise#40940
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Issue: In the project task's chatter message, the demo data was used to
create messages such as comments and stage changes, which included a specified
date but 'Task Created' message has current date instead of its creation date.
Cause: The notification for 'Task created' includes the current date because
it was not generated by demo data. This has led to a conflict with the dates of
other messages that were generated using the demo.
Fix: The 'write' method is called on all 'Task Created' messages,
resetting their data to the 'create_date' of the tasks.
task-3289941
closesodoo/odoo#120636
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: point_of_sale, pos_self_order
Changes:
- Adds a default restaurant with some default usual settings (with tips after payment if the company is in the United States) but no floor in the Point of Sale app. Makes pos_restaurant module auto installed with point_of_sale.
- Makes some restaurant settings enabled by default (only for restaurants).
- Adds loadable default demonstration data for onboarding (only when no real product is available in POS), specific to a restaurant. The default demonstration data for onboarding of point_of_sale and pos_restaurant are loaded together (if pos_restaurant is installed) to make it so an user that clicks to add demo data will have demo data for the default point of sale and also for the default restaurant (and the current restaurant if it is different than the default one). Makes the load demonstration data button visible when there is no product with a positive price available, because without that condition the tips (in restaurant) and discount were preventing the display of the button.
- Hides the Preparation Printers menu item if there is no POS config using the printers.
- Renames some labels.
Fixes:
- Adds checks to always set set_tip_after_payment to False if a point of sale is no longer a restaurant or if the tips are disabled. This is needed because the code of pos_restaurant seems to be written considering that set_tip_after_payment is True only when the point of sale is a restaurant with the tips enabled (which wasn't guaranteed). Without that checks, some tests like ReceiptScreenTour fail. Another solution to make the tests successful without that checks would be to add !this.env.pos.config.module_pos_restaurant in pos_restaurant/static/src/js/Screens/PaymentScreen.js:16. But because other parts of the code only check the value of set_tip_after_payment, I think it is better to opt for the additionnal checks.
- Fixes duplication of displayed product categories when loading demonstration data.
- Fixes products before loading demonstration data that were kept and displayed after (discount for example).
- Fixes categories and therefore communication with the preparation display after loading demo data in a restaurant.
- Adds a check on the server side to prevent demonstration data loading when there is at least one valid product for POS.
- Fixes order count display when "NaN" (in floors and tables view).
- Fixes arguments of orm call for set_not_tip (model and method names were not given in the right order).
closesodoo/odoo#117941
Task-id: 2484291
Related: odoo/enterprise#39450
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
mail
----------
Improve the _get_link_preview_from_url method to:
- Only load necessary data (only the <head> instead of
the whole page).
- Handle optional request session.
- Handle all image mimetypes.
- Add a fallback on the <title> tag when no og:title have
been found.
link_tracker
-----------------
Prevent duplicated code by changing the url
title retrieving method to use the existing one
from mail.
As the title retrieving method is now limited to
the \<head> of the html, remove the unnecessary
check on the content max size which was previously
added to prevent memory limit from exceeding
when the html content was too big.
Task-3234864
closesodoo/odoo#122087
Related: odoo/enterprise#38882
Related: odoo/upgrade#4691
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Prevent duplicated code by changing the url
title retrieving method to use the existing one
from mail.
As the title retrieving method is now limited to
the <head> of the html, remove the unnecessary
check on the content max size which was previously
added to prevent memory limit from exceeding
when the html content was too big.
Task-3234864
Part-of: odoo/odoo#122087
Improve the _get_link_preview_from_url method to:
- Only load necessary data (only the <head> instead of
the whole page).
- Handle optional request session.
- Handle all image mimetypes.
- Add a fallback on the <title> tag when no og:title have
been found.
Moving the method out of the model to facilitate
its use as a tool.
Task-3234864
Part-of: odoo/odoo#122087
French tax reports require that each line is rounded to the nearest euro.
This requires that a line is added to the closing entries to account for the
differences from rounding. The line requires a couple of default
accounts for the profit/loss from rounding to be applied.
These accounts for profit/loss are by default 758000/658000 and are inherited in the
chart of accounts for l10n_fr (you will only need them if you're doing
french tax reports). The fields are also added to res_company for
l10n_fr, non french companies can still file french tax reports, so if
they are filing french tax reports without these accounts then they'll
need to specify them in settings
This commit also adapts the subformula of the carryover line on the tax
report to round the final value, this means that a rounded value will
persist between periods.
task-2610752
closesodoo/odoo#75634
Related: odoo/enterprise#20245
Signed-off-by: Josse Colpaert <jco@odoo.com>
Mathieu Walravens