When creating an invoice in a foreign currency,
and adding a line with a product,
the `onchange` failed,
due to the fact the field `date_invoice`
is not on the invoice line, but on the invoice.
In 6b55539dc7 the "container_row_stock"
group in stock.view_partner_stock_form was hidden using
groups="base.group_no_one". The issue is that the POS used a group
inside of this group that it modified to display the associated
barcode of the partner and the loyalty points of the partner. So
although the code still worked, the actual information was invisible.
To fix it we inherit the view directly from where it is created, namely
base.view_partner_form which is a bit nicer than inheriting from an
already inherited view.
The ISO weekday should be computed with isocalendar dateformat
The exact directive is '%V' according to GNU/Linux system strftime
http://man7.org/linux/man-pages/man3/strftime.3.html
However '%V' is not documented in official cross-platform syntax supported on
all python built, according to standardized by ANSI C formats
https://docs.python.org/2.7/library/datetime.html#strftime-and-strptime-behavior
as '%V' may not be supported on other platforms such as MS Windows, use the
cross-platform 'isoformat()' method.
Note that according to ISO 8601, the start and end of date may belong to the
previous or next year.
e.g.
>>> datetime.datetime.strptime('2005-01-01', '%Y-%m-%d').isocalendar()
(2004, 53, 6)
>>> datetime.datetime.strptime('2005-01-01', '%Y-%m-%d').strftime('%W')
'00'
Fixes#8927
In e9c6fd0 'accuracy' was added to the field list read for res.currency,
but since the accounting refactoring in 9.0 (c04065a), this field was no
more present (replaced by decimal_places).
Since this field in the current point_of_sale javascript code was never
used, this commit removes it from the field list.
sentry-32303830312e3239303433353734
Inspired from template product_price and product_lst_price in addons/website_sale/views/template.xml
because the price displays in this template must be the same in the website_sale_options.modal
opw:652209
The project and sale_timesheet modules both define a project_time_mode_id field on res.company but they are not dependent on each other. This causes problem because the first module that creates the field "wins" the xmlid and will delete the field on uninstall, regardless of the other module (which will then stop working until you do an update that will recreate the field).
To work around this in a stable version, we manually create xmlids for the field in each module; on uninstall the field will not be deleted if an xmlid still refers it (which will be the case if the other module is installed).
Inheriting fields from modules that are not dependent in a direct way (ancestor-child) is not supported, so normally you should use modularity to define the field in a parent module. Since 9.0 is a stable version, we need a small workaround.
When clicking on a partner in the thread of messages, it opens the DM with the
associated user if there is one (and if this user isn't the current user).
Otherwise, or when clicking on a record of any other model, the user is
redirected to that record's form view.
This change required a minor change in chat_manager: create_channel now
returns the created channel, as the client action needs it to switch to it.
Moreover, in the thread, when there is no partner associated with a message
(only an email address), we simply use html's mailto mechanism. This fixes a
bug as we formerly tried to open an unexisting record of res.partner.
The bus was allowed to restart polling, client side, to allow the user
to directly receive messages in new channels. This was only acceptable
as a temporary fix, the correct way to do this is to actually notify the
bus server side. This is even more urgent since the client was allowed
to keep multiple longpolls simultaneously, which degraded the experience
in some cases.
Channel types that disable the 'add a channel' feature like the livechat are
now only rendered in the sidebar of the client action if there exists at least
one channel of that type.
If a user does not have write permissions on a model, he should still be
able to remove himself from the many2many relation.
This caused a problem: some messages could not be modified by a user
(star/unstar or mark as read)
... from the same author, written within 1 minute (restricted to comments).
Also:
- Display stars and needactions on hover only
- Display the date of messages without avatar and info in the margin on hover
- Add 'selected' state of messages (mainly for touch screens to replace hover)
- Fix typo (msg_type -> message_type) on the computation of the avatar url
On firefox, the font-family of the counter was font-awesome instead of Roboto
because the counter was inside the <i> tag on which font-awesome rules applied.
This rev. simply moves the counter out of that <i> tag.
including:
- decrease vertical spacing between user name and text
- decrease vertical spacing between messages
- align avatar width with first line of message
- bold channels more visible (color is actually white)
- decrease online status icon size and change its color
- hide the DM unpin icon, and show it only when hovering
- the add channel icons are less white
- offline user icon is now white
- the unpin icon is now visible when hovering on user name
- correctly display notifications in inbox
Inspired from template product_price in addons/website_sale/views/template.xml
because the price displays in this template must be the same in the website_sale_options.modal
opw:652209
When making on model A a read_group with groupby equal to a many2one field F1 to a model B
which is ordered by a inherited not stored field F2, the group containing all the
records from A with F1 not set was not returned.
Example:
model A= "hr.applicant"
model B= "res.users" (_order = "name,login")
inherited model= "res.partner"
field F1= "user_id"(to "res.users)
field F2= "name"(inherited from "res.partner")
In this example, the query generated by the function "read_group" was:
SELECT min(hr_applicant.id) AS id, count(hr_applicant.id) AS user_id_count , "hr_applicant"."user_id" as "user_id"
FROM "hr_applicant" LEFT JOIN "res_users" as "hr_applicant__user_id" ON ("hr_applicant"."user_id" = "hr_applicant__user_id"."id"),"res_partner" as "hr_applicant__user_id__partner_id"
WHERE ("hr_applicant"."active" = true) AND ("hr_applicant__user_id"."partner_id" = "hr_applicant__user_id__partner_id"."id")
GROUP BY "hr_applicant"."user_id","hr_applicant__user_id__partner_id"."name","hr_applicant__user_id"."login"
ORDER BY "hr_applicant__user_id__partner_id"."name" ,"hr_applicant__user_id"."login"
which always returned "hr.applicant" groups of records with a "user_id" set due to the inner join maked on res_partners.
This inner join on "res_partner" is coming from function "add_join" calling by "_inherits_join_add"
in _generate_order_by_inner.
Introduced by dac52e344c
opw:651949
To avoid running procurement in exception or cancel state.
Before the fix:
After cancelling a MO, when recreating the delivery order linked to the sale order in state
"Shipping Exception" the system generated 2 more copies of MO (1 Extra) instead of just one
for the cancelled MO.
After the fix:
Just one MO is recreated for the cancelled MO.
opw:650395
Follow-up of 5ac77c9 which solved the issue when an association was
selected, but not when "All Members" was choosen.
Before this commit, the displayed membership lines would only be the
paid ones, if an association (membership product) was selected. With
this commit this is also the case when no such association is selected.
This commit also correct the member counts in the "country" list :
* with "All members" the free members were not in the counts,
* with not "Free member", the counts didn't took the eventual current name search.
closes#9083
opw-648627
When making on model A a read_group with groupby equal to a many2one field F1 to a model B
which is ordered by a inherited not stored field F2, the group containing all the
records from A with F1 not set was not returned.
Example:
model A= "hr.applicant"
model B= "res.users" (_order = "name,login")
inherited model= "res.partner"
field F1= "user_id"(to "res.users)
field F2= "name"(inherited from "res.partner")
In this example, the query generated by the function "read_group" was:
SELECT min(hr_applicant.id) AS id, count(hr_applicant.id) AS user_id_count , "hr_applicant"."user_id" as "user_id"
FROM "hr_applicant" LEFT JOIN "res_users" as "hr_applicant__user_id" ON ("hr_applicant"."user_id" = "hr_applicant__user_id"."id"),"res_partner" as "hr_applicant__user_id__partner_id"
WHERE ("hr_applicant"."active" = true) AND ("hr_applicant__user_id"."partner_id" = "hr_applicant__user_id__partner_id"."id")
GROUP BY "hr_applicant"."user_id","hr_applicant__user_id__partner_id"."name","hr_applicant__user_id"."login"
ORDER BY "hr_applicant__user_id__partner_id"."name" ,"hr_applicant__user_id"."login"
which always returned "hr.applicant" groups of records with a "user_id" set due to the inner join maked on res_partners.
This inner join on "res_partner" is coming from function "add_join" calling by "_inherits_join_add"
in _generate_order_by_inner.
Introduced by dac52e344c
opw:651949
rev 6327cda0a tried to workaround the fact that the assets bundle were
unreadable when they are created in the same request by opening multiple
cursors and commiting the writes in ir.attachment. Sadly, this strategy
introduces sometimes hard to reproduce and hard to understand deadlocks
when regenerating the assets. This commit tries a ~safer strategy by not
opening multiple cursors but commiting the writes in ir.attachment when
a magic key is in the context.
In some complex use case of a workflow instance with several workitems,
a given workitem processing could itself somewhat recursively process
one of the following workitems.
This situation was currently not taken into account, so in that given
case, the already processed workitems would be processed again.
opw-647580
When reading the view
`account_analytic_analysis_summary_user`,
through the function fields using `_analysis_all`,
it could lead to an
`integer out of range` if you have a bunch of
`res.users` and or `account.account`. Casting
the multiplication of the integers to a double
solves the issue.
opw-652152
Denis Ledoux