To prevent having holes between statements and for better usability using import and synchronization
we try to automatically set the starting and ending balance based on the previous existing
statement.
To do that, we added a new field previous_statement_id so that whenever we change the ending_balance
of the previous statement, we recompute the starting balance and ending balance of the current statement.
Also creating a new statement in between 2 others statements will automatically set the correct value
to the starting and ending balance of that statement and all the statements afterwards.
Exception: creating a statement by hand won't automatically set the balance_end_real, however if you
create one between 2 statements, the balance_end_real of next statements will be recomputed
Was Task #1880409closesodoo/odoo#38696
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
odoo/odoo#28519 removed large parts of pycompat, but left reraise
despite that not having much value.
Remove that helper and replace it by just a `raise` in most cases:
when raising from an except block, the old exception is automatically
chained to the new one, no need to mess around.
There is one exception: in http we have to re-raise an existing
exception explicitly (aka `raise exc` rather than just `raise).
This is less than ideal as Python *concatenates* stacks: the
previously reified stack (from the except clause) is stacked on top of
the new stack (from this raises), this leads to tracebacks "jumping
around" at the break point of the handler and is somewhat confusing.
So we want to use explicit chaining (`raise a from b`) with the
"source" providing the caught exception's original traceback and the
child providing the rest.
However since callers rely on the exception making sense, we need the
re-raised exception to be the original[0]. Copying the exception
doesn't work (see [0]), chaining an exception to itself doesn't
do anything useful, and while we could probably copy exceptions using
the pickle method[1] that's still risky.
So the most reliable option seems to be to create a new "cause"
exception, move the old traceback over to it, then re-raise the
original exception having cleared its traceback, chained to new the
cause.
[0] or a copy thereof but Odoo exceptions don't all work properly with
copy.copy and we don't want that to fail so not really an option,
we can't rely / bet on every new exception being cleanly copy-able
[1] create an "empty" instance using __new__ (or an instance of
something else onto which we re-set the __class__ in case the exctype
actually overrides __new__) then copy the __dict__
closesodoo/odoo#39709
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The unittest signature of `assertRaises` allows a named parameter
`msg`[1]. The message is displayed in case of assertion failure if
`assertRaises` is used as a context manager (but not when giving it a
callable).
The Odoo implementation did not implement this behavior, despite it
being expected by multiple odoo tests.
Fix Odoo version to be in line with the method we're overriding /
shadowing.
[1] https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaisesclosesodoo/odoo#36719
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Create an event
- Add a mail reminder for it
- Run the mail scheduler manually
- Duplicate the event
The mail reminder is sent on the duplicate too.
This commit remove the field `mail_sent` from duplicating.
OPW-2117343
closesodoo/odoo#39777
X-original-commit: 7fede2c0360f72410ac36f5d706ac5c7c18b7c7d
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
The 'delivered quantity' field sometime needs to trigger a search
on related objects (e.g. analytic lines) to know how much has been
delivered.
For performance reasons, this search is done using a read_group where
the results are grouped by SO line.
Unfortunately, this computation is sometimes launched during
recomputes/onchanges where the line in question has a NewId instead
of a regular id.
This means that the mapping will return something like
{240: 50.0}
indicating that (e.g.) there are 50 timesheet hours for the SO line
with id 240; unfortunately by doing
mapping.get(line.id, 0.0)
the NewId (240) is used - therefore returning a delivered quantity
of 0.0 for a line which has actual timesheets.
This commit ensures that if the line has a NewId and an original
underlying record, the id of the latter is used as the key to fetch
the value from the dict that contains the read_group result.
Note that the problem was quite tricky to reproduce as it depended
on the order of operations launched by triggers - the order of
operations was important since triggering the compute with the 'real'
record put things in order before any other piece of code could have
spotted the issue.
closesodoo/odoo#39781
X-original-commit: cf54606edb9130f2c5b351150f0e37b75f10ae66
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Business cases should not prevent the unlink of module-related records
during an uninstall.
This commit allows the reinstallation of sale_stock with demo data and
also allows the proper removal of tables and records if a db has any
non-draft inventory adjustments.
closesodoo/odoo#39776
X-original-commit: cedafe00941b869d284cd511633d7da15868fc0a
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
The extra informations not on the sale.order models were sent before
13.0 with the superuser user. In 13.0 with the change of `sudo` and
`with_user` behavior, we were now in superuser mode but not with the
superuser so the mail would error (no from address) and the sale order
would error.
With this changeset, we get back to the pre-13 behavior.
opw-2116346
closes#39730closesodoo/odoo#39748
X-original-commit: 7b1654a10f5a005677492ec71e6fa1e54df09ae2
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before 13.0 .sudo() before sending a mail would send it as superuser user
(which was the intention in this case), but since 13.0 for the same
intention we need .with_user(SUPERUSER_ID).
Without this change, the confirmation email on a sale order would have
no sender ending up in failure.
opw-2118612
closes#39737closesodoo/odoo#39752
X-original-commit: 6aebb5231c3ed0b87cdddcd9cb463952e346ec07
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this rev, it crashed when opening the (sale or purchase)
product matrix (e.g. on runbot, go to quotations, create, add a
line, select 'My Company tshirt').
This was due to a recent override of _applyChanges (see 4bf98b47),
which didn't return the value returned by super.
OPW 2116083
closesodoo/odoo#39747
X-original-commit: 49626acbacb87a6f5d37bea22d0b51a506121914
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of the commit is if sales order is very long, the down payment
gets lost in the middle of it and will be best to make it appear
systematically at the end of it.
currently the sales order line is order by the sequence and while
creating the down payment it takes the default sequence of the line
so adding sequence by +1 will show the down payment at the end.
task-2025709
closes odoo/odoo#34404
Closes: #34404
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
In the contacts app, you can select 2 partners and merge them.
Before this commit:
- If a partner was added by a SQL query and not directly on Odoo,
the create_date will be empty. This causes a crash because the
merge wizard try to sort the partners by date
After this commit:
- If a partner do not have a create_date, it will be considered
as 01/01/1970. The merge wizard will sort the partners by IDs too.
OPW-2091925
closesodoo/odoo#39523
X-original-commit: deeb769c0d579c51ab42b072ccc1c013d79fcea4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Prior to this commit: b234e97f87,
uninvoiced orders' state is set to 'done' when the session is validated.
However, this was not taken into consideration in the said commit such
that even if the session is already validated, the uninvoiced orders'
state remains 'paid'.
Setting the orders state to 'done' is the correct behavior and is
implemented in this commit.
closesodoo/odoo#39735
X-original-commit: bb490301c22c84c86d2b1c2d27ecb96a4ff19ac5
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
odoo/odoo#30688 (6ce2d6efb5) added an
indirection in prefork workers: Python-level signal handlers are
delayed until native calls have ended (e.g. accept() or
execute()). Running the actual work in a sub-thread allowed the main
thread to handle signals in all cases.
However there is apparently an issue with SIGXCPU on linux (possibly
other cases as well): SIGXCPU is delivered to the child thread (if
possible?) and Thread.join apparently stops it from redelivered to
the main thread (Thread.join is signal-interruptible since 3.2 but
possibly not Python-interruptible).
Blocking SIGXCPU on the child thread causes the OS to deliver on the
main thread and fixes the issue.
Also split set_limits so it sets the signal handler in the parent
thread but properly updates the soft limit in the child after each
request, as the goal is to put a hard limit on the CPU time per
request, not on the worker. 6ce2d6ef would set the limit once then
never update it, likely cycling workers more than desired.
While at it:
* block other signals with a handler set, they seem to work
regardless on linux but other OS may have a different way of
dispatching process-directed signals
* unset signals which are set by the prefork server but whose
set behavior makes no sense in workers:
- TERM and CHLD were already unset
- HUP is used to restart the server, workers can just be killed
- TTIN and TTOU configure the number of workers
closesodoo/odoo#39731
X-original-commit: 549bd199bad269e4e28efac933efac3f41495877
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make an invoice in Foreign
Make a refund in Foreign
reconcile the two, partially
Make a payment in domestic, partial also, but with writeoff
Before this commit,
The invoice was not fully reconciled and -0.02 was yet to pay on it
Notice the negativity of that number, which actually means that it HAS been
fully reconciled !!!! (there is too much payment compared to invoiced)
This was because, the account.payment in domestic currency is doing:
Invoice residual in foreign, converted to domestic
Then that amount minus payment's amount gives write off amount in domestic
Then, at reconciliation, the whole payment's amount, which is
the payment + the writeoff contained the expected and mathematically
correct conversion and currency rounding errors
(which should make out the exchange difference)
The exchange difference IS created, and rightfully too
that is, it records the exchange difference as debit 0.01 in the receivable !
What was tricky though, is that the partial line recorded the debit 0.01 receivable
as its CREDIT move line !
After this commit, the receivable line is recorded as the DEBIT move line of
the partial between the payment and the invoice
so the invoice, is fully paid.
We keenly admit this is hackish, but justified:
- business-wise: the rounding/exchange errors are appearing ex-post
to the choice of the amount of the reconciliation between the payment
and the invoice, because we are reconciling them on the domestic amount
- technically: our hands are tied because some key information is not present
every time, and weirdly, not symmetrically. That is, the computation of
line.amount_residual[currency] may be different if your are on a line with a currency,
or on a line that doesn't.
We should really think of systematically putting the currency on the line
whichever it is ! The same goes for partial reconciliation model !
Touching the current behavior is out of the question.
Moreover, we should take into account that comparing amounts at different
points in time should be done by actualizing those amounts to a common date
See #39117 for details
OPW 2057845
X-original-commit: 40db7a8
Note that the tests did not change in spirit, but the writing
of the exchange difference may vary from happened in v11.0
Indeed a quite big refactoring has been done in between
The tests reflect this
closesodoo/odoo#39727
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Usecase to reproduce:
- Set warehouse as 3 steps delivery
- On pack rule set the procure method as 'take from stock if enough or
trigger another rule'
- Do an inventory adjustement of a product and set 10 units in pack zone
- Do a delivery order for this product with only 1 unit.
It will create the delivery order from stock to pack even if the
quantity in pack was sufficient.
It's due to [1] that introduce a new function but if the force company
and location (with an integer) are both set in the domain it will
select the wrong ids. It will take all the location in the company + the
location in the context. However if a location is explicitly given to
the context, it should only consider the stock at this location.
[1] commit 330b99f60c
opw-2090384
closesodoo/odoo#39726
X-original-commit: e77d9fc735d845bbb0b5562c359fbf2354d72f0e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
before this commit, when try to make payment with
empty card details, it will raise error dialog.
after this commit, error will be append to acquirer
form
task - 2089999
closesodoo/odoo#39729
X-original-commit: 01b143b971a85d6da673df6c536917ad4754b83a
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider Today = 31/10/2019
- Create a new hr.leave.type LT and set a validity from 01/01/2020 to 31/12/2020
- Set mode = Free Allocation Request and Validation = No Validation
- Try to create leave allocations for LT
Bug:
It was impossible to create a leave allocation for LT because Today < 01/01/2020
So it was impossible to allocate future leave.
We had to wait the 01/01/2020 to make the allocation of LT leaves
So now, when no default_date_from is in the context, no domain is applied
opw:2092830
closesodoo/odoo#39715
X-original-commit: 6bc9e6920c23262e13398b1b88ea7cfd3b4f1e7d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider two storable products P1 and P2
- Update the cost of P2 to 10€
- Create a BOM for P1 with P2 as component
- Click on Bom Structure & Cost
- Click on P2
- Try to update the cost
Bug:
A traceback was raised saying that "Record does not exist or has been deleted" or the cost of an other
product was displayed because the active_id was still the id of the bom.
opw:2093199
closesodoo/odoo#39710
X-original-commit: e984d8f94534373fde894e9e6ad0c932585deb46
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
`is_false` relies on no small part on equality tests between the input
triplets and either `TRUE_LEAF` or `FALSE_LEAF`. While these are
defined as tuples, RPC domains will always be lists (as neither
XML-RPC nor JSON have tuples, and their arrays deserialize to Python
lists).
This is an issue, because tuple and list never compare equal. As a
result, while the in / not in predicates can succeed, the TRUE_LEAF /
FALSE_LEAF never will, and thus domains which contain either and might
shortcut (avoid a query entirely) will always go through the entire
process.
Fix by having domain normalization also ensure all triplets are
tuples: that's the first thing `is_false` does, it should never cause
issues and could fix / improve / shortcut other routines.
Note: Also implements TRUE_LEAF and FALSE_LEAF handling in the
SSF's modifiers evaluator. And fixes the ValueError to work
correctly if it breaks on a tuple / dict.
closesodoo/odoo#39706
X-original-commit: a44f008b918ee66742f7e943b00e4ee3d7fe2b78
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Activate Google Synchronization, create on GC a recurrent event,
synchronize OE, then delete an event of the recursion on GC, sync again
on OE.
The event will be deleted from GC but not from OE after sync.
The exclusion on OE is not correctly working in that particular case,
fixing require also to "suppress" the attendee to avoid that just
created exclusions would be detected as changes to send in a following
synchronization.
closesodoo/odoo#37884closesodoo/odoo#39510
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When user goes on product's quants, hides the "Removal Date" field if
the product doesn't use expiration dates.
Also, set it as optional to be hide if the user wants.
closesodoo/odoo#39425
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When importing an O2M value (sub-record), rather than raising an error
if the value has a xid set (foo_ids/id) and the xid does not exist in
the database, re-insert the xid as the "id" field of the sub-record,
then re-extract it at creation (the ORM will have ignored it) and
associate it with the newly created record.
Advantages:
* keeps o2m creation in the proper order during import (sub-records
remain created after the parent) meaning o2ms with a required parent
can take advantage of the feature
* avoids breaking batching when creating the objects
* no new command or smuggling through an existing command
closesodoo/odoo#35995
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Turns out almost no user of odoo.tools.osutil actually imports
it. Following odoo/odoo#39573
(355e360973) removing what were
apparently the only two users of the submodule properly importing it,
other calls to osutil features now blow up, which went unnoticed as
these calls are lazy (so don't prevent starting the server) and only
happen for very specific operations.
The smallest change there is to simply re-enable the old behaviour by
explicitly importing osutil from tools.__init__.
closesodoo/odoo#39705
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the values of these 3 fields in database may be
desynchronised with the one set in the cache by the ORM but not
commited yet.
Before this commit, when confirming an attendee, the count was not
correctly recomputed. '_compute_seats' was triggerd when changing the
state of the registration but the value of 'state' was still the one
before the confirmation, making the sum outdated.
Note that two constraints are raised when modifying the field state:
- _check_seats_limit
- _check_ticket_seats_limit
If _check_seats_limit is executed first, the bug does not occures
because it first triggers the '_compute_seats' method on event.event
model, which has a correct flush method.
If _check_ticket_seats_limit is executed first, the bug occures
because the '_compute_seats' of event.registration is triggered first,
which did not have the flush implemented.
Fixesodoo/odoo#38340closesodoo/odoo#39677
X-original-commit: 46b168139e6043f5b5d7cc81a2bec62ef346fcd0
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In form views, there are stat buttons.
When the window size is too small, some buttons are packed into
a "More" dropdown.
Before this commit:
- The form view dropdown's buttons are shifted on Microsoft Edge
and IE 11.
After this commit:
- The form view dropdown's buttons are not shifted anymore on
Microsoft Edge and IE 11.
There was a fixed line-height on the button's icon. On Edge and IE 11,
it makes the icon moving down and this causes the offsetting.
The purpose of the line-height was to fix the button height to 44 pixels
So, I set up the button's height and centered the content.
Also, I removed a useless border-left because there was already one
border on the dropdown container.
OPW-2079694
closesodoo/odoo#39635
X-original-commit: a7d9f2a5a94662602a34f7e68e5cd0c4cd07c7f3
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
In form views, when the window size is too small, a "More" button
appears and it should contain the overflow buttons.
On all browsers, the "More" dropdown doesn't contain the expected
amount of buttons, so it is shifted on the second line.
Before this commit:
- The "More" dropdown doesn't contain the expected amount of
buttons, so it is shifted on the second line.
After this commit:
- The "More" dropdown contains the expected amount of buttons
and it is not shifted on the second line anymore.
OPW-2079694
X-original-commit: 2bda8230fba07a229fcda77a1528694a0e317917
When testing the import of records, a flush should be done to check
all databases constraints and fields computations.
Moreover, in case an exception is raised within a savepoint,
the environment should be cleaned up, to avoid tricky bugs (see below).
We replace the manual handling of savepoints with the savepoint
context manager, which already handles all of this.
This code predates the context manager, so in a way it was archaic.
When testing the import of records, the following could happen:
"An unknown issue occurred during import (possibly lost connection,
data limit exceeded or memory limits exceeded)."
This would happen on project tasks; the fields 'working_hours_open',
'working_hours_close', 'working_days_open', 'working_days_close',
all depend on the computation of _compute_elapsed.
Because this is a test import, the records would raise a MissingError,
and fields_to_compute would always contain 3 of the fields.
The resulting is an infinite loop giving this error.
opw 2092134
closesodoo/odoo#39682
X-original-commit: 1a315e87b05fcbdefcb3db6d8d4837f6cc3e835c
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
By default, the name of a file input field is 'Custom File Upload'.
If there are two fields with the same name, then they both end up in
self.form_fields with the name 'Custom File Upload[0]', and their values
are concatenated, which are file objects. So the concatenation of two
files is a String, ('[object File],[object File]'), because JavaScript.
(And if you don't like it you don't like the web nor human progress.)
The resulting bug is that instead of adding attachments to the created
record, it adds the string message to the notes.
Adding the outer loop index disambiguates the names, so that all
attachments are created as intended.
opw 2092653
closesodoo/odoo#39674
X-original-commit: 5df3f662dc9f7e3030a899a6f4196245083ad415
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Steps to reproduce the bug:
- Ask a question in the forum with a title but with no content
Bug:
A traceback was raised.
opw:2093665
closesodoo/odoo#39675
X-original-commit: 51f660c9a66f2e6aecb51e476d815b2f083f843d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
It was technically possible that two editors for the same element are
created in the same JS stack execution... and since 13.0 and the
use of native promises, it happens everytime a block is dropped in the
page.
Note: this commit fixes the problem with minimal code but the logic
should be improved in master.
closesodoo/odoo#39668
X-original-commit: 497bc892697ba1b5d2e7140f07970e468b7c90a7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The BVR implementation was confusing as it
seemed to only take into account the case where the postal
account belonged to PostFinance itself and not to another
bank, where the same number is shared among multiple accounts.
Also, the purpose of the fields was confusing.
Adaptations done:
- When you add a bank account of type postal in the account number,
there is an onchange that automatically puts it in the postal account
field and makes itself unique by adding the name of the partner to
the account number. The account will still be detected as "postal".
- Improve help message of the postal account field on the bank account
as it is used for two different purposes (Client Number for own accounts
and postal number for "postal" vendor accounts)
- Only show the subscription fields when you have to do with a bank
account related to your own accounts / Switzerland
- Add fields in the Add Bank Account wizard if it is for Switzerland
(subscription number and the postal field we label "Client Number")
- Also label Client Number on the journal form for postal field
- Don't remove zeros in front of the client number on the BVR
- Don't put extra - in the subscription number on the BVR if it has
some - already
- Use number without spaces for payment reference
[FIX] l10n_ch: module moved to enterprise
closesodoo/odoo#39642
Signed-off-by: Josse Colpaert <jco@openerp.com>
There recently were some fixes to the system of onFocus/onBlur with the
new left panel of the 13.0 editor and one still remained: the onBlur
method was most of the time called only on the main snippet options and
not the child ones. Now it works as it should, even if the system logic
has to be improved to be more robust.
One difference remains with 12.0 but this can be considered as a change
for the 13.0 version: the parent options onFocus/onBlur are called
before the child options while it was the opposite before.
closesodoo/odoo#39659
X-original-commit: 502db91c0b38567dede5d683370fef82890a99f0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The _get_report_values method is an api.model, not an api.multi (on a purely ORM
consideration, it should have no impact on the execution on standard
code).
closesodoo/odoo#39535
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When you create an invoice, you can register a payment to mark it as
"paid".
Before this commit:
- You can't send & print the invoice anymore.
After this commit:
- The button send & print is displayed
The second "send & print" button's domain was incorrect.
OPW-2115720
closesodoo/odoo#39650
X-original-commit: 18abdcf7b9b9d5af3d6f92c45c65f9a22e7177bf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Initial b6ed34e1 idea was to ensure that we always have
_rewrite_len and _routing_map defined. Unfortunately, this
is not correct since class attribute defined dynamically
are actually added in registry, and recomputed on each install.
More than that, the call si shared between multiple database
meaning that routing_map cache may be shared between multiple
database whcich is not correct.
After b6ed34e1, when installing discuss on a fresh database without
demo, all discuss routes will be unknown since None is already in
_routing_map and thus routing_map is not recomputed.
When routing_map is on the model class, in registry,
a new install will reset the class, remove the _routing_map attribute,
which will fix the problem.
Task #2117275closesodoo/odoo#39640
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider website W
- Activate multi-company
- Disable common contact book and common catalog
- Switch the superuser in company C2
- Activate pricelist
- Create a public pricelist PL for C1 and available on W
- Set up a pricelist with compute price = formula and based on = cost
- Go Sales > Configuration > tick Multiple Sales Prices per Product and tick Prices computed from formulas
- Create a portal user PU and set PL on him
- Create a product P with cost = 10$ and publish it on W
- Set up the product valuation as: automated
- Log as PU and go on the shop
- Put P on your cart
Bug:
The price of P was 0$ instead of 10$
opw:2092695
closesodoo/odoo#39638
X-original-commit: b49bf15040748200ad68b557ccdc96eed46c3464
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
We had a traceback when installing pos_mercury if pos_iot was not
installed because the field `iot_barcode_scanner` was not present in
the view of pos_enterprise. Furthermore, if pos_iot is installed after
pos_mercury, this label will be again overriden.
We fix this by removing the override and changing the label when
pos_mercury is not installed.
closesodoo/odoo#39646
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Fine-tunning of 937b5c076e7175bec664ed0cf4b77505e342f1e2
Have a multiwebsite setup
have a payment installed for one of the two websites
Make an order on that website and try to pay
Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP
After this commit, the payment success page is opened as we took
the request's url as the return url
opw-2080352
closesodoo/odoo#39643
X-original-commit: a9fb15b33fd041ee420581a5ba450017db06e0c7
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, when a dropdown overflew its container
i.e. in the case of a long filter menu in modal
The scrolling of that dropdown to get to Add custom Filter
was impossible
This was because dropdowns react pretty bad when contained in a
relative positioned container
https://github.com/twbs/bootstrap/issues/26512https://github.com/twbs/bootstrap/issues/28513 !!
After this commit, the btn-group that adds the relative positioning
is forced into the default value
This commit corrects what was initially
corrected at https://github.com/odoo/odoo/pull/37594
in v12.0.
The incriminating commit that retriggers the issue
is irrelevant because it is the refactoring of action manager
but here it is: 40dd121938closesodoo/odoo#39541closesodoo/odoo#39636
Original-signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
X-original-commit: 7f72b837473f68a1dcd6a303ac1bf355dddcc2b1
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Be in Right to left
Open a m2o search more, to get onto the list modal
toggle the filters menu
Before this commit, the filters dropdown was almost invisble
and too much on the right anyway
This was because the RTL was not taken into account
After this commit, we anchor the dropdown on the right
(both as in good and as in side) side of its trigger button
Also, when modifying the dropdown, by developping the Custom Filter
we force the repositioning of the dropdown, to take those new elements
into account
It is expected though that after this commit, in RTL, the
dropdown in a modal that has a scrollbar (which is on the left)
will be slightly pushed to the right. It is usable and visible though
Some kind of plumbing using $el.data('offset', fn) from popper.js
is possible, but has been deemed not robust enough
Docs
https://getbootstrap.com/docs/4.0/components/dropdowns/#methods
OPW 2088934
X-original-commit: 105b4affd65ea23e1aa65b53f4595c174c9984ef
Activate developer mode, generate a report (print an invoice)
The report will have missing pieces, like the footer or some part of the
header. This is probably caused by wkhtmltopdf not loading properly some
resources
Wkhtmtopdf generate the same warning message for every problematic resource:
"Warning: Received createRequest signal on a disposed ResourceObject's
NetworkAccessManager. This might be an indication of an iframe taking
too long to load."
Related issue on wkhtmltopdf project page:
wkhtmltopdf/wkhtmltopdf#1865wkhtmltopdf/wkhtmltopdf#3933wkhtmltopdf/wkhtmltopdf#2565
The problem is located in the response that wkhtmltopdf receive:
in debug mode the header of the response contains
'Cache-Control: no-cache' which probably create a race condition during
the rendering while a second request is attempted to verify the
resources.
Adding a raw user agent check to not include this header directive
fix the problem
Notes from odony:
We've considered some alternative solutions to preserve the purpose of the
DisableCacheMiddleware without having to explicitly test for wkhtmltopdf.
* 'Cache-Control: no-cache' (current behavior) breaks wkhtmltopdf rendering
* 'Cache-Control: no-store' breaks wkhtmltopdf rendering too
* 'Cache-Control: max-age=0' breaks wkhtmltopdf rendering too. It works
when increasing the delay to a few seconds, but no magic value will work
for very long documents, or it will stop serving its purpose, so it's not a
viable option.
* 'Cache-Control: must-revalidate' does not break wkhtmltopdf rendering (no
duplicate requests at all), but it is not clear from the RFC
(https://tools.ietf.org/html/rfc7234#section-5.2.2.1) that it
will have the intended effect for our middlewar
opw-2086708
Closes#38394closesodoo/odoo#39634
X-original-commit: 8cac60be37133cabef46dab016a5692876da9e5e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Be in RTL mode, on a list view
Click on the button to set up optional fields
Before this commit, the dropdown expanded to the right, and was partly invisible
After this commit, we dynamically set to which direction the dropdown should expand
depending on RTL/LTR
Consequently the dropdown is fully visible in either mode, and expands to the list
rather than away from it
closes#39402closesodoo/odoo#39628
X-original-commit: fb914d176de5a4711f11de32945ebaec0164f62e
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In the editor, the snippets from uninstalled module are shown with the
possibility to install the module to get snippet.
Before this commit:
When clicking on it, it will redirect to the module page, in the backend from
where you can install the module.
Now:
A popup will be shown to save current changes and install the module.
The installation will be done without changing page, in the editor. Once done,
the page will reload in editor enabled mode.
task-2089285
closesodoo/odoo#39138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Cedric Snauwaert