In multi-level checkboxes, if there is only one checkbox per level, the
expected behavior is that all checkbox will be checked if one of them is
checked. This was not the case before this commit.
When setting align right on a picture, the popover of the picture was
partially overflowing the editable zone, rendering it useless.
This commit mimicks the behavior of Odoo 12 by disabling the fact
that the popover follows the picture.
The `get_technical_translations()` method was returning wrong list of list
for field selection values; instead we flatten the results to get a correct
domain.
closesodoo/odoo#37101
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If the journal is set to post entries at bank reconciliation, payment entries that are validated have their associated account_move in draft.
Or we still want those to appear in the invoices/bills as outstanding credit/debit.
This commit fixes this problem by adapting the domain used to fetch the payment lines that should be displayed as outstanding debit/credit.
closesodoo/odoo#37091
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
The style for custom color in the editor color menu from 12.0 was
dropped in 12.3 (correctly because of the changed structure) but in 12.5
the HTML structure changed again and the CSS is once again necessary.
opw-2073734
closes#37090
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When you add a discount, the price is changed on the product, and so
when you have enabled options to display the discount, the product is
shown as discounted. So we are modifying the lst_price too (like for
tip) to avoid having differences between prices.
closesodoo/odoo#37089
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When a draft move is created and saved, we cannot post a pdf on it
anymore because facturx expects a default journal entry type to be in
the context in _import_facturx_invoice.
In this case, it is not in the context anymore because it has already
been saved on the account.move on which we try to post the pdf.
closesodoo/odoo#37055
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Prior to this commit, the Time Off Analysis report was showing the
leaves of all employees and not the ones selected.
closesodoo/odoo#37048
Taskid: 2073345
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Before this commit, you can start a repair order with negative value
into its operations (who will cause a dead end when user will try to end
it). So, now a check is done when user tries to start it.
closesodoo/odoo#37045
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When user confirms a repair order for a consumable product, they always
get a warning wizard about insufficient quantity.
But as we don't track quantity for consumables, this wizard is useless.
Task 2072312
* Ensure that the css is from Odoo and not from the browser
* Only use up/down to navigate
* Use Enter to validate a line
* Remove the accesskeys
Task 2072312
* Change the label "/" by "Draft <document type>" for draft entries (change name_get() of account.move)
* New left-bar menu for a chart of account & general ledger view: Take into account the company (for multicompany, avoid having the number 7 if the current company doesn't have 7xxxa accounts)
* New filter "Accounts With Entries" for the chart of accounts
Show only account which has at least 1 journal entry on it
* Show the move_id on the move line tree view
An "iface_payment_terminal" field was present but never used. We
remove it.
Add a class on the list of IoT Devices to override it easily in pos_iot
and increase the width of the labels.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#36495
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Some parts of the receipts had a black background, making them
unreadable. The origin of this problem was that the white background
was not applied correctly to the whole receipt. The rest of the receipt
had a transparent background which was then changed to black when
converting the receipt to an image. The parts of the receipt that had
no background were the followings:
- The parts that were out of the screen if the receipt was too long.
We fix this by explicitly specifying a height when generating the
canvas.
- `html2canvas` applies the background to a rectangle starting from
(0, 0) up to (width, height). In our case, `body` has a margin of 8px.
Our receipt was then placed in a rectangle from (8, 8) to
(width + 8, height + 8).
closesodoo/odoo#37072
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Fix: A simple user is allowed to confirm sending sms wizard.
Improve SMS wizard: remove things about policiy and creation of
iap account.
closesodoo/odoo#37016
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Because of the z-index, the resize handle of the last column was
over the optional fields dropdown icon, making it impossible to
click on. The z-index seems unnecessary, so we remove it.
Task 2067477
closesodoo/odoo#36987
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Thought there was a bug, but it's actually working fine, so no fix
needed, but the test is written (and it doesn't exist yet), so we
keep it.
Also fixes a selector to make an assert relevant in an existing
test.
Before this rev., the mocked fieldsViewGet treated whitespaces in
inline subviews as TextNodes, and processed them as subviews. As
a consequence, it crashed later on when the View tried to parse it.
This rev. adds a (debounced) handler to react on window resize
events in editable list views, in order to recompute the (fixed)
column widths.
Task 2067477
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.
Task 2068280
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.
Task 2068280
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
Gave back focus to the last edited cell to increase usability with key nav.
Before this commit, after saving several records with multi edition in a list,
focus was lost (given to the body).
Now, last edited cell is given back the focus after multi editing.
The Date(Time)Fields listen to 'input' and 'change' events (like
all InputFields) to keep track of changes. However, the datepicker
already listens to the 'change' event. As a consequence, in multi
edition in a list view, if the user changed the value of a
date(time) field by directly editing the input, the fieldChanged
event was triggered twice, and there were 2 dialogs asking the user
if he wanted to save the change.
This rev. makes the Date(Time)Fields stop listening themselves to
'input' and 'change' events, and instead completely rely on the
datepicker widget.
Task 2068280
Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.
Task 2068280
Having those inputs enabled can lead to weird situations where a
record has been modified but can't be saved anymore (because the
user clicked on one of those record selectors to focusout the edited
row). Also we don't want the user to start multi-editing a field,
then change the selection, and then validate the changes.
Task 2068280
Before this commit, if a record was selected and another one was edited,
it was considered as multi edition.
Now, the multi edition only works if the edited record is included in the
selection; else it will be the only edited record (single edition).
Task 2068280
...when validating last row by pressing ENTER.
In single edition, we automatically add a new row when the user
edits the last one and presses ENTER. This is something we don't
want in multi edition.
Task 2068280
Let's assume an editable list with a many2one and a char, the many2one
being readonly. Before this rev., if the user clicked on the many2one,
the row was switched in edit more, and the many2one link was given the
focus.
Now, in the same scenario, the focus is given to the char field which
can be edited (i.e. its input).
Task 2068280
Fixes the way records are discarded in list views
Before this commit, clicking the "Discard changes" button in a list view
after editing a record triggered both the "field changed" and the "discard changes"
methods (resulting in 2 modals opening).
Now, all fieldChanges are prevented when trying to click "Discard changes",
and are re-applied if the click was unsuccessful (lifted left mouse button somewhere else).
Task 2068280
Let's assume an editable list view with a many2one field and 2
records: the first one has value 1, the second value 2. The user
selects all records and wants to set their many2one to value 1. It
edits the first one, sets 1 and validates the confirm dialog.
Before this rev., it didn't save anything because the 'reference'
record (the one used to edit), didn't actually changed, as we reset
the same value.
This rev. forces the write the new value on all selected records in
that case.
Task 2068280
The link between a sale_order and a task relied on a sale_line between the sale order and the tasks. This was working when allow timesheet and allow material were true, as we had a timesheet_product_id and the sale_line was created empty. But when we create a project with material but no timesheet, the sale line would crash.
Now the sale order and the sale line creation are split, and we write the sale order id on the tasks. This works because with the new ORM, we can write on a stored compute field, and if we take care of not overwriting it in the compute, it stays at what we wrote.
task-2047389 closes-5388
When clicking on edit in a form with a wysiwig widget inside, that widget would gain focus. It is not the expected behaviour (focusing the first field) and is really an issue on mobile, where the screen would scroll and the keyboard open.
The mouseup event was there to force summernote refreshing the editor toolbar (which will not display which buttons were active until the editor is focused). So removing it still has drawbacks (the toolbar is not up-to-date), but with chm it was decided to remove it as the issue with focus is worse.
Task-2047389 Closes#36360
This would lead to a strange situation, where two tasks share the same sale order which means change on one would be reflected on the other.
Task-2047389 Closes#36360
action_view_invoice is made to work on empty/single/multi records, but there are context keys used to provide defaults when creating invoices in the next view. However when those fields are different among the origin sale orders, we get an error, because the record set's values is accessed like in a single record.
In this record we add the default_* context keys only if the recordset is of length 1, so it keep working as before for single/no records. And it doesn't crash when coming from multiple sale orders with different fields.
related task 2047389
Gorash