+ 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>
Steps:
- Install studio.
- Open studio.
- Click on reset default view.
Issue:
- Confirmation dialog body display in single line instead in
multiple lines same thing happens in pos confirmation dialog
also in new friendly message task we need to display error
message in multiple line.
Cause:
- There is a style missing on body of that dialog to preserve
white spaces also need to use other tag then <t> to apply
proper style
Fix:
- Use <p> tag instead <t> tag and add a `text-prewrap` class
in bootstrap utility class and use this class in `<p>` to
preserve space.
task-3356114
closesodoo/odoo#125300
X-original-commit: 700d41d2f007124390b7cafca0a2e58a467e2b43
Related: odoo/enterprise#42842
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Website configurator 'website/configurator/4', Pages and Features description
takes up more than one line owing to the larger 'font-size' of the h4 class.
With this PR, use heading size `small` instead of `h4` so that description
remains in a single line.
task-3326543
closesodoo/odoo#121743
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Added few basic rules and folders that are usually common to most localizations.
The template will also serve as documentation on naming conventions (not strict atm).
closesodoo/odoo#121446
Usage: ./odoo_bin scaffold -t l10n_payroll name-code (e.g. estonia-ee) [destination]
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In the start_sync method, the logger is updated to use the 'warning' level
instead of the 'error' level. This change reflects a less severe logging level
for cases where sending a partner to sync fails.
The changes have been made to reduce the noise level in the sentry.
sentry-3955309841
closesodoo/odoo#126111
X-original-commit: c1b608c2d28962ed0ccbf15e9eeb2ecf5281b758
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
After this commit, underscore library is totally removed.
Library calls has been removed from manifests.
Library files has been deleted.
This commit closed the task below.
task-3246238
closesodoo/odoo#125889
Related: odoo/design-themes#662
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, some specific cases
in the leave creation would lead to an error due to an assert.
This commit replaces that assert with a 'if' statement returning the initial
date_to if the requirements are not met. A more thorough description of the
conditions is set as commentary of the `_get_fr_date_to` method.
task-3344770
closesodoo/odoo#126304
X-original-commit: d5642b088b37614e733b717989c12f9930b6e4ee
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current behavior:
When using the QRCode on ticket to create an invoice, it was always
creating a new partner, even if a partner was already set on the order.
Steps to reproduce:
- Activate the QRCode on receipt feature
- Create a PoS order and create a new customer for it
- Pay the order and print the receipt
- Scan the QRCode on the receipt to create an invoice
- On the new window enter the customer informations and see the invoice
- Now go check the customers list in the backend, you will see 2
customers have been created.
opw-3275938
closesodoo/odoo#126303
X-original-commit: 0a867a4e53d97da707b14062e0abafc18a1c827c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Current behavior:
When scanning the barcode of a product that is not saleable, the product
was added to the order.
Steps to reproduce:
- Create a product that is not saleable and not available in PoS
- Set a barcode for this product
- Open the PoS, and scan the barcode of the product
- The product is added to the order even if it is not saleable
opw-3325238
closesodoo/odoo#126293
X-original-commit: 3a3997e22b6a21c66455718a117c7c424526745e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
The purpose of this commit is to improve the design of the Property field
modal as it was done to release something fast.
We also introduce a modification of the JS test related to the property
header. Before this commit, the structure of the modal was composed
of a header and a body.
Since we refactored the component in one single block with the class
`.o_modal_container`, we apply the `.o_field_property_definition_header`
class directly on the input rather than targeting an input inside the
header.
task-3084756
closesodoo/odoo#126274
X-original-commit: 12a25449d9f26aec5f14482952ca0db40bf612b9
Related: odoo/enterprise#43091
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When a user creates a link that is tracked, an interface with graphs is
presented to him so that he can track the performance of his tracked
link. Unfortunately, these graphs did not work when the site was in a
foreign language. This was due to the fact that the code had not been
designed to handle this. This commit fixes the code so that it works in
all languages.
Note that the data is received via RPC and the python code format the
dates for the current language of the website. So we had to do a little
hack to make it work properly.
Steps to reproduce the issue:
- Install website_links module
- Go to the website app
- Click on Promote > Link Tracker
- Create a tracked link
- Visit the link
- Install Arabic (Syria) for your website
- Check the stats of your link in Arabic
=> There is a traceback and the data is not displayed.
task-3289167
closesodoo/odoo#126273
X-original-commit: e690da6ed1493e1def47cca6ef61e01ca8fa885f
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Add local date and time at the end of the printed in/out cash ticket
closesodoo/odoo#126247
X-original-commit: bf56255b1b334047a12f7469f7a1fafeb2787b66
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue:
1) Install the timesheet module.
2) Update the encoding method in the timesheet settings to use 'days' instead.
3) Navigate to the project task section and observe that the allocated days
field incorrectly displays the unit of measure as hours instead of days.
Cause:
The planned_hours field in the project task form view contains a float_time
widget that does not convert the UOM when switching to the Days encoding method.
Fix:
Using the timesheet_uom_no_toggle widget resolves the issue by changing the
updated value. To minimize the extra space generated by using the
timesheet_uom_no_toggle widget, the o_field_float_time class is employed.
task-3318851
closesodoo/odoo#126211
X-original-commit: 93d6f475d4cca35e4d4c41e9dedce3001d50f72d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit if we archive project's task then 'archive' ribbon and state
button were getting overlapped.
steps:
-> go to the project and open any project and then open any task
-> click on archive and see that archive ribbon and state button get overlapped
Fix:
-> checked condition if record is archived or not
-> if record is archived then first apply the justify content start of div which
contains state button and then changed width of state for different screen
sizes.
-> if record is not archive then leave the state button as it is.
task-3374980
closesodoo/odoo#126208
X-original-commit: 8400dc4bbc40b157736972fedd28d48907396611
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When '_seek_for_lines' returns multiple suspense_line for
transaction_amount calculation, then the user will face this
issue 'Expected singleton: account.move.line(516, 517)'.
Steps to reproduce:
- Create a new transaction in Journal (Bank) by Accounting Journal
> Bank Reconcilation > Add a Transaction.
- While creating a transaction add a partner, amount (amount > 0),
Foreign Currency, Amount in currency and then save it.
- Go to Journal Entries by Accounting > Journal Entries
and then open your recently created journal entry.
- Click on reset to draft and then in 'Journal Items'
add a line with some credit amount such that total credit and debit should be
equal. (Under Account it should be Bank Suspense Account).
- Now click on 'Bank Transaction' button in the form view.
By following above steps you will be able to reproduce the error.
Applying the changes will resolve the issue.
sentry-4217912848
closesodoo/odoo#126284
X-original-commit: 12a75a8521f8150c382645215c440d39af4b50aa
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Revision odoo/odoo@cabb9e7e57 introduced a
regression: This is no longer possible to import a data module
using `<field file="..."/>` in their data file.
This revision targets to restore the feature as expected.
The unit tests added covers the feature, so that regression
no longer happens in the future.
It introduces a new concept of temporary directory `file_open`
can read from.
e.g.
```py
with odoo.tools.file_open_temporary_directory(self.env) as module_dir:
with zipfile.ZipFile('foo.zip', "r") as z:
z.extract('foo/__manifest__.py', module_dir)
with odoo.tools.file_open('foo/__manifest__.py', env=self.env) as f:
manifest = f.read()
```
Note that `file_open` will be allowed to read from that temporary
directory only if `env` is passed to `file_open`,
and if the `env` is part of the same transaction/request than the `env`
passed to `file_open_temporary_directory`.
This is to avoid having users, whether from other databases,
or even the same database,
trying to access these directories not belonging to them.
e.g. If an admin uploads sensitive data in this temporary directory,
no one than him must be allowed to read from these files, not even
another user from his database.
closesodoo/odoo#126326
X-original-commit: ea5cfe2e9493e4ef5a9b81851af452c8c51e407e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
- Install the lux localization
- Configure Peppol for a customer: Select a customer > tab accounting > under "electronic invoicing":
format: Peppol BIS Billing 3.0
Peppol e-address: 0130 - Directorates of the European Commission
Peppol Endpont: testendpoint
- Create an invoice for the peppol customer
- Add a section or a note in the Invoice
- Confirm the Invoice
Issue:
Raise user error: Odoo requires a tax for EACH LINE, instead of each product
Solution:
Exclude the section/note line
opw-3354757
closesodoo/odoo#126312
X-original-commit: fb716296dbdb4921d26ebe1c3a420965f07d61e4
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Some account terms are mistranslated, this PR aims to fix these translations. The customer provided a table with the mistakes and suggestions. The customer’s suggestions are available in the ticket.
How to reproduce:
1. Ukrainian translation > chart of accounts > some terms are mistranslated
closesodoo/odoo#126294
Opw: 3247005
X-original-commit: 95ae2afd3bd5b2a2df62e6e33eeb03066d1d8276
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
To reproduce (V16):
0. Install Accounting (can also be reproduced with just Invoicing, but
there is no "journal item" menu that will ease the process to show the
issue)
1. (In debug), change the dollar currency rounding to 0.0001
(instead of 0.01)
2. Go to Accounting > Customers > Invoices
3. Create a first invoice with:
- a partner P1
- set an invoice date
- make sure that there is a payment term set (for example "30 days")
- at least one invoiced line (the product does not matter) with the
tax 15 % and the price to 12.36
DO NOT confirm the invoice
4. Create another invoice with
- ANOTHER partner P2
- set an invoice date
- make sure that there is a payment term set (for example "30 days")
- at least one invoiced line (the product and the price does not
matter)
5. Go back to the Invoices list view and select the 2 new (unposted)
invoices then Action > Post entries.
6. Check Force and "Post Journal Entries"
7. Go to Accounting > Reporting > Journal Items
8. Group by "Journal Entry" and unfold the 2 last invoices (that should
be the one validated in 6.)
=> The "Partner" set on the Debit Line is the one of the other invoice
(and vice versa)
Analyse:
This issue is a mix of different sub-issues. Solving any of this
sub-issue would solve the issue but as other sub-issues may exists we
will fix each of them individually.
Sub-issue 1:
The account.move.line (=AML) partner is set correctly before the post
(6.), this is during the "mass posting" process that the issue happens.
The partner is changed because of this line:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096
The value written to AML of id `line_id` include `move_id` which
overwrite the account.move that was originally set on the AML.
As the `partner` is computed only in certain circumstances, if the
`move_id` written differ from the one of the AML, most of the values
will be updated with the write values, but the `partner_id` will keep
its value (this is why the swap of partner happen).
In other words, this issue happen as `line_id.move_id` order is
different from `key["move_id"]`. So we write on the "wrong" AML.
Sub-issue 2:
In theory, this issue should not have happened in the first place.
The line:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061
should have prevent the re-edition of the AML (as actually no relevant
datas are written). But the equality between the dictionaries fail due to some rounding errors.
Here:
- needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002
- needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999
N.B: if we don't set an "invoice date" on the invoice, a rewrite is
done before which would prevent our issue to reproduce.
Sub-issue 3:
If we try to reproduce the issue without setting a "payment term", the
issue would not reproduce.
By setting a "payment term" the `to_delete` computation change at:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067
This happens as the `existing_before` keys and `needed_after` keys are
different:
- existing_before[<key Invoice 1>]["discount_date"] -> False
- needed_after[<key Invoice 1>]["discount_date"] ----> None
As the values are different, Odoo all the AML to the `to_delete` which
then trigger their overwrite.
In other words, if no "payment terms" were set on the invoices, the
issue would not happen either
opw-3270471,3292931,3333799
closesodoo/odoo#126272
X-original-commit: 074964b6c91d223da0b416855a92e9ed8a17ee55
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
Duplicating the contact that is linked to an attendee of a course also
creates a copy of an attendee as well.
After this commit:
It does not create duplicate attendee in course.
Task-3253983
closesodoo/odoo#126244
X-original-commit: 4af091bd62243db243555d46b97cc7af49ceeeb1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Mayur Raj Sinh Rathod (mrsr) <mrsr@odoo.com>
Lucas Lefèvre (lul)