Users can now copy existing dashboards to create backups before making changes. This addresses a common need where users spend significant time building dashboards and want to preserve their work while experimenting with modifications. The copy functionality has been added to the dashboard editing interface.

Purpose
-------

There's currently no way to copy a dashboard. If you spent 1 week building
a dashboard then want to change it but without risking to break and loosing
everyting, you probably want to copy it "as a backup"

Task: 3588237

Forward-Port-Of: odoo/enterprise#51678
Forward-Port-Of: odoo/enterprise#50480

This fix resolves an issue where the Mass Produce feature was being incorrectly restricted in the manufacturing backend due to new Shop Floor limitations. The system now properly distinguishes between backend and shop floor requirements, allowing full Mass Produce functionality where needed while maintaining appropriate restrictions in the Shop Floor interface.

Shop Floor introduces a restriction on how the show_serial_mass_produce flag is computed :
the components cannot consist of more than 1 lot/serial.

However, this has a side effect on backend views where it is still required to have full 'Mass Produce' functionalities.

The "I am unavailable" button was appearing in multiple menus when it should only be visible in the "My planning" menu. This fix adds a condition to hide the button from other menus, ensuring users only see it in the correct location where it's intended to be used.

Description of the issue: I am unavailable' button should only be visible in the
'My planning' menu.

Desired behavior after PR is merged:
Button only visible in My planning menu,it will invisible from other menu.

Fix:
condition added to button if particular context not found make button invisible

task-3280805

Forward-Port-Of: odoo/enterprise#51396
Forward-Port-Of: odoo/enterprise#43365

This fix resolves an issue where users encountered an error when trying to invoice already-paid orders in the POS Restaurant module for Mexico. The problem was caused by missing order information in a popup dialog. The fix ensures the order data is properly passed to the system, allowing invoicing of paid orders to complete successfully.

Prior to this commit, attempting to invoice a paid order in the POS Restaurant module would result in an error due to 'selectedOrder' being undefined. This issue was observed when trying to process the invoicing of an already paid order.

This commit resolves the issue by ensuring that the order is passed as a prop to the AddInfoPopup.

opw-3590978

Forward-Port-Of: odoo/enterprise#51315
Forward-Port-Of: odoo/enterprise#50818

The Easypost shipping integration had an issue where the carrier type dropdown appeared empty even though the API was working correctly. This was caused by recent framework changes that affected how data is stored. The fix implements a custom interface component that properly retrieves and displays available carrier options, restoring full functionality to the shipping carrier selection process.

Task: 3596494

After "viewtiverse" changes in 17.0, many values are no longer stored in context. That includes carrier types obtained from Easypost API calls. The result is that, even though the API call is successful, the carrier type dropdown is empty. After discussing this issue with both framework teams, a solution was chosen: implement a small custom widget, which will extract the available carrier types in JS (where all context values are still present).

This fix prevents the social tour from being unintentionally marked as completed when users haven't actually gone through it. The issue occurred because tour steps were unnecessarily tagged as "enterprise-only," causing the system to mark the tour as done if it couldn't confirm the enterprise edition. This fix removes those tags so the tour functions properly regardless of how the system detects the edition.

Currently, the social_tour tags all its steps as "enterprise". This is unnecessary as this tour is only present in enterprise, but can cause an unintended side-effect: from the point of view of the tour system, if a tour contains no steps that match the current edition, it will consider the tour complete and mark it as consumed/done.

If a page loads the tour service, but doesn't load the necessary information to allow the tour service to know that it is in fact running on an enterprise edition database, and the user visits that page, the tour will be marked as consumed even though the user hasn't gone through the tour.

In practice, this happens on the livechat QUnit suite which does not care whether the edition is enterprise or community. In this specific case, the rpc service is mocked and the route is not implemented by the mock causing a crash, but a similar problem could occur on a different page with a similar effect: either a crash, or unintentionally consuming the tour.

This commit fixes that by untagging the steps as being enterprise. If the tour is present, all steps should run.