מזל טוב

The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.

Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily

Adapt the css and views to be easier to switch direction

Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language

add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY

This commit brings a new module to handle the automatical
purchasing of services, like stock does but without using
routes.

On a service product, a checkbox need to be check and a
supplier has to be defined. On SO confirmation, a Purchase
Order will be generated.

See commits details for more details.

Task #39340
Closes #25221

This commit adds a new module providing the automatically services
purchasing feature ("Service Subcontracting").

The product of 'service' type can be flag (in the purchase tab of
its form view) as "purchase automatically".
When adding an sale order line with that kind of product, it will
generate a Purchase Order for the supplier of the product, on Sales
Order confirmation. The PO will contains one line with the quantity
on the sale line, with the UoM conversion (purchase uom might be
different from the sale uom on product configuration). The generated
PO is in draft state.

Then several cases can happen:
1/ Increasing the quantity on the sale line
    - If PO is draft state ('draft', 'sent', 'to approve') : increase
      the quantity on the PO
    - If PO is confirmed state ('purchase', 'done', 'cancel') : create
      a new PO
2/ Decreasing of quantity on the sale line
    - in any cases: shedule a next activity on the PO
3/ Cancelling SO: shedule a next activity on the impacted PO
4/ Cancelling PO: shedule a next activity on the origin SO

The introduction of this module required to move the link between
sale.order.line and purchase.order.line from stock_dropshipping to
thie module, and put sale_purchase as a dependency of
stock_dropshipping.

This commit also brings some test cases.

Task #39340
Closes #25221

Now, the style of exception activity depends on
the activity subtype, since a global warning type
exists.

Add a data common for all models have the 'decoration'
type set to 'warning' to schedule alert activities.
This can be usefull when activities are generated on
related model changes.

Task #39340

This commit extends the activity API to allow scheduling
activity with a Qweb template to format the activity message.

Task #39340

Impacted modules: sale, sale_timsheet, sale_stock, delivery and
event_sale

The commit ee2b9fae split the
implementation and the api of the `action_confirm` method of
a Sales Order.

This commit tries to go further:
1/ change this API: the private method is the implementation that
should be extended when the confirmation should generated other
documents. The state change is extract to be sure that in all
override of `_action_confirm` the SO state will be 'sale' (and
not 'done', in case of activating the options).

2/ adapt other module to this new API. Some of them does not required
the change to correctly work, but it can introduce future bugs.
Doing it now is better ;-)

3/ With this new implementation, we can prioritize SO line treatment
on confirmation. We want the stockable lines to be processed before the
service ones. Indeed, the line (service and stockable) that should
create a purchase order (future dev for services) will search for an
existing PO, but stock has more precise criteria than services. So,
service SO line will find the existing PO from stock while the opposite
is not true.
So, this is why we are now calling `_action_launch_procurement_rule`
before the `super`.
The rest of the treatments (event, delivery, ...) depends on the module
loading order.

Task #39340.

This commit dissolves module into sale and sale_stock. Indeed
some fields will be needed for services in next development.
- module is replace by a group in sale
- `commitment_date` and `expected_date` are moved into sale
directly, because they are meaningful for purchasing services
- `expected_date` implementation change when sale_stock is
installed, as the picking_policy of the SO determine if the
min or max dates should be chosen.
- `effective_date` is moved to sale_stock
- tests are moved into sale_stock, and tagged to be executed
after install (post install) otherwise it fails (since
sale_order_dates was a leaf module, it makes sense).

From a functionnal point of view, nothing should have changed,
except that user can see `commitment_date` and `expected_date`
even if sale_stock is not installed, by activating a group.

Task #39340

This is done by displaying this field on top of the vendor bills form view and using it as a default value when registering the payment. The use of a sequence on res.partner.bank also allows giving priorities to partner bank accounts directly from the tree view that is contained in res.partner form. In case payments are generated for multiple invoices at once, their account is set as the partner's most prioritary account.

