Before this commit, the field to generate serial numbers in the
detailed operation move view wasn't displayed.
closesodoo/odoo#37197
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of the commit is to adapt demo data for the maps view
as we currently have a cluster of pins, which doesn't showcase the feature.
So updated the address of the main partners.
Task-2041896
closes odoo/odoo#36179
Closes: #36179
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
We should avoid showing the title in edit mode as it doesn't get updated
automatically.
closesodoo/odoo#37193
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
With the actual code, some computations are done
in the graph renderer to determine if it is worth
to show the "Stacked" button in the graph view control
panel for the data on hand. It turns out that that
problem is not satisfactorily addressed and is quite
hard from a usability perspective. We prefer to restore
the old behavior as long as we don't have better ideas.
closesodoo/odoo#37188
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The message for the validity of the leave type was not clear enough,
this commit makes it clearer.
closesodoo/odoo#37191
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In time off dashbord, due to python precision computation we can
have amount of days like 9.9999998. This commit make a rounding
after 2 digits and doesn't add new 0 at the end.
For example:
3 -> 3
3.1 -> 3.1
3.14 -> 3.14
3.141 -> 3.14
closesodoo/odoo#37182
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
SHA-1 is a cryptographic hash function that have weaknesses known since
2005, it has been deprecated by the NIST [1] about 10 years ago in 2011
and Google [2] have been able to perform a collision attack in 2017.
We use SHA-1 as filename for the attachments stored in our filestore.
Although practical attacks still requires quite a lot of computational
resources, it is time to prevent SHA-1 collisions on our filestore.
To prevent such attacks, when uploading a file that has the same SHA-1
as a stored file, we perform a SHA-2 computation on both files to verify
their signature. If their SHA-2 signature is different, an error is
raised.
We have selected the SHA-512 variant of the SHA-2 algorithm because on
64 bits platform, SHA-512 is the fastest SHA-2 variant, it is only ~1.5x
slower than SHA-1. [3]
We have not used SHA-3 because at the moment of writing, it is too slow
(~3x slower than SHA-1) [3] and it is not guaranteed to be available
with the Python 3.5 `hashlib` module.
[1]: https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions
[2]: https://shattered.io/
[3]: http://bench.cr.yp.to/results-hash.html
[4]: http://www.commitstrip.com/en/2017/02/27/the-sha-1-alternative/closesodoo/odoo#36430
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Currently in the slide.question view it is possible to open a form
to create new questions for quizzes, but it is impossible to fill the form with
the required information to create a new question. So the create button has no purpose.
This as "slide_id" is required but can't be set in the form.
Now the option to add question from the reporting tab 'Quizzes'
is removed as the questions (with the answers) are added in the form from
slide.slide.
closesodoo/odoo#37117
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The onchange on tax_ids and second_tax_ids was only recomputed when
tax_ids changes (duh) so the variables show_force_tax_included and
show_second_force_tax_included were not set when coming back to the
formm after having saved a line with one tax.
closesodoo/odoo#37111
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Suppose an invoice in EUR with a company using USD.
- Try to create an invoice with some lines, remove the value of the journal_id field.
=> Traceback because line.company_id.currency_id is an empty recordset on which you can't
call the 'round' method.
- In the list views of the invoices, the price must be shown in the company currency.
- When registering the payment if you change the currency in USD the conversion is wrong.
closesodoo/odoo#37050
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
After submitting the quiz, buttons and validation content was rendering on top
of the quiz instead of under it. This display bug is fixed in this commit.
Task-2072564
closesodoo/odoo#37040
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In some cases, after installing a new language in rte_translator tour,
some query using ir_translation table will become very slow.
Identified query:
SELECT res_groups_users_rel.uid, res_groups_users_rel.gid
FROM res_groups_users_rel, "res_groups" LEFT JOIN "ir_translation" as "res_groups__name"
ON ("res_groups"."id" = "res_groups__name"."res_id"
AND "res_groups__name"."type" = 'model'
AND "res_groups__name"."name" = 'res.groups,name'
AND "res_groups__name"."lang" = 'en_US'
AND "res_groups__name"."value" ! '')
WHERE 1=1 AND res_groups_users_rel.uid IN (2) AND res_groups_users_rel.gid = res_groups.id
ORDER BY COALESE("res_groups__name"."value", "res_groups"."name") OFFSET 0´
During post_install this query will become slower (between 0.7 and 2 seconds) ~50%
of the time, when this usually take less than 0.1 second.
For some tour step, this query is executed several times, making a simple
/web loading going from less than one second to more than 10 second, breaking the tour.
The main intuition behind that would be that the query plan completely fails,
mainly because postgress is to busy and doesn't have time to launch an analyse
when runbot load is high.
This commit proposes to execute a manual ANALYZE on ir_translation table
after a new language is installed. Tested with 40 builds, rte_translator never failed
with this fix.
cherry-pick of fc5934dc45closesodoo/odoo#37013
X-original-commit: 57f91453cb567d8a7a29137b321a630fe0dbb9a6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Be in company C1. Create the invoice I for a SO in company C2.
The invoice is created on the default account.journal for C1.
This happens when e.g. C2 is a child company of C1.
Then I is accessible from C1, but not from C2
as reading the journal violates the multi-company record rules.
Note that if company_id == False, then
self.env['account.invoice'].with_context(company_id=company_id)
.default_get(['journal_id'])['journal_id']
returns False, and in that case, it would raise below.
To keep with the existing behaviour, we put a fallback on
self.env.user.company_id.id
which means that the values we pass are:
'company_id': False, 'journal_id': J for some J in company C
which is flaky, but won't trigger any extra errors.
opw 2068291
closesodoo/odoo#37002
X-original-commit: 427280d9760a71e6ca2961bcf4a2f9f157e6dddd
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Fixed the button allowing to reset to the logo colors in the
document layout configurator.
Before this commit, the custom_colors boolean asserting that
the colors used by the layout are different than the ones computed
from the logo and used to revert to those colors was in readonly
and couldn't be toggled.
Now, the boolean is editable and allows to revert the colors properly.
Task 2072557
closesodoo/odoo#36968
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Remove the "sale.group_sale_order_dates" group and settings, all the date
fields are always displayed but we put schedule_date and commitment_date
(for which the label was renamed "delivery date") on the same line (with
a design to make the schedule date looks like a suggestion for the
delivery date).
task 2057802
closesodoo/odoo#37174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This "bugprovement" resolve the old issue of writing on a translatable
field a falsy value.
Before this commit, only the translation value was removed. When no
translation is present (or when the value is not set), the value is
retrieved directly from the source field.
Before 18d9c2cab2, it was still possible to go around this issue by
removing manually all ir.translation entries and writing with a user
in en_US.
This is no longer possible as writing on a translatable field always
uses translations when in multi-language environment, without
exception of en_US.
When writing a falsy value on a field, the expected behaviour is to
reset the value and see that falsy value after saving, not the old
value stored on the source model.
Remove all translations and force to update the column.
Removing one individual translation is still possible in the
translation popup.
Task id: 2062415
closesodoo/odoo#37077
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If it isn't set manually, it defaults to now and the result is not
consistent with planned date end. We make it an hour before totally
subjectively.
closesodoo/odoo#37173
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Let's consider that warehouse A resupplies from warehouse B
- A has Outgoing Shipments in one step
- B has Outgoing Shipments in two steps
- Change Outgoing Shipments of B in one step
Bug: An integrity error was raised because route_id field is required
on model 'stock.rule'
PS Inspired from function create_resupply_routes
opw:2069163
closesodoo/odoo#36991
X-original-commit: 2a87b56efab1246fa85c1b507322e0909db3dd20
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Some operations call the WizardMultiChartsAccounts.existing_accounting
(file chart_template.py), such as going to the settings of the Accounting app.
This function tests whether any lines are present in several tables related
to accouting.
Before this commit:
a search is performed throughout the tables and takes forever for a large db.
Partner reports: "with current code, a customer with 12M account move lines
gets an out of memory error after the screen has sat for 10 minutes - this is
because the code is doing a read on every row in the account move line just to
see if the user company has a record".
After this commit:
with limit=1, the search stops after only one line is found in any table.
closesodoo/odoo#36975
Opw: 2066938
X-original-commit: 80563819ae93c00d171935f1d1cded33de15ba21
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before that, when using a small screen (with width <= 768 px) and
showing the accounting dashboard of a company without any chart of
accounts installed, the icon and message prompting to install a chart of
accounts was displayed in the lower left corner, instead of being
horizontally centered.
closesodoo/odoo#36974
X-original-commit: 4999f47d7e283c6a5799e68f2b0e1351638e17a3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
-Create a random journal entry affecting the partner A, using a receivable/payable account.
-Let the journal entry in draft.
=> The amount set on the line must not be sum in the partner's amount_due.
closesodoo/odoo#36973
X-original-commit: 3ab4589ff444da9889ac922ac9d7ba6c8e8638bc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Following 40487aca5c there was an issue
where a delivery could be splitted because of mrp specific code.
This test checks that when creating a sale order including a level 3
bom (MTO) the delivery is one, containing the correct products
closesodoo/odoo#36961
X-original-commit: c07ecea7923c1609c4461fadbc61040e9fd3d86a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On the pivot view, there is the following unsigned measure fields:
"account_tax" and "account_untaxed".
It can cause mistakes since for example the sum of a invoice an its
full credit note should be zero, but here it will be double the amount.
So here we complete 97aec9f8 for two fields that were still available.
opw-2071027
closes#36940closesodoo/odoo#36971
X-original-commit: 2dc8e2feec9e5b604e0c0acae52562822a113342
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The progress bar was pretty broken before this commit.
> It was not possible to input the value as text
> Moving the progress bar to modify value and saving crashed
> modifying the max value crashed
> The whole feature was ill-defined
With this commit, we fix the crashed. It is now possible to write the field
behind the progress bar by moving it in RO mode
or by typing the input in RW mode
*if it is the value we want to write on*
It it is the max value that the field targets, we can do it in RO and RW mode,
only with the input as text
Note that this works *only if* the editable option on the widget is set to true
OPW 2061846
closesodoo/odoo#36928closesodoo/odoo#36970
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In case you have a button of type action, the controller is doing an rpc
on the model using the right method, but in this rpc, the context is not
passed.
This creates a translation problem (nothing is translated) since the
language is not defined in the context.
Task Id 2062419
Closes#36189closesodoo/odoo#36969
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There is no need to redefine `_get_stripe_api_url` by adding `https`
since all existing calls to the method programmatically add it already.
Therefore, we use the same approach: we add `https://`, then join the
URL.
opw-2031745
closesodoo/odoo#36957
X-original-commit: 0412786486462423c91afc1c5a4dcb25886827e4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Log an error only if a transaction exists.
opw-2071862
closesodoo/odoo#36946
X-original-commit: 903bd53d5f11dc9a9cfea246e6c5c0a088ad02ba
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Change the date format of your current lang
- Reconcile a statement
Bug:
The maturity date displayed in the widget didn't use the format of your
current lang.
opw:2068241
closesodoo/odoo#36944
X-original-commit: d2ad3d6542bfe1c900720148f22abe4b507e2a41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
before this commit: it gives error when we redirect to payumoney site
after this commit: payment testing in payumoney is working as expected
closesodoo/odoo#36937
X-original-commit: 97c0ece7857ca56b1fd20d3772262def5aeebdc4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reverts d91b1e5bd5
But still handles the use case (cancelling transfer payment)
Make a payment, confirm it
The payment's move has a name, i.e. constructed from its sequence
Cancel it
the payment has no move anymore
Re-confirm the payment
Before this commit, the new move had a new name from a new sequence number
This is problematic to ensure accounting consistency
Besides, it was not the way it works for invoices' moves
After this commit, the former name of the move is taken
to build the new move of the re-confirmed payment
OPW 2046412
OPW 2070167
closesodoo/odoo#36868closesodoo/odoo#36922
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When processing a payment in Ecommerce, if the payment
acquirer communication is defined on 'Based on Document Reference'
and if the sale order sequence is having a suffix, we have
an internal error due to a bad implemented regexp.
opw-2067596
closes#36867closesodoo/odoo#36892
X-original-commit: b08a0025e7900554791a4e42bddcbeb09739a8a1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
In case no email address was specified on the delivery address stripe
redirect flow will fail, so we define a fallback on the billing partner
email.
closesodoo/odoo#36833closesodoo/odoo#36862
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* website
Following the new editor merge at https://github.com/odoo/odoo/pull/29775
(which was finally partially reverted for 13.0), the crop dialog was not
working anymore on sub-sequent crop. This was due to 2 things:
1) Re-cropping an image that was just cropped now
The original source of the recently cropped image is saved as temporary
jQuery data on the image element. Unfortunately, for some strange
reason, that image is cloned before any edition and thus lose that data.
This commit fixes the problem by cloning the data too... supposing the
orignal clone is there for a reason.
2) Re-cropping an image that was saved before
This did not work anymore simply because... the cropped images were not
saved in database anymore but saved as base64 data in the view... For
some reason, the cropped images to save were searched in the original
DOM instead of the edited DOM...
Also fixing the random use of a mutex.
Discovered while working on task-2059480
closesodoo/odoo#36878
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With the PSD2 directive coming into effect on September 14th,
was had no choice but to switch our Stripe integration to use
newer APIs that support Strong Customer Authentication (SCA for short).
This meant switching from the old stripe.js implementation for
'redirection' flow to the Stripe Checkout API and from the
Charge API to the newer SetupIntent & PaymentIntent APIs
for s2s flows.
This new modules introduce these changes in a non-intrusive way,
this means that installing this module is *not* required for
all customers (e.g. instances only accepting payment to and
from countries that are not part of the EU), that installing it
will support SCA flows and that uninstallation leaves you with
a working instance as well.
Task 2039100
closesodoo/odoo#36869
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
r-sierra