Before this commit:
To know if an event menu is an auto generated one (eg: location, register..),
it checks if the menu name is the same as the hardcoded one in
_get_standard_menu_entries_names.
If user change the menu name, the code won't retrieve it and will act as if the
menu had been deleted and it will recreate it.
This leads to 2 bugs:
*First (website_event)
- Change menu name from website_event (eg: location, introduction or register)
- Check/Uncheck 'Track on website' or 'Track Proposals on website' to force
the code to rewrite missing menus.
- Go back to the event front end, theses menus have now been recreated, and
are duplicated.
*Second (website_event_track)
- Check 'Track on website' on event's back end
- Change the 'Talks' menu name in front end
- Go back to backend, 'Track on website' is unchecked because
_compute_website_track won't retrieve an event menu named exactly 'Talks'
Now:
We don't use euristics to try to recover missing menus.
We just create related menu when option is checked, and we delete them when
option is unchecked.
To know which menu item comes from which option, we store a value in a new
model 'website.event.menu'.
We don't want to try to check if the menus are all there and recreate them if
needed anymore. There is cases where user wan't to delete a menu and repace
it with a link to that menu's URL in the page content.
Before this commit, the option would've been unchecked since it won't
retrieve the menu.
This technical dependency module adds settings to res_company for the
company's social media pages.
It is introduced to fix duplicated fields for res_company in website and
mass_mailing, these two modules now require social_media as a dependency
Add the context manager method `assertQueryCount` to count queries,
the decorator `@users(...)` to execute a test for several users, and
the decorator `@warmup` to execute a test twice (warm-up, then real).
Creating data directly in tests was done when tests were located in mail
module to avoid creating real data or demo. Now that mail tests have their
own module we can create demo data and use them in tests. It is simpler to
have demo data for things like subtype and email templates to ease
understanding and reuse.
Before this commit, an user could not create or remove a website.menu since
there was no list/form view for it. Changing sequence also impossible.
Therefore, it was impossible to create or delete a menu from an event. (you
could just edit the existing one)
Now, user can access in debug mode to the list and form view of website.menu to
manage the menus.
This commit also add a link on the ir.ui.view form view to access it's related
website.page
This closes#21302
Impacted modules: rating_project, project, sale_service_rating,
website_rating_project and rating.
This merge remove some small modules to integrate them
directly into big one; indeed, we wanted to set rating as
dependency of project module.
As consequence, we see:
- rating_project is removed (its features) are included in
project, hidden with a group
- sale_service_rating is absorbed by sale_timesheet
- website_rating_project is moved into project too, so the
rating page does not depends on website anymore
No feature change, simply moving code, and reorganize some ;)
Displaying the rating of project is moved directly
in project module, since it does not depends on website.
User may want to display rating of its support project
even without website.
Since rating in on project directly, and task
and issue are merged, we can simplify some domain
and replaced them by default filters.
The search domain will be less complex and the
performance will be better.
Impacted modules: project, rating_project,
sale_service_rating and website_rating_project.
Removed modules: rating_project and sale_service_rating.
Move code to empty 'rating_project' module, in order
to kill it.
Code is not modified, simply copy/paste at the right
place in 'project' module code.
However, 'enable rating on task' options is convert
into a res.groups that can be activated from the
project settings.
Customer portal is not dependent from website anymore. In this commit we
move customer portal code related to sale stock directly in sale stock
instead of website sale stock.
When making a SO with a stockable product with an expense policy set,
confirming
the SO will increase the delivered quantity according to the validated
picking. But
when unlocking and modifying the ordered quantity on picking the
delivered quantity
on SO does not change (it is if the product have no expense policy).
So the expense policy influence the flow in a way (update validated
picking) but not
on the the other (confirm SO) to compute SO line delivered quantity.
This commits make the expense policy not relevent when modifying ordered
quantity
on picking.
It also prepare the cleaning to unify API of delivered quantity
computation on SO
line for stock and service.
Since partner is not required on analytic account, nor
on AAL, we may have lines related to different partner (a 'support'
project for instance, with task for different partner, the AAL will
thus also have different partner). This use case is not possible with
the field override in account.
This commit will allow to do cost analysis by partner in the same
analytic account.
When installing account module, some field semantic on AAL
changed. Indeed this module modify some concept for its own
use cases.
Since analytic accounting is only used inside the company,
there is no interess to have the amounts stored in both
currencies. So the fields amount_currency, analytic_amount_currency
and company_currency_id can be removed. Doing that, we remove the
unfair related of account module.
Since quantity to invoice and quantity invoiced
already take into account refund invoices, the
calculation of those amounts can be simplify.
Also, we simply need those on the sale.report,
so removing them from sale.order.line model
will ease performance.
If an user (or a developer) wants to install this module twice, she
could not before this patch. Because those demo data call a function
that crashes if the state of the demo data has been modified... and
modifies it!
We avoid this issue by resetting the states of the demo data
explicitely (before a deeper refactoring)
This commit improves and cleans the project rating page;
- statistics of top 5 rated in last 15 days in right column of the page
- move progress bar for tasks on right side of the page
- show the detail of a rating when mouse hovering on the smiley
Since the page is refreshed, the statistics computation is done
with a single SQL request to extract all raw data to calculate
period and partner stats to display.
Thanks to @ror-odoo for the first implementation and to @jem-odoo for its review
Purpose
=======
Users often log an activity and want to schedule another one immediatly.
We should limit the number of clicks
Specification
=============
- Mark as done should be a secondary button
- Add a new secondary button : DONE AND SCHEDULE NEXT
- It should mark the activity as done and close the modal
- It should open a new activity modal
Behavior and available options are now the same in the Chatter modal and
the wizard itself. It implies correcting the crm_tour flow
When an error happen (which may have been intended as such and ignored
down the error pipeline) in google_account/google_calendar there was
some typos that tracebacked.
opw-783271
closes#21263
Containing
* fix self._round not always existing;
* fix counter for activity creation;
* use self.str() in order to have some variation in test_mail;
* separate base performance to mail feature specific performance tests;
This commit add an icon for each people that worked on the Wo
and also
a play icon if the WO is in progress
a pause icon if the WO's workcenter is blocked.
This commit basically reverts 4974f8edb7
The fix was unstable (as restoring a feature that was not there
before release, even if originally merged before). This was in
particular breaking saas modals as lots of them are still opened
using 8.0 system... and opening them this way might make them appear
below their own backdrop in the new system the mentioned commit
restored.
We will think about that feature again for a future version.
When installing the module pos_restaurant with demo data, the check boxes for
module_pos_restaurant and is_table_management must be checked.
opw:785943