[IMP] account: payment for multiple invoices: option to group + also group on account + hide memo

Add an option in the multiple invoices payment wizard to choose whether or not to group the generated payments. This is useful in case we want to keep one payment by invoice (even if they share the same partner, etc) so that each of them corresponds to a single communication.

The memo field of this wizard is now also hidden in some cases, when displaying it would allow entering wrong communication values (for example, when paying invoices from different partners ; it makes no sense that all the generated payments share the same memo).

[IMP] account: option to sanize invoice communications

Better stick on pure emojis.

Specification
=============

- Fix lots of bug due to the BS4 migration
- Improve steps
- Validate some steps (Like the company configuration) in all the
  onboarding bars if done in one onboarding bar.
- Only animate the confetti one time if a step is done, instead of
  on each view loading

For more information, see: https://www.odoo.com/web#id=1869513&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720

Rename TIN into Tax ID in company and partner forms.

task: 1869513

Increased amount of magical autodetection of import
parameters (formats, delimiters, ...)

Task 1870663

Id is used in enterprise to add a module inside that view

The file was introduced with BS4 but the name was not well chosen.

* website

The way the bootswatch library import fonts is not the right way so
we must unfortunately apply a fix in the library itself.

Also review the manifest file.

Purpose of this commit is to improve automated activities in fleet.
Currently they are not always updated or rescheduled. Specifically when
updating the expiration date or the responsible automated activities should
be updated accordingly.

This commit is linked to task ID 1838956 and PR #25899.

Purpose of this commit is to improve automated activities in maintenance.
Currently they are not always updated or rescheduled. Specifically when
updating equipment, technician user of schedule date automated activities
should be updated accordingly.

This commit is linked to task ID 1838956 and PR #25899.

Purpose of this commit is to add possibility of rescheduling the assigned
user on automated activities. Currently rescheduling is limited to updating
the deadline. In some cases we want to be able to update the assigned
user of an automated activity.

Tests are added to avoid regression.

This commit is linked to task ID 1838956 and PR #25899.

Make the lunch alerts blocking if ordering a product from a supplier if not
available at the order time

Add mail templates to generate emails to suppliers.

This merge is only a first step before the Big Lunch Refactoring that will
change forever the way peoples are considering eating lunch.

And make sure multiple alerts combine correctly

Confirming orders must now be done per supplier and will open an email
composition wizard with the different orders

Reorganize the fields to clarify the view

Add a field partner_id on a lunch.alert
If the field is set, the alert becomes blocking and will prevent people from
ordering a lunch.

Add a available field on the lunch.product that will check if any alert forbids
ordering that product at the time of the order.

Pass the lunch.order date in the context to be able to plan a lunch order
another day if the provider is forbidden today.

A simple new view to easily display all activity on a model grouped
by res_id and activity_type_id. Some action are possible like sending
a mail template for all record having an activity with this activity type
and present in the view (depends on the filter).

The view use the Kanban activity view on cells. It could be a good idea
to rename this widget to something like "DropdownActivityView" (maybe
after the freeze)

Task: #1870662
PR: #26272

It was possible to define a delay in days on activity type
to reschedule next activity. It is now possible to specify a unit
(days, weeks, months) and a starting point for the delay
(as before, from the moment when the new activity is scheduled,
but also after the deadline of the previous activity).

We realy need to have all javascript action triggering a done
and schedule next to call the python corresponding method on
activities. A part of the work have been there but some
cleaning could still be done in activity.js.

Task: #1870662
PR: #26272

do not compare string and dates

Purpose of this merge is to improve onboarding of Discuss. This is done via
a wow effect and a bot to test the Discuss app; otherwise you have nobody to
talk to. Purpose is also to improve retention as "the best way to increase
retention is this: when the user invites someone, when this guy activates its
account, the user gets a push notification from the invited user that just
logged in; that way he will come back to Odoo and start discussing with its
colleagues.

Concerning your new best friend: it is not a dog but Odoobot.

