A traceback occurred on the Intrastat list view (Accounting >
Reporting > Management > Intrastat), when the user clicked on a row
of the list. This action only specifies 2 view modes: list and
kanban. When a record is clicked, the ActionManager tries to open
that record in a form view. As the view isn't in the action, this
request should be ignored. Before this rev., this case wasn't
correctly supported.
Purpose
=======
We should add some real timezone support for the global leaves
(resource.calendar.leaves without a resource assigned) currently it is
declared in UTC and never changed to the user or employee timezone.
Specification
=============
In order to support this, we have to add some choices for the user
defining the global leave. He can specify how the timezone is
configured,
- no value is specified, we keep the dates in UTC then convert those to
user timezone
- current user timezone specified, we set the timezone of the leave to
the company timezone
- a timezone is specified, we keep this specific timezone
Static help from xml and python generated help were both showing the new
smiling face, we needed to sort that out.
Python dynamic help now prevails over static help.
Co-authored-by: RomainLibert <rli@odoo.com>
Use case to reproduce:
- Install delivery/batch picking
- Process 2 pickings in a batch.
-> Traceback due to ensure_one.
It happens because the action_done method in delivery is
not multi and batch_picking launch action_done on multiple
picking.
This commit makes action_done in delivery multi.
It happens due to workcenter working hours,
the workcenter is not active during the weekend thus
the productivity loss are not counted in the oee.
This commit removes 2 days to the test date if it is
during the weekend.
Purpose
=======
General improvements on the accounting application
SPECIFICATION
=============
1. On a supplier invoice, everyhting should be in the language of the user, not in the language of the supplier
2. list view on invoices and vendor bills: Add the amount VAT excl. and the tax amount in the columns
https://drive.google.com/file/d/0B9XXHE6oGlGJVXVaYjdUekxZbkE/view
3. remove tax scope in the list view of the taxes coming from the search more of the invoice line
https://drive.google.com/a/odoo.com/file/d/0B0ITmdw6h3ZrVWc4NVFQZVFpY0E/view?usp=drivesdk
4. Hide the Filters option (While venders bills search view showing only tax scope purchase and sales bills search view showing only tax scope sales so no need purchase and sales option of the filter, also hide active and inactive filters.) https://drive.google.com/file/d/1rWzGr4X5SswUZLZXiNI15Qg4Oqb5wopC/view?usp=drivesdk
5. Payment terms
It should not be possible to delete a payment term that is used in another document.
Raise the following error : "You can not delete this payment terms as other records still reference it. However, you can archive it."
Purpose
=======
Payment terms
It should not be possible to delete a payment term that is used in another document.
Raise the following error : "You can not delete this payment terms as other records still reference it. However, you can archive it."
Purpose
=======
- Remove tax scope in the list view of the taxes coming from the search more of the invoice line
- Hide the Filters option (While venders bills search view showing only tax scope purchase and sales bills search view showing only tax scope sales so no need purchase and sales option of the filter, also hide active and inactive filters.)
[IMP] project: "Task Title">Title (could be named differently)
[FIX] project: don't assign a person on a task during the tour
Someone is already assigned as tasks are created from the kanban,
directly, with a responsible by default.
Purpose
=======
User not able to see his total balance per customer if user has several projects with same customer..
see here : https://www.odoo.com/web/content/3287924
Specification
=============
User should be able to see the sum of the debit, credit and balance when group by partner
The difficulty here is that debit,credit and balance are non-stored computed fields depending on the company and the date passed with the context. As these parameters depend on the user and the current date, we can't store the field. The simplest way to achieve this is to override the read_group method and compute the sum by hand when the values are aggregated (means when a group_by is applied).
Purpose
=======
Currently, when creating a company, the resource calendar is created if not specified.
This lead to duplicated data. In Manufacturing > Configuration > Working Time, two same working time demo data('Standard 40 Hours/Week')
Specification
=============
Company should be correctly set in the calendar.
Previous to this commit, installing sale_managmenet/account_invoicing
would add some menu items for the `sale/account` module
(which contains all the logic for the sale/accounting flow)
and it would also install sale/account since it's a dependency, however,
horror would strike if one were to go and uninstall
sale_management/account_invoicing: nothing happens!
This is because these "facade" modules don't actually install anything, and
uninstalling an app does not force the uninstallation of its
dependencies, thus the `sale/account` module would stay installed, along with
the views introduced by the "facade" module.
To fix this, we create an uninstall_hook which forces the removal of
the ir.ui.menus that the "facade" modules introduce, so that the
functionality remains (for modules that depend on it) but it's not
user-accessible (because it should only be accessible to users if the
facade module is installed).
The issue adressed by this fix was observed by a problem with a missing
onchange. The situation only happens when we have a one2many in a form
view with an onchange in a field in the list view, and the arch of the
list view is not inline. In that case, the onchange was not properly
triggered.
There are two causes for this bug:
- the BasicModel does not exactly receive the same data when loading a
record in a one2many with a non inline view. More specifically, there
is a confusion with the fields/viewFields in that case. This is done
because the postprocessing of the fields is slightly different when a
sub view is not inline (not ideal situation, we should fix it btw)
- when it construct a subrecord, the BasicModel did not use the correct
fields value, when there was a subview. More specifically, it used
the view.fields (which does not contain onchange informations) instead
of the view.viewFields (which contains processed/view specific
informations, including the onchange data.
This commit fixes the second issue, because this is clearly a bug, and
it actually fixes the problem. The first issue is actually okay,
because we already have a difference of behaviour between the main view
and sub views (in the first case, we have the fieldget information, not
in the second case, so the processing is already a little bit different
anyway)
Notes:
- This bug was discovered only because we added a test in 11.0, which
was forwardported and broke in master. The breakage occured because
of a recent refactoring in master which moved the arch processing
inside the views and out of the data manager.
- It is good that we discovered this bug, but I want to say that it really
sucks that forwardports are done, break the master/saas.11.2, then I
have to fix it in emergency, and it completely break my own
schedule...
wip
wip
The issue adressed by this fix was observed by a problem with a missing
onchange. The situation only happens when we have a one2many in a form
view with an onchange in a field in the list view, and the arch of the
list view is not inline. In that case, the onchange was not properly
triggered.
There are two causes for this bug:
- the BasicModel does not exactly receive the same data when loading a
record in a one2many with a non inline view. More specifically, there
is a confusion with the fields/viewFields in that case. This is done
because the postprocessing of the fields is slightly different when a
sub view is not inline (not ideal situation, we should fix it btw)
- when it construct a subrecord, the BasicModel did not use the correct
fields value, when there was a subview. More specifically, it used
the view.fields (which does not contain onchange informations) instead
of the view.viewFields (which contains processed/view specific
informations, including the onchange data.
This commit fixes the second issue, because this is clearly a bug, and
it actually fixes the problem. The first issue is actually okay,
because we already have a difference of behaviour between the main view
and sub views (in the first case, we have the fieldget information, not
in the second case, so the processing is already a little bit different
anyway)
Notes:
- This bug was discovered only because we added a test in 11.0, which
was forwardported and broke in master. The breakage occured because
of a recent refactoring in master which moved the arch processing
inside the views and out of the data manager.
- It is good that we discovered this bug, but I want to say that it really
sucks that forwardports are done, break the master/saas.11.2, then I
have to fix it in emergency, and it completely break my own
schedule...
wip
wip
When exporting to a tarfile, we first export each module's translations
to a file on the FS, then create a tarball from all of them.
With the P3 bytes/string split, translation export was defined to export
to a bytes IO object in order to work correctly with CSV (which work on
bytes IO for better cross-version compatibility). However the tgz file
export was left opening module's files in `w` mode, which in P3 means
text, which blows up as POFile expects to ultimately write to a bytes IO
object: it uses text, and a StreamReaderWriter is used to translate that
into an underlying bytes IO.
Fix by explicitly opening the files in binary mode.
Fixes#22700
A name_search on attribute line would possibly ends up with a domain like:
['|', ('attribute_id', '=', 'm'), ('value_ids', '=', 'm'),
('attribute_id', '=', 'm')]
which would just search the attribute.
This is caused by calling the default name_search. This commit forgo
the default name_search when we are in this attribute line special case.
courtesy-of: @fmdl
opw-813505
closes#22619closes#22760
Before this commit, when having a simple employee (group employee) accessing the form view
of hr.employee, there was traceback because the field is_address_home_a_company was not in the view
This is because of commit 2d777d5
which restricted this field to the group_hr_user (Officer) in Python
When the view itself is not group-restricted
The JS loads everything from the view but puts invisible=1 on sections that have a group
The field, in our case, is forbidden before that and is not loaded, whereas the domain in which it is used is loaded
After this commit, the view loads correctly, while avoiding leaks as intended
OPW 813721
The data in tests use 'datetime.today()'. This can
add second and milli seconds: if those are not zero,
a 4th day of work will be count (hence the '+1').
The test craches with "3 != 4" when the test was executed
on a 'zero second' time.
As Dr Emmett Brown would say : "Time traveling is just
too dangerous !"
Name of scripts piped to `odoo shell` were `__builtin__` (`builtins` in
python3), which is not really obvious (and awful if your script must
handle python2 and python3).
Change it to `__main__`, allowing to use to common pattern
`if __name__ == '__main__':`
Before this commit, when duplicating a task,
the pad of the original one was updated with plain text
Hence losing all the layout.
This was because, in all likelihood, Odoo's Etherpad server did not support pushing HTML
At the time of the commit, Odoo's pads can receive HTML.
We then push HTML by default, falling back to pushing text as before
if necessary
OPW 806064
Before this commit, when connected as a portal user, the user was not
able to post replies to existing replies. This is because the textarea
section was marked to be displayed for connected internal users only.
This commit removes the whole group restriction. Indeed, it makes sense
(as a fix), to show the textarea section for public users too. Indeed,
the "Reply" button is already shown to public users but does not do
anything. With this commit, clicking the "Reply" button shows the
textarea section for everybody and, if the user is not connected,
redirects to the login page when posting the message. This of course
needs usability improvements in master.
Note: the problem had originally been fixed for regular answers with
commit https://github.com/odoo/odoo/commit/b81b03c82d282dc94595a9beb94444041509ef25
Note 2: both mentioned problems were originally introduced by commit
https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
Closes https://github.com/odoo/odoo/issues/22648
Use `ir.values` for default taxes. Stop using `ir.config_parameter`. The
logic is made in order to be as error-proof as possible.
Backport of a9ede7fdfa
opw-807226
Christophe Simonis