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
In case an invoice is required to be paid thanks to the route
'/my/invoices/', the user is redirected to '/shop/payment/transaction/'.
If website_sale is not installed, this causes a crash.
Complement of 2bd17285ea
opw-813481
* localized checks layout of US and CA introduced in enterprise
* account settings now install account_check_printing instead of the US checks layout
Wsa PR #18791. Was task 33298
Before this commit, we create a new dynamic action when creating a new
project. This is a problem for various reasons:
- we did not have the nocontent helper properly set (so, the kanban view
could not display the help message just after creating a project
- the dynamic action is slightly different from the one you get when you
click on an existing project (different views, ...)
- the dynamic action is not editable in studio
With this commit, we simply reuse the same action, but with a different
context. This solves all these issues at once, without duplicating
logic.
In a recent commit, the kanban view was changed to display a nocontent
help message, even when grouped. To do that, it was necessary to change
the nocontent structure, and in particular, to position it absolutely.
This totally breaks dashboards.
Also, from a functional point of view, dashboards are used to see
existing information, so it can be said that the nocontent helper is of
a more limited use in this case. Therefore, I think that the best
technical decision is to simply remove the nocontent helper in the
dashboard, rather than fiddling with the css to try to make them work.
Before this commit, it was not possible to display a help message in a
kanban view, if it is grouped. This is an issue, from an onboarding
point of view. Imagine a new user, creating a project. After it
creates a few columns, it is not clear what to do.
With this commit, we display the nocontent help message in a grouped
kanban view, if the user is not currently creating a new column. This
allows the user to focus on its work, by working in phases: first, he is
prompted to create project column, then when he decides that he is done,
the user interface shows the nocontent help message, which guides
her/him to the process of creating a task.
When the user decrease the quantity on the SO it will log the
activity on a the upsteam documents however the user can't easily
find the impacted documents linked to it. In order to achieve that
the _get_upstream_documents_and_responsibles method pass a stack
that remember all the documents browsed in order to return the final
document. This stack is then passed in the _render_method in log activity
in order to use it when rendering the note for the activity.
return the linked requisition line and the responsible for the requisition
instead of returning the origin moves. there should be nothing upper
the requisition itself so we don't need anymore to grind documents in order
to find the upstream one. More information about _get_upstream_documents_and_responsibles
in method _log_activity_get_documents in stock_picking.py
return the production_id and the responsible if it exist on
the move instead of returning the origin moves. We can deduce that
if a production is linked to a move and this MO still ongoing then
it should be the upperstream document.
When the user decrease ordered quantity on a SO, it will log a note
on upstream ongoing document in order to notify the user that the
demand has changed in order to let him react has fast as possible.
Check method log_activity in order to have more details about the
shortcut method used in order to log activity on downstream/upstream
documents
Allow to redirect on a form view when the user click
on a html tag a with data-oe-model and data-oe-id specified.
In order to avoid code duplication the do_action already existing in
mail_thread is moved in the action_manager and mail_thread and mail_activity
use a trigger_up in order to call it.
The purpose of this commit is to create a generic method in order to
log an activity on following documents or on upstream documents in order
to avoid code duplication.
In order to use it, you have to:
- create a static method in order to generate the string
for the note (it will use an arguement with the format
{'dest_object': ['orig_obejct', (new_qty, old_qty)]}
- 'DOWN' to notify following document. In this case you
have to specify a groupby/sorted method.
- 'UP' to notify upstream document. In this case you have
to specify a specific method call
'_get_upstream_documents_and_responsibles' on the object to
ride up.
Log_activity's operating mode:
destination objects = self.stream_field(passed as arguments)
'DOWN' group destination objects by document on which we want
to log the activity and a responsible to assign.
For each pair (document, responsible) generate a specific note
with only the information relative to object that belong to the current
document. Once the note is returned, it logs the activity on the
document and assign the reponsible.
'UP' instead of sort and group runs the method
'_get_upstream_documents_and_responsibles'. For example on moves
this method is called recursively on all moves orig that are not done or
cancel until it can't find a valid one at this moment it returns its picking.
Then generate the note and log the activity the same way than 'DOWN'.
Fabien Pinckaers