See sub commits for more details. This merge is linked to task ID 1838588 and
closes PR #25075.

Purpose of this commit is to improve onboarding with a wow effect and a bot
to test the Discuss app. Otherwise new users have nobody to talk to. Retention
will be improved by both increasing interactions and onboarding of Discuss
features.

This commit adds a simple bot in discuss. It answers some questions, helps
users getting their hand on discuss and eases the onboarding.

In this version, the flow is quite simple, and only im_livechat adds some
logic in order to show canned response. The logic is contained in new
modules: mail_bot and im_livechat_mail_bot in order to keep everything
well separated. It also allows users to remove the mailbot if they do not
want to keep this functionality.

Odoobot will only answer if he is in the onboarding conversation (alone
with a user in a channel of type chat) or if a user pings odoobot.

Odoobot logic applies to both standard chatter / channel messages and
also transient messages (like help commands).

Specifications

 * 2 minutes after first sign in, users will receive a direct chat from
   Odoobot;
 * make Odoobot an archived partner;
 * scenario

  * Odoobot: "Hello, I'm here to help you discover chat features. Try
    answering me with an emoji :)";
  * User:  Send emoji
  * Odoobot: "Great! :) Did you notice that you can also send attachments,
    like a picture of your cute dog? Try it!"
  * Odoobot: "Not a cute dog, but you get it :) To access special features,
    start your sentence with "/" (I.E. /help)""
  * User: /help
  * Auto message then Odoobot: "Wow you're a natural! As a channel usually
    contain a lot of users, you can grab the attention with a ping. Try to
    ping me with @Odoobot!"
  * User: @Odoobot lorem ipsum

  * if Livechat installed

   * add 2 demo canned response so it does not look weird (like "Hello, how
    may I help you?" and "Have a nice day!")
   * Odoobot: "Perfect! <br> Try to type ":" to use canned responses."
   * User tries canned
   * Odoobot: "Good, you can customize your canned responses in the live chat
    application. <br><br> + réponse suivante"

 * Odoobot: "There's 3 different ways in Odoo to interact with your
   colleagues:  via this chat window, [img of chat window] via the Discuss
   application [img of Discuss app + icon on it] or via the chatter [img of
   the chatter]. Aaaaand that's it! Enjoy discovering Odoo! :)"
 * random answers to ping/bad answer

  * "Mmmmh I'm not sure what you mean.. Can you try again?"
  * "I'm afraid I don't understand. Sorry!"

 * when someone pings @OdooBot with no reason: Odoobot: Yaaaay that's me!
   [party emoji]
 * fun stuff to add for some answer

  * User: i love you / love
  * Odoobot: Aaaaaw that's really cute but, you know, bots don't work
    that way. You're too human for me! Let's keep it professional <3
  * User: Fuck
  * Odoobot: That's not a really nice thing to say, you know? I'm a bot but I
    have feelings, ok?! </3

This commit is linked to task ID 1838588 and PR #25075.

Purpose of this commit is to improve the onboarding and the first steps of
Odoo notably when using Discuss and inviting first people to join Odoo.

When a new user connects the user who invited him will be notified with
a desktop notification inviting him to have a chat in Discuss and talk
together.

This commit is linked to task ID 1838588 and PR #25075.

Purpose of this commit is to improve the onboarding and the first steps of
Odoo notably when using Discuss and inviting first people to join Odoo.

In this commit we now ask the user to activate desktop notifications. Like
already done in Discuss a message will appear in systray in order to ask the
user to do it. This message will disappear once the user accepts or blocks
desktop notifications.

This commit is linked to task ID 1838588 and PR #25075.

To properly dump it in json

In the kanban view, there was no possibility to add a feedback when
closing an activity this commit adds the same popover as the one we have
in the form view.

This commit also add the templates to this popover with the possible to
directly send the template or open the composer.

Task #1870662
Closes #26280

Make sure that the employee and its user have the same name and image