Explicitely return the extension of the listview to allow to modify it
in other modules
closesodoo/odoo#34672
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
-In Kanban view of products, it should allow to create a
product or import it
task-2032878
closesodoo/odoo#34660
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This inner join permit to have filters on orders to be executed earlier in the query plan
In a multi-company environment with millions of pos lines, the difference is about 10% faster
As you cannot have a line without order, this doesn't introduce reggression.
closesodoo/odoo#34849
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
On runbot, edit SO131 and change the company
=> traceback
An onchange is triggered (=> self.id is a NewId).
But while recomputing the quantity delivered, a
read_group is performed which gives real ids (int).
The ids are then used to retrieve some so_lines in a
dict where each key is an id (but actually NewId
in onchange) of self.
=> the keys are NewIds but try to get the value with an (int) id
=> KeyError
closesodoo/odoo#34818
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Website crm phone validation does not hold code that cannot be located in
website_crm as dependencies are now the same. Let us merge those two
modules !
Linked to task 2033777
closesodoo/odoo#34744
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As multiple users will be able to login in the main session, we
shouldn't use the user_id of a session to find the correct session, but
we are only depending on the pos_config
closesodoo/odoo#34623
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before, when a pos order was created, some of its values were were
completed through the default mechanism that was looking for a session
opened by the current user, which could lead to wrong values when with
recovery session. Since in near future we'll allow one user to open
multiple sessions, this behavior won't work anymore, as you could get
the config od another session than the one you are working on.
We also removed the '_default_session' on field session_id, as the
method 'create_from_ui' which creates the orders from the frontend
allways set the session_id when it creates a new order.
TASK-ID: 2032769
In Inventory, we have an option to print the report of Barcode in ZPL but we do
not have option to print the same in PDF.
After this commit, there will be a PDF version of the report of Barcodes
available just similar to the report in ZPL.
task-1970506
closesodoo/odoo#32935
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
There are currently multiple ways to determine if an employee is presence
or absent:
- login state (user status on chat)
- checkin/checkout from the Attendance app
- leave
- hr_presence (email, ip)
Those states are displayed in several different places and can be inconsitent.
e.g. Logged in -> green in the chat
Not checked in -> red on the employee kanban view.
The multiple ways to determine employee presence described above
should be aggregated together to have a better consistency.
Specification
=============
There are 3 presence states (previously defined in module `hr_presence`),
namely `present`, `absent`, `to_define`. They are now defined as soon as
`hr` module is installed.
The state computation can have several behaviors according to which apps
are installed:
1. `hr` is installed
Check employee presence based on login by default (only for employees with
a user).
Kanban state (private and public): should be green when logged in, red when logged out and
orange when the user is away.
Private employee form: Display a stat button "Connected" on the form view
when the user is logged in or "Last Activity xx/xx/xxx" otherwise.
2. `hr_attendance` is installed:
when the user is logged out, the state
is determined from the checked in/out state. But when the user is logged in,
consider the user as present (even if he checked out).
Kanban state: green for checked in, red for checked out
Private form view: attendance stat button.
3. `hr_holidays` is installed:
Has the highest priority if the employee is on leave.
Kanban state: red if employee is on leave.
Private form view: stat button "Absent Until xx/xx/xxxx" if employee
is on leave.
4. `hr_presence` is installed:
Two additionnal presence checking option: emails sent and IP address connected.
Once a user sent an email or the IP address was connected, he is considered
present for the entire day.
There should be at most one stat button on the employee form view, with the
relevent information.
Task id: 2024482
closesodoo/odoo#34933
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1/ Change stat button landing page
----------------------------------
Currently when clicking on the leave stat button
of an employee, the landing page is the leave dashbord of the current
user.
It's more usefull for HR people to land on the reporting
view of the employee.
2/ Remove stat button from public employee
------------------------------------------
It's useless for regular employees to know how
many remaining leave others have.
Hence the stat button is removed from the public
employee form view.
As Marc Demo, at the begining of the month, through
the client action, you can checkin but not checkout.
There is one limitation in the way the attendance state is computed:
It uses the attendance with the most recent checkin date.
Therefore, if an attendance is created in the future, it's the later
attendance which is taken into account, not the current attendance.
Steps to reproduce the problem:
1. Create an attendance in the future with both start and end
date set.
2. Through the client action: checkin
=> the client action stays on the checkin screen because you are
considered as checkout. Hence you cannot checkout.
It's difficult to change the way the state is computed, especially
having the right triggers.
Adding a constraint to avoid attendance in the future is probably a
bad idea. It could unintentionaly fail if the user's time is off by
a few minutes on his computer.
On the other hand, this situation should rarely happen (only when manually
creating an attendance, which has little functional sense).
Solution: Fix demo data to avoid attendances in the future.
Tests needed to be adapted because they used demo data. They no longer
use demo data.
This PR allow gaining a badge at the end of a certification survey if succeeded.
The badge can be configured on the survey if the certification mode is activated.
The badge is linked directly to the survey and not the challenge,
because it makes more sense to configure directly the reward on the survey and
not the way to gain this reward. As the way is always the same.
Only one badge can be set on the certification survey.
Only the name, description, image and badge level can be configured.
The rest of badge configuration is automatically set to correspond to the use case.
When a badge is configured on a certification survey, the needed challange, goal
and challenge line are autogenerated.
The badge is available on the user's profile page if he gained it.
Note : To avoid having to create a bridge module only to display the
certification badge on the user's profile page, the default website_published value
of the certification badge is defined directly in the survey module even if
survey does not depend of website. This attribute will be ignored until website
module is installed.
Task ID : 1935136
closesodoo/odoo#31486
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Avoid a complete reload of the web client when adding a optional
product, which loses searches, breadcrumb, etc.
This is achieved by adding a non-stored 'is_present' computed field
which is computed depending on the presence of a SO line linked to the
option line - that way its is dynamically adapted when the option is
added to the SO. Since we wanted a clear feedback when the option was
added to the quote, green colouring and the disappearance of the 'add
to quote' button have been added.
Note that this field *cannot* be stored - since the line_id field on the
option bypasses the ORM (`set null` for the on_delete attribute), it
would not recompute properly upon deletion of the linked SO line.
Task#1950410
closesodoo/odoo#34929
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
1. base: Load translation when language is activated
Purpose
------
Settings > Translations > Languages > I find the language I want
and I click on stat button to activate it.
Now I set it up on my user, it still doesn't work > the langage has not been loaded !!!
Specification
-------
When activating a language load the translation (and open the load translation wizard)
2. base: Add shortcut button to load language
Pupose
-------
On the res.partner and res.user form view if you want to change
the language, it's not easy to know where I can activate more
langages.
Specification
-----------
Add a small icon next to the language field to activate more
languages (similar interface than to send an SMS).
3. base: Clean res.lang tree view
1. Set limit to 200 to display all current 82 languages
in one page (current limit is 80/82).
2. Move some fields to debug mode.
3. Add a button to directly load a language.
4. base: Remove Load a Translation menu
Activating a language automatically load the translation,
hence the menu is no longer necessary.
5. base: Don't show language if only one active
If only one language is active, don't show in the contact
form view (`res.partner`) the language field. Changing the language is
not possible since there is only one language.
Hence the field is useless and therefore hidden.
TaskID: 2026150
closesodoo/odoo#34661
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If only one language is active, don't show in the contact
form view (`res.partner`) the language field. Changing the language is
not possible since there is only one language.
Hence the field is useless and therefore hidden.
1. Set limit to 200 to display all current 82 languages
in one page (current limit is 80/82).
2. Move some fields to debug mode.
3. Add a button to directly load a language.
Pupose
======
On the res.partner and res.user form view if you want to change
the language, it's not easy to know where I can activate more
langages.
Specification
=============
Add a small icon next to the language field to activate more
languages (similar interface than to send an SMS).
Purpose
=======
Settings > Translations > Languages > I find the language I want
and I click on stat button to activate it.
Now I set it up on my user, it still doesn't work > the langage has not been loaded !!!
Specification
=============
When activating a language load the translation (and open the load translation wizard)
To avoid having to wait the cron that distribute badges to elligible users,
we run the cron manually at the survey passed
if the survey is a certification and if the certification delivers a badge.
Task ID : 1935136
PR #31486
This commit allow gaining a badge at the end of a certification survey if succeeded.
The badge can be configured on the survey if the certification mode is activated.
The badge is linked directly to the survey and not the challenge,
because it makes more sense to configure directly the reward on the survey and
not the way to gain this reward. As the way is always the same.
Only one badge can be set on the certification survey.
Only the name, description, image and badge level can be configured.
The rest of badge configuration is automatically set to correspond to the use case.
When a badge is configured on a certification survey, the needed challange, goal
and challenge line are autogenerated.
The badge is available on the user's profile page if he gained it.
Once the badge is configured on the survey, he cannot be changed
(remove + create new one), only modified (badge attributes edition).
The only way to remove the badge is to uncheck 'certification_give_badge'.
When removing the badge from the certification survey, all the autogenerated
records (at badge creation) are deleted to avoid ghost records (as they have
no purpose outside of this context). If the badge is owned by someone, the badge
is only archived. If nobody owns the badge, the badge is deleted.
Survey users now have the right to create badges but not challenges or goals.
All the autogenerated records are handled in sudo, to allow the survey user
to configure a badge on their survey.
Note : To avoid having to rewrite the complete context in an xpath expression
only to display the certification badge on the user's profile page,
the default website_published value of the certification badge is defined
directly in the survey module even if survey does not depend of website.
This attribute will be ignored until website module is installed.
Task ID : 1935136
Closes PR #31486
PURPOSE
Refactor SMS to better integrate it in interface and Discuss. Allow users to
send texts in different business objects: crm.lead, event.event, etc. Introduce
SMS templates to ease mass SMS sending and scheduling.
DETAILS
This merge is mainly a big refactoring of SMS module. Future commits will come
with improvements in various addons to better include SMS, notably: crm,
events, scheduled actions, mass sms, marketing automation, stock, ...
This merge has been done in several main steps
* preparing mail to send hold other notification methods than Inbox and
email;
* refactor / improve posting with SMS notifications;
* improve SMS composer;
* add SMS templates and integrate them in composer;
* integrate into Discuss UX with wizards to resend and cancel failed
notifications;
* add tests;
See sub commits for more details.
Related to task 1922163
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
closesodoo/odoo#33510
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to include SMS templates and the new sms messaging
API and methods in calendar_sms and hr_presence. Templates allow people to
customize the content of sent SMS. New SMS messaging API allows to track
notification status when sending SMS.
Related to task 1922163
Linked to PR #33510
It allows notably to check and test mail failure widgets as well as wizards
to resend and/or cancel sms notifications.
Related to task 1922163
Linked to PR #33510
Purpose of this commit is to allow users to have a feedback on SMS
notifications status in chatter. This commit contains notably
* an update of systray widget that now handles SMS failures. Those are
displayed in another item of the systray and redirect to documents having
an SMS failure;
* an update of chatter widgets to support SMS notifications in messages.
Failed notifications appear in red and allow to use the SMS resend
wizard;
Mail message model gains a new has_sms_error computed and searchable field
allowing to filter on messages having failed SMS notifications. Mail thread
model gains a new message_has_sms_error computed and searchable field, based
on the one on mail.message. It allows to filter on records with failed SMS
messages directly from the systray. That way clicking on the systray entry
redirects to the right records.
Related to task 1922163
Linked to PR #33510
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Purpose of this commit is to allow SMS notification management. It is based
on what has been done in mail for notification: resend and cancel.
In this commit we add wizards allowing users to resend and cancel failed
SMS notifications. Resend allow to change the contact number, as well as
resending only a subset of notifications.
Future commits will improve the UX itself.
Related to task 1922163
Linked to PR #33510
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Purpose of this commit is to provide users templates to use when sending
SMS. It is inspired from what already exists for mail templates. This commit
* adds templates for SMS
* users can now create template for SMS Text messages similar to mail
templates;
* jinja syntax is supported for body like mail templates, which is why
templates are linked to a given model;
* refactor the SMS composer
* templates are supported in composer like the message composer. This is
supported only in mass mode to avoid bloating the interface in standard
composition mode;
* composer code is rewritten to support various use cases (comment, mass
sms, numbers, ...) and better fits all use cases;
* composer is extended to support notably mass SMS without posting messages;
Templates will also be used in a near future in mass sms sending (mass
mailing application improvement) and in marketing automation (for enterprise).
Tests are updated and added to ensure feature works.
Related to task 1922163
Linked to PR #33510
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Purpose of this commit is to better include SMS notifications when posting a
message. SMS is now just another way of notifying people along with Inbox and
email. Following recent mail merge improving notification mechanism [1] we
have to define a _notify_record_by_sms method on mail.thread.
When a message_post is done using message_type being ``sms`` notification type
of customers is set to sms. Customers can be computed on model (generally based
on partner_id field) or directly set usign partner°ids. Notification model is
updated to store this information directly inside the notification itself.
An new ``_message_sms`` helper method is introduced in SMS module allowing
to send messages using sms type and notification with a reduced parameters
number. It is just a shortcut to message_post, easier to use. Either it
computes default recipients on the record set, either it is based on given
partners and numbers to notify.
The following use cases are notably supported
* default computation: find customer, notify by sms;
* force recipients to notify by sms (partner_ids);
* give a set of numbers to notify by sms (sms_nubmers), not necessarily
linked to existing partners;
* force number / customer relationship independently of mobile number defined
on customer (for example when sending an SMS directly from a mobile field
on a lead linked to a customer);
Tests are updated accordingly. Performance tests are added in order to have
some insights on queries generated when sending SMS, like already done for
mail.thread alone.
Related to task 1922163
Linked to PR #33510
[1] see be27955136: performance and notification code improvements
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
This commit prepares SMS refactoring by updating some mail models. Purpose
is to be able to store SMS notification information inside existing mail
flow and models.
Main changes
* mail.notification: define a notification_type field to store the medium
used to notify people. In mail two ways exist: inbox and email. It will
ease introduction of SMS notification mechanism. This field replaces the
is_email boolean field;
* mail.notification: make res_partner_id field not required. This means
notifications could be linked to something else than a partner. An SMS
for example. For Inbox and email notifications partner is still required
and a constraint is added accordingly;
* mail.thread: let notification methods handle the creation and update of
their notification instead of creating them in _notify_thread and tweaking
them in sub notification methods;
* mail.thread: clearly move inbox-style notification in its own method like
notify by email;
Some lighter code changes
* propagate message_type to notification recipient computation. It will
allow for example to be more precise when computing a notification type
depending on the message_type. For example, send a notification by SMS
when the message_type is SMS;
* ease inheritance of ``_notify_thread`` by returning computed recipients
data. It will allow to work on it without having to re-compute it;
* propagate kwargs from message_post and message_notify to notify methods.
This allow to avoid depending on context and set explicit parameters.
Drawback is that message_post and notify must separate kwargs used to
create a message and those that are propagated to notification methods;
* update various notification check to ensure they work on email
notifications, notably the resend and cancel wizards;
One side effect of this commit is that notifications are created by the
relevant notification method. Previously all notifications were created
by writing on needaction_partner_ids fields then updated according to the
notification process. Notably there could be too much notification created
when sending emails due to _notify_customize_recipients not being correctly
synchronized with notification. This issue is now solved as only really
sent emails create notifications.
Migration tips
* notification_type: notification.is_email and 'email' else 'inbox';
* remove is_email;
Related to task 1922163
Linked to PR #33510
Usecase to reproduce:
- Connect on demo user (inventory user)
- Go on product page and click on stat button for 'quantity on hand'
> AccessError on decimal.precision object
due to commit a1eb000c93
When the user click on 'report inventory' button it will garbage
collect the remaining quants without quantity. In order to do it,
it needs the precision rounding in order to have a rounding and do
not let quant without significant quantity.
closesodoo/odoo#34780
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usability improvement because when the user click on inventory
report it's mainly in order to edit/check its current stock since
commit da33eb36b8
This change redirect the user directly on stock.quant tree view
and add an inventory at date button in the control panel. This
button will open the same wizard than previously and ask for a
date. The same principle is used for valuation layer.
Co-authored-by: svs-odoo <svs@odoo.com>
Task: 1880379
This commit introduces back the value by location feature dropped in v11.
The feature was dropped because we implement financial fifo, thus the
value by location does not make sense for this cost method.
This commit introduces an estimation of the value by location in fifo.
Task: 1880379
Purpose
=======
While cleaning the stat buttons across all modules, we decided
to move the (un)archiving from stat button to actions in the
'Action' dropdown.
The goal was to lighten the content of oe_button_boxes by clearing
out stat buttons.
The general idea is that stat buttons should be a redirection,
either to a set of records or to an alternate view of the current
one (there are some exceptions though).
The toggle_active stat button is an action, quite similar to a
deletion in most cases.
There are two main ways of using the 'active' field:
- archiving a record (often because it cannot be deleted since it
is linked to another record, like a res.partner used in validated
account.invoices)
- activating a record (with configuration objects like currencies,
languages, or taxes)
In the first case, the option is advanced, akin to deletion. Just
like deletion, its place is in the action dropdown, not the
formview itself.
It is nevertheless important to inform the user whether the record
is archived, but it is not necessary to inform him when it isn't.
In the second case (much less common), the 'activation' of a record
can simply be made available by adding the active field directly in
the formview.
Specification
=============
1/ web: Always display (un)archive buttons in Action on form views
Purpose
-------
While cleaning the stat buttons across all modules, we decided to move
the (un)archiving from stat button to actions in the 'Action' dropdown.
Specification
-------------
If the record has an 'active' field, display an action 'Archive' in the
2/ all: Remove active stat button on all views
Purpose
-------
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
-------------
Remove the 'active' stat buttons in all views
3/ web: Call 'toggle_active' instead of 'write'
Purpose
-------
Currently when clicking on 'Archive' or 'Unarchive' on the list view,
we write directly on the record {'active': False}, instead of calling
toggle_active. Missing that way implementation of numerous business cases.
Example
- Archive a record --> archive its next activities
- (Un)Archive a user --> (Un)Archive its partner
- (Un)Archive a product variant --> (Un)Archive its template if
there is only one variant
- Archive an employee --> Open a wizard to choose an exit plan + describe
the departure reason
- Archive a route --> Archive its procurement rules
- ...
Specification
-------------
- Call toggle_active instead of write when calling toggleActive in the web
client.
- On the other hand, use actionArchive and actionUnarchive to apply the
toggle action on the related records only.
4/ web: Remove toggle_button widget
This widget is not used anymore, as all the stat buttons have been removed
from the views.
5/ base,mail,...: Redisplay active field in some views
Purpose
-------
In the following views, add the 'active' field in the formview
as specified in the screenshots:
account.view_tax_form (account.tax) https://nimb.ws/08WqXP
crm_iap_lead_website.crm_reveal_rule_form (crm.reveal.rule) https://nimb.ws/xPHSiT
delivery.view_delivery_carrier_form (delivery.carrier) https://nimb.ws/yq3eDS
base.view_rule_form (ir.rule) https://nimb.ws/MBi2Ix
lunch.lunch_alert_view_form (lunch.alert) https://nimb.ws/DRdK4Z
mail.mail_blacklist_view_form (mail.blacklist) https://nimb.ws/xBq9ut
base.view_currency_form (res.currency) https://nimb.ws/FXG9oA
base.res_lang_form (res.lang) https://nimb.ws/eSr0dM
6/ web: add a new ribbon widget (POC)
Purpose
-------
The ribbon widget adds a ribbon on the top right of a form
to make some status more visible.
You have to specify the text attribute to show the text on
the ribbon. You can also specify a bg_color attribute to
color the background with a bootstrap background color class.
Note: This is an ugly draft of the final widget, that is supposed
to land in master in a few days. As this PR brings a lot of
functional changes in several files, it has become quite difficult
to maintain it over the days.
The final responsive version will come with:
https://www.odoo.com/web#id=2032621&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720
7/ base,mail,...: Add ribbon widget everywhere on archived records
Purpose
-------
In the following views, add a bg-danger ribbon with label 'Archived'
only visible when active=False:
account.account_tag_view_form (account.account.tag)
analytic.view_account_analytic_account_form (account.analytic.account)
analytic.account_analytic_tag_form_view (account.analytic.tag)
account_asset.view_account_asset_form (account.asset)
account.view_account_position_form (account.fiscal.position)
account.account_incoterms_form (account.incoterms)
account.view_account_journal_form (account.journal)
account.view_payment_term_form (account.payment.term)
website_blog.view_blog_blog_form (blog.blog)
website_blog.view_blog_post_form (blog.post)
calendar.view_calendar_event_form (calendar.event)
crm.crm_case_form_view_leads (crm.lead)
crm.crm_case_form_view_oppor (crm.lead)
crm.crm_lost_reason_view_form (crm.lost.reason)
sales_team.crm_team_view_form (crm.team)
documents.document_view_form (documents.document)
event.view_event_form (event.event)
website_event_track.view_event_track_form (event.track)
fleet.fleet_vehicle_view_form (fleet.vehicle)
fleet.fleet_vehicle_log_contract_view_form (fleet.vehicle.log.contract)
website_forum.view_forum_forum_form (forum.forum)
website_forum.view_forum_post_form (forum.post)
gamification.badge_form_view (gamification.badge)
helpdesk.helpdesk_sla_view_form (helpdesk.sla)
helpdesk.helpdesk_team_view_form (helpdesk.team)
helpdesk.helpdesk_ticket_view_form (helpdesk.ticket)
hr_recruitment.hr_applicant_view_form (hr.applicant)
hr_appraisal.view_hr_appraisal_form (hr.appraisal)
hr_contract.hr_contract_view_form (hr.contract)
hr.view_department_form (hr.department)
hr.view_employee_form (hr.employee)
hr.hr_employee_public_view_form (hr.employee.public)
hr_holidays.edit_holiday_status_form (hr.leave.type)
hr.hr_plan_view_form (hr.plan)
hr_payroll.hr_salary_rule_form (hr.salary.rule)
hr_work_entry.hr_work_entry_type_view_form (hr.work.entry.type)
lunch.lunch_product_view_form (lunch.product)
lunch.lunch_supplier_view_form (lunch.supplier)
mail.mail_activity_type_view_form (mail.activity.type)
mass_mailing.view_mail_mass_mailing_form (mail.mass_mailing)
mass_mailing.view_mail_mass_mailing_list_form (mail.mass_mailing.list)
maintenance.hr_equipment_view_form (maintenance.equipment)
maintenance.maintenance_team_view_form (maintenance.team)
marketing_automation.marketing_campaign_view_form (marketing.campaign)
mrp.mrp_bom_form_view (mrp.bom)
mrp_plm.mrp_eco_view_form (mrp.eco)
mrp.mrp_routing_form_view (mrp.routing)
mrp.mrp_workcenter_view (mrp.workcenter)
point_of_sale.pos_config_view_form (pos.config)
product.product_pricelist_view (product.pricelist)
hr_expense.product_product_expense_form_view (product.product)
product.product_variant_easy_edit_view (product.product)
stock_landed_costs.view_stock_landed_cost_type_form (product.product)
product.product_template_form_view (product.template)
project_forecast.project_forecast_view_form (project.forecast)
project.edit_project (project.project)
project.view_task_form2 (project.task)
industry_fsm_report.project_worksheet_template_view_form (project.worksheet.template)
quality.quality_point_view_form (quality.point)
base.view_res_bank_form (res.bank)
base.view_partner_form (res.partner)
base.view_users_form (res.users)
sale_coupon.sale_coupon_program_view_form_common (sale.coupon.program)
sale_management.sale_order_template_view_form (sale.order.template)
sale_subscription.sale_subscription_alert_view_form (sale.subscription.alert)
sale_subscription.sale_subscription_template_view_form (sale.subscription.template)
sign.sign_request_view_form (sign.request)
sign.sign_template_view_form (sign.template)
website_slides.view_slide_channel_form (slide.channel)
website_slides.view_slide_slide_form (slide.slide)
stock.view_location_form (stock.location)
stock.stock_location_route_form_view (stock.location.route)
stock.view_picking_type_form (stock.picking.type)
stock.view_stock_rule_form (stock.rule)
stock.view_warehouse (stock.warehouse)
stock.view_warehouse_orderpoint_form (stock.warehouse.orderpoint)
survey.survey_form (survey.survey)
website_crm_score.view_crm_score_form (website.crm.score)
website_twitter_wall.website_twitter_wall_view_form (website.twitter.wall)
8/ hr: Fix departure wizard activity generation
Purpose
-------
If the fired employee has no access to the hr.employee model,
the departure wizard will lead to a traceback, as we try to
create an activity on a model for which the user won't be able
to resolve it.
Create an activity on the related partner instead.
9/ web: Make archive:unarchive buttons manage returned actions
Purpose
-------
When calling toggle_active, you may sometimes retrieve an action to
execute. For example, when archiving an employee, it opens a wizard
to provide information about the departure, and choose an offboarding
plan.
This commit modifies the way toggleActive, actionArchive and
actionUnarchive works to manage this behavior.
TaskID: 2030440
closesodoo/odoo#34496
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
When calling toggle_active, you may sometimes retrieve an action to
execute. For example, when archiving an employee, it opens a wizard
to provide information about the departure, and choose an offboarding
plan.
This commit modifies the way toggleActive, actionArchive and
actionUnarchive works to manage this behavior.
Purpose
=======
If the fired employee has no access to the hr.employee model,
the departure wizard will lead to a traceback, as we try to
create an activity on a model for which the user won't be able
to resolve it.
Create an activity on the related partner instead.
Purpose
=======
The ribbon widget adds a ribbon on the top right of a form
to make some status more visible.
You have to specify the text attribute to show the text on
the ribbon. You can also specify a bg_color attribute to
color the background with a bootstrap background color class.
Note: This is an ugly draft of the final widget, that is supposed
to land in master in a few days. As this PR brings a lot of
functional changes in several files, it has become quite difficult
to maintain it over the days.
The final responsive version will come with:
https://www.odoo.com/web#id=2032621&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720
Purpose
=======
Currently when clicking on 'Archive' or 'Unarchive' on the list view,
we write directly on the record {'active': False}, instead of calling
toggle_active. Missing that way implementation of numerous business cases.
Example
- Archive a record --> archive its next activities
- (Un)Archive a user --> (Un)Archive its partner
- (Un)Archive a product variant --> (Un)Archive its template if
there is only one variant
- Archive an employee --> Open a wizard to choose an exit plan + describe
the departure reason
- Archive a route --> Archive its procurement rules
- ...
Specification
=============
- Call toggle_active instead of write when calling toggleActive in the web
client.
- On the other hand, use actionArchive and actionUnarchive to apply the
toggle action on the related records only.
Ghuen Lee