* note, payment, sales_team, website_forum, website_sale(_options)
Get rid of the remaining sass files and their corresponding css files
and convert the meaningful ones to less files. Ironically, this is done
in prevision of converting all less files to scss (a sass syntax).
One sass file remains though: description.sass. This file is indeed
particular and needs more work to be correctly converted (odoo.com/apps
semi-depends on it and the file is not used in an asset bundle).
* note, payment, website_forum, website_sale(_options)
This is a simple renaming of sass files to less files. The real
convertion will be done in the commit that follows.
This commit adds the possibility to chose between pounds and kilograms
to express the weight field on the product. This is done so that
companies that worked internally in pounds do not have to convert their
weights back to kilograms for a consistent computation of the rates in
delivery.
We complete the general settings with the selection of the weight's uom.
Validating the setting will create an ir.config.parameter. A static
method defined on product template will return the chosen UOM.
We display "weight_uom_name" on the form view so that the UOM is not
clickable/editable because we fear user would want to edit the UOM
instead of changing it in the res config.
We move the view definition allowing to fill the product's weight from
stock to product to help the generation of the intrastat report without
installing inventory.
Notification emails contain a link to the record. Before 6187ffa258
it was necessary to choose whether to display leave or allocation as
button label. It is not necessary anymore since each concept has its own
odoo model. Standard behavior is now sufficient as it displays the model
description, now leave or allocation. The unnecessary code is therefore
removed.
Notification emails contain a link allowing to follow or unfollow
documents directly from the notification email. However there are
several issues with this button
* it require people to login to follow or unfollow documents;
* it is not linked to the email;
* if the customer does not have a login it is not possible to perform
the action;
* there is no confirmation step;
This commit removes the follow / unfollow button in the notification
emails. Indeed as people have the "Access document" button there is
only one more click to perform in order to subscribe or unsubscribe.
Concerning customers adding a complete control of the follow mechanism
would be costly in term of code and access rights checks. We therefore
decided to remove this button.
It also allows to simplify a bit the notification process as there
are less parameters to take into account when grouping recipients. It
allows to lessen the number of required template rendering when sending
notification emails.
The first day of week is a cultural habit usually linked to the language. An additionnal option could be added later on the user preferences to allow a user to change the first day of the week in his calendar view.
- create new repair instead of using the demo data to make further
extensions easier
- integrate the fees testing in an existing test
- test the created moves of a repair order
This commit removes the location_dest_id on repair orders. This field
was used to move the product to a specific location after the repair was
done. It makes the usability of the repair order smoother and the user
can still make a transfer to move the product to another location
afterwards.
The user is able to specify a route on a SO line. The pull rules are
correctly used however the push rules are not apply.
This patch adds a check in order to apply possible push rules associated
to the route specified on the SO lines.
Closes#22141
Previously, it was only possible to make a return in
- the location the move was coming
- a return location that is child of the parent_location, actually
meaning a return location in the warehouse
This commit now allows making return in all return location, even one
located in another warehouses.
When trying to save an employee without working calendar, we
get an error message, since the resource_calendar_id of the
related resource object is required. To have a better error
setting the field required on view is more explicit.
We don't want to set it directly on the field as it is
a related stored field, to avoid recompute problem.
Using a working calendar, you might want to know
how much hour correspond a work day. This depends
of you working calendar. This might be usefull to
compute leave duration (half a day is not 8 hours,
but 4).
The hours_per_day field is not computed as the
average of working hour of all work day of calendar
to allow customization. By default, it is 8, as
the default attendances are the one from the
40h/week calendar.
A constant is also available to handle case where
resource calendar is not available.
*: mainly crm, hr_recruitment and project
This branch improves the RecordQuickCreate and ColumnQuickCreate
widgets of the Kanban view, in order to ease user onboarding.
The RecordQuickCreate is no longer limited to the display_name: it
instantiates a real form view, whose xmlid has to be referenced in the
root node of the Kanban arch (attribute 'quick_create_view'). This
branch already defines quick create form views for models 'crm.lead',
'hr.applicant' and 'project.task'.
The ColumnQuickCreate's main change is that it may now contain a link
leading to a dialog with examples of how to configure the columns (by
specifying a JS registry key under attribute 'examples' in the root node
of the Kanban arch, and by defining the examples to display in the
dialog in that registry). Examples have already been specified for the
'project.task' Kanban view. Several other tweaks have been done on the
ColumnQuickCreate (e.g. it now opens directly in grouped Kanban views
with no column, its style has been improved...)
Tasks #27475 and #38740.
The ColumnQuickCreate widget is now automatically open when
entering a grouped Kanban view with no column. Moreover, the DOM
of the quick create has changed. The tour had to be adapted
accordingly.
The goal of this rev. is to improve the user onboarding on the
Project app: when the user creates a new project, he is now guided
to properly configure the stages of its project.
To do so, we added a new mechanism in the Kanban view, allowing to
define examples of processes that can be used in the corresponding
view.
The style of the ColumnQuickCreate widget has also been changed.
Part of task #38740
The 'crm_tour' and 'main_flow_tour' tours both create a 'crm.lead'
record from the Kanban view at some point. Since last commit, this
doesn't open a form view in a dialog anymore, but instead opens a
form view in the QuickCreate widget. Some steps of those tours had
to be adapted accordingly.
This rev. defines form views to use as quick create views in the
kanban view of models 'crm.lead', 'hr.applicant' and 'project.task'.
It uses a newly created mechanism allowing to specify a form view
xmlid in the Kanban arch, such that the referenced view is rendered
inside the QuickCreate widget (see parent commit).
Task #27475.
This rev. improves the QuickCreate widget for grouped Kanban views.
It allows specifying in the Kanban arch a form view xmlid, e.g.:
<kanban quick_create_view="some_form_view_xmlid">
...
</kanban>
When this attribute is set, the referenced form view is loaded and
rendered inside the QuickCreate widget. A real FormView widget is
instantiated, meaning that all form view mechanisms are available
in the QuickCreate (modifiers, default_get, onchanges, widgets...).
Task #27475.
Record quick create can be cancelled by pressing ESC, so this rev.
ensures that the same behavior applies for the column quick create,
for the sake of consistency.
In Less, the size_class XXS is defined and used in media queries.
This rev. adds it in JS for sake of consistency.
Code in addons comparing the size_class needed to be adapted due
to the new XXS size_class.
Moreover, we now use the helper 'config.device.isMobile' everywhere
we should, instead of manually comparing the size_class.
Finally, we changed the way the config.device has to be specified
in the test environment. From now on, only the size_class should be
set, and the isMobile flag is computed automatically.
- One need to first enable this from Accounting Settings to use this feature
- This feature works for Vendor Bills which are validated/paid
- Once activated, user can see one option in Vendor Bills to set particular record to be recurrent document and can define the recurrency period. This will automatically create draft documents(by mean of Scheduled Actions) as per recurrency configuration.
Was PR #21411. was task 34884.
* [IMP] mail: check if template can be rendered on write
Before this commit, whenever a user would send an email from a template
containing mako python expressions and those expressions contained
syntax errors, the mail would still be sent but the body would be empty,
this was intended behavior but due to an increase in complaints of empty
mails being sent, the behavior was reviewed.
This commit improves on this behavior by:
1. Rendering the template on write (save)
2. Checking if the template rendered successfully
3. Raising a UserError if the rendering failed
The end result is a modal box showing an error to the user whenever he
either saves an mail.template with python syntax error in mako snippers
or when a mail with mako snippets is rendered on-the-fly (wizard).
The `additional_context` key was missing from the mock function of `load_action`.
This was causing an issue when testing a use case (the context was correctly
passed in Studio).
Revision on c778de44c7
The changes on chat_window are wrong, because the
composer uses an 'input', instead of a 'div'.
As a result, it was not possible to send messages
over im_livechat from the website.
This was not the case on the webclient: chat_window
is enhanced with extended_chat_window, which replaces
the composer with 'div', hence the changes are correct.
As user_id is a magical field, we rename responsible_id to user_id to notify him when he is assigned to an expense sheet.
The other option is to rewrite the mail template "message_user_assigned" and to adapt mail_thread.py to accept other field than user_id, but this task is let for later.
- Change the differents states of hr.expense to have
ToSubmit, submitted, approved, refused and paid.
- Add a responsible field on employee model. The responsible is a res.user that belong to the group "hr_expense.group_hr_expense_manager"
The commit change too a "vals" variable that changed in a git rebase operation.
- Make the other_info tab invisible if the user doesn't belong to account.group_account_user.
- Make expense wizard (for expense lines) editable if expense is in reported mode, so when the sheet is in To submit state.
- Move a tour from expense form to expense_sheet form
- rename two fields (attachments and manager)
- The buttons "approve" and "expense" must be hidden if the user isn't the expense responsible.
- The description field of expense line must be editable in draft, reported and refused state
- Add a subtype to follow responsible changes on expenses sheets
- subscribe responsibles of an expense to followers of that expense
- hr_expense requires sale_expense instead of sale_management
- remove one tour step and change texts of some others
- remove header from expense line wizard
- add tax field in form view for expense
- change the display name of some fields and other titles.
- remove the expense report and improve search bar for expenses in report.
fda-odoo