Before this commit, the web_editor toolbar wasn't horizontally scrollable
and part ot the items were not displayed.
To fix this, we have to revert back the initial position on some elements.
closesodoo/odoo#37076
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the web_editor toolbar wasn't horizontally scrollable
and part ot the items were out of the screen area.
To fix this, we have to revert back the initial position on some elements.
Before this commit, web_editor dialog was opened inside an iframe and
not on the window.top. So dialogs didn't take all screen area.
To fix this, we open dialogs in full screen mode but we also put the
web editor in full screen to increase the size of the iframe.
Note that the initial state of the web editor (full screen or not) is
preserved when you close the modal.
We also add some fixes to make the "web_editor media dialog" responsive.
When converting an opportunity to a quotation, it will give 3 options where
the last option is "Do not link to a customer". When clicked it has the
same behavior than "Create a new customer".
Followup of 1d2bccd0db that added the
selection entry but did not implement its behavior.
This commit fixes that behavior. Now it opens a quotation without linked
customer.
Task ID 2065014
closesodoo/odoo#37026
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit fff2a30 introduced a popup on sale order line to show some information about available quantity
of the sold product.
This commit adds various imporvement on this widget
closesodoo/odoo#36995
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
SPECIFICATIONS
* Remove the /home from the breadcrumb in user profile
* Rename the Home (on a specific course) into "Courses"
Task 2062640
closesodoo/odoo#36900
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Customer invoices and supplier refunds lines involved with taxes will be credit lines, hence their balance must be inversed when shown in the tax audit field.
The method is_inbound() encloses exactly those documents, whereas is_outbound() stands for customer refunds and supplier bills.
closesodoo/odoo#37092
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
From the settings activate:
- Multiple Sales Prices per Product
-- Prices computed from formulas
- Discounts
Create a pricelist with discount policy "Show public price & discount to
the customer", set the price calculation formula:
- Rounding: 10
- Price discount: 10%
Modify the sale order xml list view adding 'digits="[3, 2]"' to the
discount shown in the sale order line.
Create a sale order with such pricelist and on the so line put a
product with quantity 1 and sale price 4190 (VAT 19% included in the price).
The discount will not display the requested number of decimal digits (2)
in list view, but it will when editing the field.
The cell formatting is done calling the appropriate function (formatFloat),
which search the digits option from the 'options' parameter or from the field
definition. The latter stores the default digits coming from
the DecimalAccuracy settings, which, as side effect, alter the behavior
of the discount calculation.
https://www.odoo.com/web#view_type=form&model=project.task&id=2069939&active_id=2069939
When passing into edit mode the field is created as widget, parsing its options
which have 'digits', instead when coming back in list mode it is "just a
float field" rendered directly from the list_renderer which no options,
so the formatFloat will look at the field definition
https://github.com/odoo/odoo/blob/12.0/addons/web/static/src/js/fields/field_utils.js#L172
Adding the correct parameter to the dictionary passed to formatFloat
during the list rendering is a possible solution, because it is the
"closest" point in which parsing the parameter is possible without
touching higher level code or forcing the creation of a widget (adding
widget='float' as xml parameter).
closesodoo/odoo#37167
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Initial bug report, full of red herrings:
receive two support requests by email while on Odoo.sh, the first creates a
ticket, while the second replies to the server with the error:
550 Requested action not taken: mailbox unavailable
When a request is done, the service check function tries each request multiple
times when getting Operational errors.
When two email are received within a 'short' amount of time (e.g .1 second)
the two requests are initiated with a new cursor.
When both mails generate the creation of a new record of the same model,
the second cursor is going to fail because of an:
ERROR: could not serialize access due to concurrent update
However, the record we used in the computations needed in the creation of the
second record have been added to the environment.
When that second creation is retried, it will operate on the same records,
and find them in the todo, with the environment that was obtained for the first
trial. Since the cursor is closed, this crashes.
To explain the bug report, Odoo.sh transfers the mail through an xmlrpc
to process the mail.
Because of this crash, the server interprets the lack of well-formed response
by a generic 'mailbox unavailable'.
opw 2060476
closesodoo/odoo#37165
X-original-commit: 845eecdfa7b27d84862e94f4b63d40a851e0c410
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Display the difference when an unbalanced journal entry is created to
help pointing out the source of the issue.
opw-2069673
closesodoo/odoo#37145
X-original-commit: d00e3158cd30067f7cc8d524eff81ccd6e620342
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
- Add the following in a PDF report:
```html
<p>
<blockquote>
<ol class="loweralpha simple">
<li>Item that explain terms</li>
<li>Another item that explain something else</li>
</ol>
</blockquote>
</p>
```
- Print the report
Wkhtmltopdf crashes with the error:
Wkhtmltopdf failed (error code: -11). Memory limit too low or maximum
file number of subprocess reached. Message : b''.
This is a known issue:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/4115
Actually, since this CSS is only used for Wkhtmltopdf reports, we can
simply remove the CSS rule causing the problem.
Closes#37034Fixes#37033
opw-2073195
closesodoo/odoo#37155
X-original-commit: 8d08893172ae8c0f3ad1f1af6ab9514aa30bf843
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case where no argument is given to _compute_price_rule, it would default to
context_today().
This gives "today" in function of the context, depending on the user timezone.
In contrast, an explicitly given date would always be UTC.
Furthermore, on the webshop an unlogged user would get the Public User timezone,
and once logged would get its portal user's timezone.
To make everything coherent, we always use UTC.
opw 2054881
closesodoo/odoo#37154
X-original-commit: 35d4a8ccce8f3a34701d231e17a324cbbf5abfab
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Sibling commit of 427280d9760a71e6ca2961bcf4a2f9f157e6dddd, same use case.
Be in company C1. Create the invoice I for a SO in company C2.
The invoice line is with an account created of C1.
This is because property_account_income_id or property_account_income_categ_id
are company dependent properties that need to be accessed with a force_company.
This happens when e.g. C2 is a child company of C1.
However, accounts are not readable across companies, so the resulting invoice
cannot be validated in either company, since there is a mix of accounts.
Note that in case force_company is False, it defaults to the user's company,
which is already the default.
opw 2068291
forwardport of 79714bafe4b
closesodoo/odoo#37146
X-original-commit: ae84e7fd416c38404c20607b5b04fc1c9b790cde
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Commit c3717f3018 added a (5, 0, 0) command when modifying groups_id of any
non-internal user, to avoid the situation where the various implications would
end up giving the portal user group_user rights.
This risk is avoided by commit f206714af0, which added a constraint
check_one_user_type, which would raise in that specific case.
The last missing piece was 9badedcd98f; when groups are added through settings,
they are added through the implied_groups of the group model.
The (5,) command has the unfortunate side-effect to remove the portal group
from a user if a write is triggered programmatically.
If that happens, then the 'signing up' process end-destination is a 500 error.
Now we simplify the logic that keeping the same behaviour for implied_ids for
internal (group_user) and non-internal users.
We keep the (5,) command in one case: if a user is demoted to portal or public,
he may have groups should be reserved to internal users, but that do not imply
group_user (which would raise).
To avoid that, we remove all its groups, since there is no clear distinction
between technical display groups and actual privilege-granting groups.
opw 2041606
closesodoo/odoo#37144
X-original-commit: 29723e351d5dc5e5ea055c80da86f4e871909de9
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Steps to reproduce the bug:
- Go to Sales app and open the form view of a product P
- With studio add the field display_name in the view
- Try to create a new product
Bug:
A access error was raised because a read was made on a record in cache
opw:2070074
closesodoo/odoo#37133
X-original-commit: 90143c18f50ff31ded5aba7d7ba3beb66423ff06
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Improve the manual reconciliation widget:
previously when opening the reconciliation view from receivable or payable account, only entries having a partner where showned, now also shows entries with no partner. -> We still need to have one entry in debit and one in credit for the reconciliation widget to show something but partner is not necessary anymore.
When coming from the aged receivable or the partner followup and clicking "reconcile" we want to be able to see all entries for that partner that are not reconciled (before we only showed something if they were at least one debit and one credit entries for that partner). We added a new context key (all_entries) for that use case.
closesodoo/odoo#36879
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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>
Steps to reproduce the bug:
- Create two operation types OP1, OP2 with code = mrp_manufacture
- Create a BOM B with operation type = OP2
- Create a MO with B
Bug:
The operation type set on the MO was OP1 instead of OP2
Technically:
The default value was always taken from function _get_default_picking_type
opw:2070370
closesodoo/odoo#37029
X-original-commit: 3c5338dce8db7606ac2ac0101473bcafe3bd4f76
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The test was made with an epsilon of 0.00001, which is precise enough to avoid
false positives, but allowing false negatives.
As a results, some orders can be incorrectly determined unpaid.
No (non-digital) currency has a precision higher than 0.00001,
but many currencies have a precision much lower (e.g the unit for ¥).
Also, we prepare for the future where all orders will be paid in Bitcoin.
opw 2059997
closesodoo/odoo#37112
X-original-commit: 73c2d46f4a443885fbf67879141ac892efebe3c7
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
— Create a new product, it's tracking must be set to 'By Unique Serial
Number';
— Create a new purchase order, with 500 lines. Each line with 10 units
of quantity of the previously created product;
— Confirm the purchase.
Before this commit, the creation of the stock piking take a quite some
time, and becomes difficult to use this functionality.
Now, the creation of the stock piking time was significantly improved.
opw-2070738
closesodoo/odoo#37107
X-original-commit: a434b087c86888903e320532b5e75856fa32bd13
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since fbbfa6d it's not longer possible
to write a date without separator (e.g., 0102 for 01/02/2019; 121298 for
12/12/1998; 02042018 for 02/04/2018), or a date without year (e.g.,
01/02 for 01/02/2019) in the datepicker widget.
In this commit we have decided to be as permissive as tempus dominus
that call moment.js with strict false. This allows moment.js to deduct a
date from a string in a more versatile way. This also allows a more
versatile autocomplete in the search views.
opw-2070464
opw-2070931
closesodoo/odoo#37095
Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the field cash_basis_base_account_id, used
to keep track of the base on which a tax a computed for cash basis entries
was required in the tax form view
Since this account can be absent, and will be most of the time, and that
an account is retrieved anyway in the move creation process it is safe
to remove the required attribute in the view
After this commit, the field is not required in view anymore
OPW 2072750
closesodoo/odoo#37060
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since commit 8fa9f7d6d4 refactoring the
actions server, the documentation was outdated.
This commit removes and fixes the documentation on ir.actions.server.
Also adds the display of the docstring of the IrActionsServer class from
odoo.addons.base.models.ir_actions.
Solves #31044
The `forcecreate=0` is required because the ICP will be deleted when set
to `False` (which is quite frequent for a boolean).
closesodoo/odoo#37103
X-original-commit: 255a12931d2a22dfadb1455a5dfc0a5e2f37b730
Signed-off-by: Christophe Simonis <chs@odoo.com>
When a title with boxed style (border arround title) is split (by doing
normal ENTER (and not shift ENTER which work as expected)) the title
being in inline-block for styling purpose, this give odd results (of
several title boxes on the same line).
With this commit style is changed so split title are on different lines.
opw-2070611
closes#37084
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
need seperate lines with different labels(SGST and CGST) on the invoice report and pos receipt
so use a tax group instead of repartition line
closesodoo/odoo#37080
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, discuss widgets had to wait for the route
`mail/init_messaging`. This behaviour slowed down the loading of the
web client.
This commit solves the issue by rendering discuss widgets even when
`mail/init_messaging` hasn't been resolved. For instance, the
messaging menu displays a spinner until messaging becomes ready.
Task-Id 2072835
closesodoo/odoo#37031
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, there was no way in the event question report
to filter out cancelled registration
After this commit, we introduce a filter for it
OPW 2072973
closesodoo/odoo#37032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Changed the way the header selector behave when the selection changes.
Before this commit, the header selector was only checked when clicked and
was unchecked as soon as any other record was unchecked.
Now, the header selector reflects the current visible selection:
if all of the other visible selectors are checked, it will be checked.
Folded records are not considered visible, thus only records from active groups
and from the current pager will be taken into account.
closesodoo/odoo#36522
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Added handling of invalid format types in multiple edition in list views.
Before this commit, in multiple edition, a field that was edited with an invalid value format
(e.g. a numeric field receiving a string value) didn't trigger a field_changed and no prompt
was shown; the record was simply idle with an dirty value.
Now, the list controller also listents for set_dirty events and automatically triggers
an error modal + discards all changes when receiving one.
Gives time to the user to enter an actual value in m2o in list views.
Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.
Now, many2ones only trigger a fieldChange when selecting a new valid value.
This rev. solves the similar issue as 801c603218, but with boolean
fields.
Scenario: select several records, select a boolean cell, press
enter to change the boolean value.
Task 2068280
Onchanges make no sense in multi edition as they would be computed
on the 'reference' record (the one use to edit), but applied on all
selected records. This rev. simply disables them in that case.
Task 2068280
Romain Estievenart