When fetching the invoices linked to a sales order,
the system looked for all refunds which had an 'origin'
field that was the number of an invoice of this SO.
That's nice, except that invoices that are not yet
validated do not have a number, which caused sales
order with an uncofirmed invoices to be 'linked' to
all 'out_invoices' that had no origin (which could
be 1000+ for a substantial db) (basically all out
invoices which had the origin field set to false)
This commit simply extends the domain to exclude
refunds that did not originate explicitly from one
of the SO's invoices.
m2m_tags inlist editable view try to get color on validation, the field is invalid because the mutex is pending.
Fix: don't re-render the fields
Issue: steps to reproduce:
- Create a new instance, install "sale"
- Create a product "prepayment", service, invoice on ordered qties
- Create aproduct "project phase", service, invoice on delivered qties, manually track delivered qties
- Create a SO with once prepayment, and twice a line with "project phase". ( the name (description) of the lines should be "phase 1" and "phase 2" )
- Create invoice => The prepayment is invoiced
- Go back to the SO, try to change the delivered qties of the first phase to 1
- Save => error, odoo doesn't let you save.
Missing context in call to render the planner leading to untranslated planner.
Use the session to get the user context as outside of the view manager.
opw 660627
When there is no lang set, format_tz uses server locale to format a
date. If my server is in French, date is formatted using '%B' (full
localized month name). This can lead non-ascii strings like
"décembre"...
When creating a new `account.account`,
or writing on an existing one, changing the
`type`, the source of the related field
`internal_type`, `user_type_id.type`, was
re-written (re-stored) because the field
was not read-only.
In addition, the re-store of the value
of this field triggered the re-store of the related
field `internal_type` on all other `account.account`
records using this `internal_type`, which leaded to:
- Performance issues
- Potential access rights issues, if this leaded
to write operations on records to which the user
does not have the access (multi-company rules, among others)
Forcing the field as read-only allow to not pass the value of this
`internal_type` from the web client to the server when
creating or editing an `account.account`.
Besides, the field is required in the view, to correctly trigger
the according onchange method:
```
@api.onchange('internal_type')
def onchange_internal_type(self):
```
opw-660292
Closes#10143
Analytic accounts are inherited by project.project, and in some cases it is useful to have a link from the account to the project.
This is a usability-fix, not a code-fix
When an expense is recorded and linked to an analytic account, the
associated line will appear in the timesheet.
This fix links prevents linking an account analytic line to a timesheet
sheet if the line is not a timesheet.
Somehow related to a4b6e3a8
opw-657917
If the kanban view is loading grouped records, the dataset of the view
itself is the concatenation of the dataset of each groups.
But when using "Load more..." on a column, these records are not added
in the view dataset which is thus desynchronised. This could lead to an
error down the road.
closes#10156
opw-659016
When inheriting from a view in extension mode created in the same module, this
view was not loaded during check_xml of the last view.
This caused an error when the last view wants to modify elements added
by its direct parent view.
Example :
- View1, created in module "account"
- View2, mode extension, created in module "customer", inherits View1
- View3, created in module "customer", inherits View2
During update of module "customer", when loading View3, the check_xml
call didn't load View2, because it's defined in the same module (and,
obviously, this module has not be totally loaded at this point)
This is fixed by adding direct parent of each loaded view in the
check_view_ids list in context, to force them to be loaded.
Closes#9135
This revision is related to 7be2403cf5
The payment acquirers must be fetched if the quote
needs a payment.
Besides, as explained in the above revision, the state
`manual` no longer exists sales orders, and therefore
this must no longer be used to determine if a quote
needs a payment or not.
opw-660575
1. To change the page title, you now have to call
`set_title` from `require('web.web_client')`
2. Without the `type="button"`, the `Change Password`
button is regarded as a `type="submit"`, therefore
submitting the form, on `web` on click,
and `web` doesn't expect this POST request.
The POST request must be done on
`/web/session/change_password` only.
opw-660567
Each time the quantity of a product is changed, the price must
be updated according to the pricelist of the user.
When the price given by the pricelist is less then the unit price
of the product, the reduction of the price must be displayed.
A not stored computed field is added in model "sale.order.line"
to compute the discounted price because when the module
product_visible_discount is installed the price unit of a SO line
is the full price of the product and the discount related to the pricelist
is written in percent in the field discount(function "product_id_change"
in addons/product_visible_discount/product_visible_discount.py).
opw:660178
- A simple POS user doesn't have the rights to write
on pos.config, not even to write the `current_session_id`,
so it must be done as sudo.
- If no fields is specified to `search_read`, it reads all fields.
The simple POS User cannot access all fields on `account.journal`,
(e.g., the computed fields implying `account.payment` records)
opw-659079
This revision is related to 432f199.
Since the above revision make sure to change the
editable list to `bottom`,
the order of the list should be done on the `date` (asc),
on this view, as this is more likely that, when adding a new line,
that the date set on this new line is
more recent than the dates on the other lines.
The new added line should therefore appear directly at the bottom
of the list, to avoid consufing the user.
Besides, the default order of the model `account.analytic.line`
is set to `date desc, id desc`
opw-659892
After initial implementation CSRF protection had been left poorly
documented tripping up users and developers (#9538, #10139).
Add a warning in the logs for developers, and a more extensive
explanation of the whole thing in the @route docstring (and the official
documentation).
Fixes#10158
user_has_groups is used to check for groups in e.g. view attributes (`@groups`).
When trying to format lists of groups in views, it would break down as it would
pass e.g. `\n some.group` to `res.users.has_group`, which would look for
an xid with the module `\n some` and (oddly enough) not find it.
Theoretically could also handle that inside res.users.has_group but it seems
ever-so-slightly more risky, and has_group is only used programmatically and
should thus already be called correctly.
fixes#9797
Models' write function has a return value which was not propagated when
overriding it for ir.ui.view in website_version module.
opw-658965
note: fix was already present in enterprise f0975cb
in `view_pivot.js`,
the method `view_loading` must wait the `self.fields` variable
to be defined before working properly.
This `self.fields` variable is filled in the `prepare_fields` method,
which is called in the `start` method, through a deferred named
`load_fields`.
`view_loading` is called in `start`, in `views.js`.
Therefore, in the overriden method `start` of `view_pivot.js`,
the call to `_super`, calling the `start` of `views.js`, must wait for
the `load_fields` deferred to be resolved.
Otherwise, the `self.fields` variable, mentioned above, won't be
filled in time.
opw-660153
If no timezone was defined for the user,
the timezone sent to Google for the events
syncrhonization was set as `False` instead
of the right default value `UTC`
opw-660171
Before this the only thing that would ever be printed was 'Guests: ',
because it was only added when receipt.customer_count evaluated to
false. Another issue is that receipt.customer_count doesn't exist in the
point_of_sale module. It is created by pos_restaurant, so there's where
it should be added to the receipt.
- The revision 950d66c086 brokes
the current inheritage. We replace it with a stronger inheritage.
- If the product is not published, the portal user cannot access
it on its product page `/shop/product/`, there is therefore
no need to set the link to this page.
opw-660191
Damien Bouvy