Since 2054b59 if we created a record in a many2many relationship of an
onchange, we would also possibly erreneously return the NewId.
The logic of convert_to_onchange of _RelationalMulti doesn't send back
the ID field (if the ID is needed, it is part of the command, not the
update/create dictionary values of a command) and this commit does the
same for the code changed in 2054b59.
This commit also adds a test for this fix, and a test for the regression
corrected with cd2ccc4110 reported in #25969
fix for https://github.com/odoo/odoo/commit/2054b5928#commitcomment-29837226closes#25984
When invoicing a line with an account that has a tax, ensure that line has the same tax of accounts. This is required by DATEV and is common usage in Germany
Was task 35289
Was PR #25202
I. modification and extension of SKR03 account chart
========================================
* improvment and mapping of Odoo standard account types (usage of all
available account types and fixing of wrong mapping)
* fixing of reconcile setting on several accounts
* update of account chart (to SKR03 2017)
* fixing of account chart by ascending order of accounts for easier
maintenance in the future and probably easier preparation of accounting reports
* backport of new account tags from V11 for better reporting
* shorter tags
* introduction of new taxes for all theoretically possible tax cases
needed to declare the VAT
* automatic mapping of taxes to accounts to auto detect the right tax
by selection of income / expense account on invoice lines
* assignation of tax groups to taxes
* introduction of reconcile templates (to allow booking of cash discount
cases)
II. modification and extension of SKR04 account chart
=========================================
* improved mapping of Odoo standard account types (usage of all
available account types and fixing of wrong mapping)
* fixed reconcile settings for all accounts
* update of account chart (to latest SKR04 2017)
* better source code by ascending order of accounts. Finally it will be
easier to maintain the chart in the future and also it will be easier
to identify and group records to to develop missing or new accounting
reports.
* backport of new account tags from V11 for better reporting
* shorter tags
* assignation of tax groups to taxes
* introduction of further taxes to cover most possible tax
cases needed to declare the german VAT
* automatic mapping of taxes to accounts to auto detect the right tax
by selection of income / expense account on invoice lines
* introduction of reconcile templates for cash discount deduction on
payments or low payment variances.
Access a SO with the access token, without being logged
Before this commit, the images of the so lines were the no image placeholder
This was because the route of the image was so.line/product_image
Since the token applies on SO, and not on its lines, nothing simple would work
After this commit, we hide the image if the user is the public one
OPW 1868916
closes#25973
Connect as portal, go to my account > invoices and click pay now
select wire transfer as the acquirer and then pay now
Before this commit, the messages displayed to the user was misleading and wrong
After this commit, we take the relevant acquirer's message
OPW 1867670
closes#17508closes#25946
This commits defines a new method 'action_post()' for 'account.move' object to call instead of 'post()' from the account.move form view.
Indeed, additional parameter ‘invoice’ of post() is considered as ‘context’ by webclient when called from button action and it is crashing badly.
TASK ID - 1860817
When validating a leaves request with a user which is
in group group_hr_holidays_manager(Leaves Manager) and
group_account_invoice (Accounting & Finance Billing), it raised an
access error because the function _validate_leave_request
tried to create an analytic line with a project_id.
Without the rule account_analytic_line_rule_billing_user added by this
commit: https://github.com/odoo/odoo/commit/81218a8, a user which was
in group group_hr_holidays_manager and group_account_invoice had the rights
to validate a leaves request.
opw:1866243
Currently settings for purchase stock dropshipping are added by
classname 'app_settings_block'. But there are so many classes with this name
that by default it takes first class. First found application receives this
settings.
This commit fixes that by correctly putting the settings in the purchase
settings.
Related to task: 1858217
Closes PR #25267.
While clicking on the answer in appraisal, it gives traceback because of this
context filter. This commit is related to task ID 1866476 and closes PR #25749.
Without the call to `super`, with at least two level off expected
onchange return data (eg. `invoice_lines.name`) we have an error in
python2, python3 python implementation of OrderedDict and possibly other
python implementation.
So this worked most often (with python3 CPython C implementation of
OrderedDict) by chance.
closes#25960
When creating a job position from the frontend, and we:
- are on the same language that the default website language,
- have the permission to write on ir.ui.view,
we have all conditions to adding branding used to edit a page.
But when creating a position by the frontend, we create a job that will
render this template:
website_hr_recruitment.default_website_description
When we are in the above said condition, we will create a job position
that erroneously has the branding that should only be displayed on
website and removed when saving an edition.
This caused a lot of problem with the editor that would most often not
be able to edit the content.
In this commit, we use the "rendering_bundle" context key to prevent
branding.
opw-1868879
closes#25963
With the portal user, go on /my/task/1
(obviously provided that this task doesn't belong to portal user)
Before this commit, there is a 500 error
After this commit, the exceptions are handled and throws a 403
OPW 1867795
closes#25951
On mobile, some barcodes didn't trigger in the picking screens, notably
O-BTN.validate. This is due to the use of parent() to check if the
button is in a dropdown, as parent() only checks one DOM-level upwards.
The button being inside a <ul><li>, we need to check more levels than
one to pass the condition and trigger the button press.
By changing parent() to parents(), the entire chain will be checked, not
just one level, and the button press is correctly triggered.
opw-1860964
closes#25941
Before this commit, the style of the value and text in some stat buttons were
broken.
The design of the stat button is to have a single value and a single text which
are stacked as follow:
[CSS] [Visually] [Example]
.o_stat_info +---------+ +------------+
.o_stat_value | | | |
.o_stat_text | value | | 10 |
| text | | Forecasted |
| | | |
+---------+ +------------+
However, some stat buttons use multiple values or texts. For example:
[CSS] [Visually] [Example]
.o_stat_info +-------------+ +------------+
.o_stat_value | | | |
.o_stat_info | value text | | 3 Hour(s) |
.o_stat_value | text | | Lost |
.o_stat_text | | | |
.o_stat_text +-------------+ +------------+
[CSS] [Visually] [Example]
.o_stat_info +---------------+ +---------------+
.o_stat_text | | | |
.o_stat_text | text value | | Min: 10.00 |
.o_stat_info | text value | | Max: 20.00 |
.o_stat_value | | | |
.o_stat_value +---------------+ +---------------+
The latter is works fine with block, which guarantees vertical alignment.
However, the former case has some alignment issues like this:
[Visually]
+------------+
| |
| 3 |
| Hour(s) |
| Lost |
| |
+------------+
This is due to the use of `display:block` for any `.o_stat_text` and `.o_stat_text`.
This commit fixes this issue, without affecting the other cases.
Task-ID 1841523
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
Let's install base_vat_autocomplete and base_address_extended
When creating a contact with a VAT number, the street was not
formated by the autocomplete in a correct way because the function checkVat all the time
returns the street with the following format: '%(street_name)s, %(street_number)s/%(street_number2)s'
and this function doesn't take the street format of the country into account.
So the function _split_street tried to split the street into street_name, street_number, street_number2 with the
street_format of the partner but the street was not well formated by checkVat.
opw:1867491
Rendering in html was correct thanks to the webkit-padding-start 40px added
by the browser. But once printed with wkhtml, the padding was missing.
Now we force the padding manually.
This commit closes#7375