Default value of interval_number and number_per_interval was overriden
and set to 0 by _onchange_holiday_status_id this would then crash at
creation because of the sql constraint.
In the form view of allocations, the duration label was duplicated,
solution was to remove labels and simplify the view.
Browsers accept it as they are wont to do, but the Content-Disposition
lib (introduced in 35d452cffb) does
not. Simply don't mark them as safe when %-escaping the filename so
they do get %-escaped properly.
RFC5987 states
ext-parameter = parmname "*" LWSP "=" LWSP ext-value
ext-value = charset "'" [ language ] "'" value-chars
value-chars = *( pct-encoded / attr-char )
attr-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "&" / "+" / "-" / "."
/ "^" / "_" / "`" / "|" / "~"
; token except ( "*" / "'" / "%" )
Neither : nor / are in attr-char. This is further confirmed by
checking out RFC2616:
CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
Here we can see "/" and ":" are both in "separators", which are
specifically *not* in token. attr-char restricts token further, so an
invalid token char can't be a valid attr-char.
This commit:
1. Adds settings to install the new `web_unsplash` enterprise module.
See counterpart commit on enterprise for details.
2. Export `ImageWidget` and `update_control_panel` to be able to override them.
3. Add the unsplash access key rights to website designer. (see related OE
commit)
task-35060
Closes#25825, closes#25637
Currently due to technical reasons all activities are created using the
superuser. It means we have no idea who created an activity. This
commit fixes that by adding a field used to store the activity creator.
It is also displayed in the vignette displayed in chatter giving details
on the activity.
This commit is related to task ID 1865557. Closes PR #25842.
Several addons (account, sale, purchase) use specific 'send by email'
templates to send the invoice / SO / PO to the customer as well as
holding a view / payment button.
Purpose is to separate the template content (payment information) from the
payment button (Pay and sign online) when sending those documents by
email. Composer and chatter should not hold the button. It should be added
only in notifications emails.
Technical solution is to move the button into the notification template.
Model template holds the content (document and text) and notification
template holds the payment button.
This merge is related to task ID 1860049 and closes PR #25824.
Purpose
* use the new notification template allowing to display the payment button
only in emails;
* reorder the fields definition to ease the reading;
* slightly clean the email body using a maximum of div and br tags as it
seems better integrated with Odoo edition capabilities;
This commit is linked to task ID 1860049 and PR #25824.
Purpose
* use the new notification template allowing to display the payment button
only in emails;
* reorder the fields definition to ease the reading;
* slightly clean the email body using a maximum of div and br tags as it
seems better integrated with Odoo edition capabilities;
This commit is linked to task ID 1860049 and PR #25824.
Purpose
* use the new notification template allowing to display the payment button
only in emails;
* reorder the fields definition to ease the reading;
* slightly clean the email body using a maximum of div and br tags as it
seems better integrated with Odoo edition capabilities;
This commit is linked to task ID 1860049 and PR #25824.
In the demo data, some requests for quotations are linked to the demo
purchase tender, but this one is in draft state. It is inconsistent with
what can be done in odoo, because draft purchase tender never generate
requests for quotation.
TASK-ID 1864372
This commit introduces a new notification template. Its target is to be used
when sending payment-based templates like 'Send by email' for sale orders,
invoices or purchase orders.
Purpose is to separate the template content (payment information) from the
payment button (Pay and sign online) when sending those documents by
email. Composer and chatter should not hold the button. It should be added
only in notifications emails.
Technical solution is to have a somewhat-generic template available in mail
to be used in some specific actions. Another solution is to hide the
button but it breaks if people edit or remove the hidden content when
editing the mail in the composer without knowing it. As the button is
mandatory in those actions we choose to have it added by the notification
email.
Future commits will gradually use this template in some addons.
This commit is linked to task ID 1860049 and PR #25824.
Currently if a partner has a void email, its email_formatted field holds
a value like "Raoul Grosbedon <False>" which is quite rarely considered
as a valid email address.
Minimal fix for this field is to return a void value if there is no email.
Having a void return is easier to manipulate for callers in order to
handle it.
This commit is linked to task ID 1860049 and PR #25824.
When you click on put in pack in a ppicking, you can uncheck the
checkbox 'Done', this doesn't have any sense, and doesn't do what you
expect. So the checkbox is always checked for new packages, and you can
simply click on the dustbin to cancel your put in pack.
When a package level is confirmed and is set to done, if you try to
reserve it after, it won't have the correct location of the reservation
because there are still move lines (forced) with the wrong location.
When the move lines reserved are assigned to a package level, it wasn't
taking into account the package level of the parent move if it has any.
So this could lead to package level state error, if we have two package
level with the same package_id.
Due to this commit: https://github.com/odoo/odoo/commit/ab5fcb29650349fa641c6130bf6dcbdc1ec28a07
When confirming a PO with two lines having the same product,
the stock moves were not merged anymore in the putaway
(input to stock) picking.
Reason:
When confirming the PO, odoo creates first a receipt
(vendor to input) picking and its stock moves matching the PO line.
Then it applies the push rule on each move. Both putaway
(input to stock) moves are created by copying the receipt
(vendor to input) moves, but when the second is created,
odoo check if there's another move to merge sharing same
properties to merge into it. As purchase_line_id is now copied
in both cases, both putaway moves include a different
purchase_line_id and won't be merged together, since this field
is in _prepare_merge_moves_distinct_fields() on stock.move.
opw:1854387
Usability improvement:
- Common view for push and pull rules
- Add an help text in order to describe the rule
- Rules menu
- Warehouse checked by default on route created by a warehouse
- Lower the MTO route sequence in order to take it first.
- Tooltip cleaning
Technical improvement:
The purpose of this task was also to merge stock.location.path(push rule) and
procrement.rule. Those two model were design to execute the same task
but in a different direction. Thus it contains duplicate code.
Task ID 1852969.
`new_landed_cost_value` was added to `value` to recompute the
`price_unit` field. The issue is that when applying multiple landed
costs, `value` and `new_landed_cost_value` already contains the previous
landed costs, resulting in an erroneous `price_unit`.
This patch only adds `cost_to_add`, which is the current landed cost, to
`value`, which contains all the previous one.
To reproduce:
- Create a product FIFO / AUTOMATED
- Purchase 50 units@$2 and receive them (total value=$100)
- Add a landed cost of $100 on those 50 units and a landed cost of $50 on those 50 units
(total value = $100+$100+$50)
- Sell 15 units (the value on move out =$75 > $75/15 = $5 unit cost)
The standard_price on the product = $7 while I expect to have $5
opw-1867002
*: im_livechat, im_support, website_livechat
Improvement on top of this commit: https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
=============
Improvements:
=============
1. New thread models "abstract threads" and "website livechat"
new modeling:
0..1 0..1
AbstractThreadWindow <-----+
|---> Abstract Thread
AbstractMessage <-----+ / \
* * / \
/ \
Thread Website Livechat
/ \
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread is used in the backend, while Website Livechat is used in the frontend.
- The main distinction is that Thread relies on mail_manager, while Website Livechat doesn't.
2. Thread widget has its file renamed (from thread.js to thread_widget.js)
3. Most templates in thread.xml now handles Abstract thread
==========
Bug fixes:
==========
1. [FIX] Mail failures from channels were not grouped together.
2. [FIX] Channel names in the discuss sidebar were displaying their escaped representation.
3. [FIX] Thread was rendered several times when receiving a new message.
=======
Others:
=======
1. Removed unused code.
2. Fixed some classnames and corresponding style.
The style for preview info in the systray were incorrect.
Also, mailbox had the old classname ('o_channel_name'), instead of the new one ('o_thread_name')
When the user creates a channel by providing a name, the name is escaped
in order to avoid XSS attacks. As a result, the logic make use of escaped
string, which may be different from the provided string by the user.
As a result, if we do not unescape the string when necessary, the user may
see the escaped version. For instance, if we creates a channel named 'R&D',
it may display 'R&D' to the user.
This commit plays safe by still keeping the handling of channel names in
their escaped form, but unescape it just before displaying it on the sidebar
of the Discuss app to the user.
Since mailboxes are added after the rpc 'mail/init_message', the translations
are loaded. Therefore it is not necessary to lazily load the translations.
Before this commit, mail failures were correctly grouped in the
systray messaging menu, except for mail failures coming from channels.
This commit fixes grouping for mail failures from channel.
When a new message is received and discuss is not open, any chat thread
containing this message is detached. However, if the thread is already
detached, it should not be detached again.
When we add a new message, it should re-render the thread only once.
The `addMessage` function must handles new messages and updated messages.
Some code for updated messages should not be executed for new messages,
which is what this commit does.
- Cleaning website livechat window so that some behaviour are in website livechat instead.
- More shared code in abstract thread / abstract thread windows, thanks to the
introduction of website_livechat model.
In im_livechat, it now handles a {mail.model.WebsiteLivechat}.
Note that this website livechat model is dumb with messages: it stores messages
just before rendering, because this is im_livechat that handles messages.
This should be improved in the future.
Make use of a website livechat model, so that im_livechat can make use of this model.
This provides an almost similar model for threads in the backend and in the frontend.
As a consequence, im_livechat and website livechat windows have been adapted to handle
a website livechat model.
* = im_livechat, im_support
- thread widget now uses abstract thread in `render` method
- thread models have their `init` parameters changed, so that the parent may be optional
- reworked 'creating a new record...' in chatter in create mode:
> new model CreateModeDocumentThread, which basically is a fake document thread
with a fake message for its rendering in create mode of the chatter
> special rendering method of thread_widget for such case: `renderChatterCreateMode`
- renamed thread methods previously named `getMessages` to `fetchMessages`:
> in order to not conflict with `getMessages`, used for rendering
> now, `getMessages` always get messages that are locally,
while `fetchMessages` may fetch messages.
TODO:
- special thread model for im_livechat (rendering is broken ATM)
The intent of this class was to have all mail model be RPC/service calls out of
the box. This is a bit overkill for just 2 lines per new mail models, which is
why this is not used at all.
RomainLibert