When a theme module is updated the changes made on a view are considered
as user changes, prenventing the view from being updated in the future.
Fixed by comparing the arch being written with the arch of the original
view. If it is the same the record should not be noupdate.
Plus added a test to make sure the theme views receive theme updates
after being updated once.
Introduced by: https://github.com/odoo/odoo/commit/4acf177b4c55f3a16362cbeafea3d332ef4fe819closesodoo/odoo#51557
X-original-commit: 221470ab9c9eda3f3a4e2da0fa1a7bb23d6288cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Issue
- Install "Sales" and "eCommerce"
- Activate debug mode
- Go to Settings->Technical->Email->Templates
- Search and open "Sales Order: Confirmation Email" record
- Click on stat-button "Preview"
- Select a "Sale Order" sample with product(s)
The quantity column label is not in the right place/column.
Cause
Each row of the table is a table.
Solution
Add same fixed column size css on each table.
opw-2242914
closesodoo/odoo#51380
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When there is a:
`groups="..."`
on a qweb view, when you edit the view with the editor then save all
groups will be removed since they are processed (so either we don't see
`groups` in the rendered view, or we don't see the element itself).
With this change, the "where should this part be saved when edited"
branding will be distributed to elements with `groups` attribute.
Added test without change failed with:
AssertionError: {'data-oe-model': 'ir.ui.view', 'data-oe-id': '827',
'data-oe-field': 'arch'} != {}
because branding was added to `root` tag before change.
opw-2253576
closes#51489closesodoo/odoo#51548
X-original-commit: c77bd5b043b7d2a795d0fc70c8e83b308a357224
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
If we try to load a csv file with opening values for the anuaffected
earnings account, there will be errors because when trying to balance
the move, we filter the lines on that account and we don't expect there
to be multiple lines in it.
closesodoo/odoo#51401
X-original-commit: ad4277219fe078712916e91c1be566a9b412fe1f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Technically removing the entire thing if it's not one of the special
cases is a form of cleanup I guess, but that seems a bit brutal and
counter-productive. So that function should *probably* return the
input value if it's not a type which requires special processing.
closesodoo/odoo#51531
X-original-commit: b42994c87dce12c5ba22943f6cbe00240fe43138
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently if an event has tickets, some of them with start date and some of
them without, it is considered has beginning at the minimal start date.
However if a ticket has no start date and is not expired, it means it is
available for sale.
An event start date is therefore the first date of its not expired tickets if
they all have a date, otherwise it is set to False (aka, already started).
We also fix display in main event page: events not yet open are not considered
as Sold out or Closed anymore, just not yet open.
Task ID 2244487
PR #51503closesodoo/odoo#51523
X-original-commit: 8404a6ff12ee82e9b4ec35660f74dbe0b4a90cb0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current display of "You ordered more tickets than available seats" is quite
ugly, missing modal classes to make its padding pixel-perfect.
Task ID 2244487
PR #51503
X-original-commit: 14e510ee186c36d5bd723b3077d000122f7b181c
toggle_website_menu (in website_event_track module) is called by website_event
set_customize_options (in website_event module). Since website_event_track is
not installed by default when website_event is installed, this function might
not be available in the event.event model. Therefore toggle_website_menu has
been moved from the event.event model in website_event_track to the event.event
model in website_event.
Followup of bd99cc24b1
Task ID 2244487
PR #51503
X-original-commit: e541efe1338f853962560db4d982821707ddc3c6
One condition among other to determine if SOLD OUT should be displayed for a
ticket is start_sale_date < current date. However is start_sale_date is not
set a traceback is raised.
Moreover timezones are not taken into account when comparing dates, which may
create issues.
A tool method 'is_launched' has been added to overcome this problem. It works
like the already existing field 'is_expired'. Its value is computed based on
start_sale_date and event_id.date_tz. This will be changed into a not stored
computed field in master.
Task ID 2244487
PR #51503
X-original-commit: 9f81e126cdb1ce79ef26077a708cad8a7614031f
USE CASE
Send a mailing to some recipients. Set reply-to of this mailing to an alias
creating records on a model inheriting from utm.mixin. UTM informations on
mailing are not propagated to the newly-created records.
SPECIFICATIONS
When an user answers to a mail of a mailing with an alias creating records
on an UTM enabled model, propagate UTM from the mailing to the new record.
In order to set UTM informations during record creation, "message_new" has
been overridden in mass_mailing. That way it is automatically available on
all models inheriting from utm.mixin.
A test simulating this scenario has been added. It checks if UTMs info are
correctlwy set on the created record by comparing them to the mailing's UTM
info.
Task Id 2210334
closesodoo/odoo#48602
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit trying to reimport csv of a translation failed.
The reason was that before 632fa044c3 the parsing was common
between po and csv while now it's split in two different parsers.
The res_id column of the CSV is the external id of the record and is
handled by IrTranslationImport.
Use DictReader instead of csv_reader to easily add new keys and still
be flexible on the given csv files.
Match the POReader format with a imd_model and imd_name column.
As for the PoFileReader, the code translations are unique and must be
discarded in case of duplicate.
Correct the error message if the imported file is not correct (was
missing an argument)
Fixesodoo/odoo#50975closesodoo/odoo#51468
X-original-commit: 3cedadb5ba606e156f52e70ed08b25ac2df8d58b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
Currently, reporting views such as the bar and line charts have
their x-axis sorted either alphabetically or according to a
sequence. When reporting, the user would be interested in sorting
the x-axis values by their measure.
SPECIFICATIONS
Add 'ascending' and 'descending' options in graph view for bar and
line charts
Task 2070103
closesodoo/odoo#49970
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
The methods `get_work_hours_count` and `_attendance_intervals`
raise a traceback if `self` does not contain a single calendar record.
This commit adds an explicit check for this requirement.
Related PR odoo/enterprise#10593closesodoo/odoo#51326
X-original-commit: e5d93be382b03c7a9c925b4a2e6be6875843195d
Related: odoo/enterprise#10619
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Because of cross-browser compatibility concerns, jQuery's selector
engine makes using :has selector relatively slow. This is usually
acceptable, but in the case of snippet options, some options also need
to use :has in their data-target selector, and nested :has selectors'
performance degrade exponentially with the level of nesting.
Additionaly, jQuery evaluates complex selectors right-to-left, which
makes the :not operator quite inefficient.
Because of that, this commit removes :has and :not from the conditions
that were added at the end of the data-selector, and speeds up the
selector by a factor of ~15-40
Lastly, the addDropSelector options was actually unused, and a leftover
from the editor revert, as such it has been removed.
closesodoo/odoo#50073
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the Notification is used but in Chrome Mobile
we can't use it outside a ServiceWorker.
After this commit, if the Notification Object produce
an error it will fallback to the old method do_notify()
Steps to reproduce:
* Open a Odoo instance with Chrome Mobile (e.g. with Demo user)
* In Chrome Mobile, accept to receive the "Native Browser Notification"
* Put Chrome Mobile in the background of Android (don't close it)
* Open another instance of the same Odoo somewhere else with another user (e.g. Admin)
* From Admin, send a direct message to Demo
* Resume Chrome Mobile to the foreground the you will see the traceback (BUG)
GitHub issue: odoo/odoo#34714
Ref:
https://bugs.chromium.org/p/chromium/issues/detail?id=481856closesodoo/odoo#51474
X-original-commit: ebe6731c583f9f4125272af3d8bdc4625e06de7c
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
- Install Website and Email Marketing
- Go to Settings
- Click on "Manage Languages" and activate French
- Click on "Activate and Translate" and check the websites to translate
- Go to Preferences and set user language to "French"
- Go to Website > Configuration > Settings and make sure that French is in the languages list
and that it is default
- Go to Email Marketing
- Create a new mailing
- Make sure that current user is in the Recipients list
- Send the mailing (it will be scheduled)
- In debug mode, go to Settings > Technical > Scheduled actions to run the action manually
- Check the received mail and click on the "unsubscribe" link
On the unsubscribe page there is text that is not translated.
Some of the translations on this page is done in JS.
But the translations are not available at that moment.
The translations have to be loaded manually before letting the JS doing its work.
opw-2251235
closesodoo/odoo#51485
X-original-commit: 72a5e2b273e5faeccf49c0ef3fbb9f470e1a1c71
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install Sales and Accounting
- Go to Sales > Orders > Quotations
- Create a new quotation
- Add a product and in Order Line form, select a tax
- Save the Order Line
- Save the quotation
- Go back to quotation list
- Select (checkbox) the created quotation
- Select "Export" in Action menu
- In export wizard, choose "Excel" format and add field "Tax amount by group"
- Validate with "EXPORT TO FILE"
An error is triggered.
The issue comes from the fact that the value of "amount_by_group" is an array of tuples
and "xlwt" cannot write that type of value.
opw-2255054
closesodoo/odoo#51480
X-original-commit: dde2ca9943362b20853ab11b15fe1504c0b8d848
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Fix trace state management in mass mailing: correctly compute state
and better support incoming email headers.
SPECIFICATIONS: STATE
Trace status is a computed field based on other fields. Those store the
datetime at which a specific action has been performed: opened, replied,
bounced, ... depending on those fields status of trace is computed.
Replied / Bounced / Opened states should be computed prior to Sent state.
Indeed Sent is the default state once the email is sent. Then replied,
bounced and opened are states that happen after sending the email. It
is therefore necessary to re-order the state computation to correctly compute
the statistic state.
SPECIFICATIONS:GATEWAY
Consider an email going through the mail gateway. Its headers References
and In-Reply-To are used in mail gateway to find if it is an answer to an
existing discussion thread.
Notably in mass mailing it is used to set mailing traces (called statistics
in 11.0) as opened and replied. However currently only the References header
is used.
In this commit we now use References or In-Reply-To like what is done in
mail gateway.
LINKS
Task ID 2257717
PR #51247closesodoo/odoo#51490
Forward-port-of: odoo/odoo#51445
Forward-port-of: odoo/odoo#51247
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Consider an email going through the mail gateway. Its headers References
and In-Reply-To are used in mail gateway to find if it is an answer to an
existing discussion thread.
Notably in mass mailing it is used to set mailing traces (called statistics
before 13.0) as opened and replied. However currently only the References
header is used.
In this commit we now use References or In-Reply-To like what is done in
mail gateway.
== 13.2 FORWARD PORT SPECIFIC ==
Code in tests has been updated to use new mockups tools and variables available
in test_mail
LINKS
Task ID 2257717
PR #51445
Forward-port-of: #51319
Forward-port-of: #51247
X-original-commit: 9921e38692e7dc4547afc34acc395da340eca410
Trace status is a computed field based on other fields. Those store the
datetime at which a specific action has been performed: opened, replied,
bounced, ... depending on those fields status of trace is computed.
Previous backport fixed mailing trace management to match heuristics used in
12.0 . However when replying, trace is considered as open instead of replied.
It is now fixed as we consider replied being more important than opened.
Task ID 2257717
PR #51445
Forward-port-of: #51319
Forward-port-of: #51247
X-original-commit: 8df2b0b8baabb35fdd44f5cbcc1cf72ebb03cc79
Colorpalette compatibility system was broken so old color classes were
not removed from snippets when being edited.
The bug was introduced by [1].
Also if a compatibility color class happens to use the same css color as
a current theme class, that one will now be shown as selected.
[1]: https://github.com/odoo/odoo/commit/c20423313cf10f262e615badc0397e6ba4ef4087closesodoo/odoo#51464
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
PURPOSE
Create event registrations in batch. It will allow to customize group-creation of
registrations, notably with automated rules for crm / event synchronization.
SPECIFICATIONS
Find where registrations are created, and
* either remove registration creation (cart update)
* either make it in batch (buying tickets in front-end, using the registration
editor)
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR #51341
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In fb051d3420 there was some changes on drag and drop of chatter
windows, but this would break the drag and drop of summernote because it
wait for document.drop event for hiding the drop zone.
opw-2259522
closes#51448closesodoo/odoo#51478
X-original-commit: 4aaf5b1f562f4cd30e05b020741eb936f6e20a20
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
PURPOSE
Create event registrations in batch. It will allow to customize group-creation
of registrations, notably with automated rules for crm / event synchronization.
SPECIFICATIONS
Improve registration editor to create registrations in batch. Also be less
dependent from context in its code, currently a bit weird.
Move creation of registrations based on line from _action_confirm to
action_confirm. Indeed it adds complexity and we are unsure it really helps
having two methods.
Update based on lines now create registrations in batch instead of one by one.
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
Co-Authored-By: Jeremy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Create event registrations in batch. It will allow to customize group-creation
of registrations, notably with automated rules for crm / event synchronization.
SPECIFICATIONS
Instead of creating registrations one by one when processing registration
form details, simply batch-ize their creation.
Instead of creating registrations one by one when adding a new line in cart
simply let website_event handle its job, or the confirmation action of a
sale order that already populates registrations.
Creating registrations when adding a cart line has no real use as we have
no specific information to create that registration. It is better to let
the flow finish and create additional registrations in batch once SO is
confirmed.
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
Co-Authored-By: Jeremy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
In this commit we add some tests related to sale order / event registrations
synchronization, notably
* registrations automatically created when _update_registrations of an SO
line is called, for example at SO confirmation;
* using the registration editor;
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
Steps to reproduce the bug:
- Go to inventory > settings > enable multiple warehouses
- Let's consider the default warehouse W
- Create a new warehouses NW
- Enable debug mode
- Go to sales > create a new quotation
- Go to the other information tab > change default warehouse W to the newly created warehouse NW
- Click on the bug > go to set defaults > warehouse=NW > save default
- Refresh the page > Go to sales > create a new quotation
- Go to other information tab > observe the warehouse
Bug:
The warehouse was W instead of NW
opw:2254084
closesodoo/odoo#51237
X-original-commit: 80c0821c0e902a68f15a839ff7d2f6beece43dc3
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Install Contacts
- Create a contact: Company A
- Add a contact to that company: John
- Add a private address for John
- Save
- Change John's company
- Go back
- Look for the private address
The display_name contains the old
company name
Cause
The private address display_name is
not recomputed when the contact's
company changes.
Solution
Recompute child_ids display_name
when the company changes.
OPW-2253785
closesodoo/odoo#51450
X-original-commit: b112c8921eec60c63cead37c74946d06b499eb6a
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
When generating a payment link through the payment link wizard, the
company was previously not included. This could cause accounting issues
if the acquirer displayed to the customer were not part of the same
company as the underlying document that generated the link.
This commit add a new computed field 'company_id' on the wizard model
that gets computed based on the underlying model; this field will be
included in links generated by the wizard to limit the acquirers
displayed to those of the that company, preventing extra acocunting
steps (interco reconciliation).
opw-2254011
closesodoo/odoo#51441
X-original-commit: a6fcd7e0cfec8d4c62620a53b5fa806561e239af
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Purpose
=======
By using the user's related company to create a employee, we prevent
creating several employees for the same users on the basic flow.
But this is exactly the way we want people to use the system.
Example: Jojo is working in Belgium, has a belgian employee liked
to a belgian user in the system.
Now Jojo is about to work during 1 year in another company, based in
the USA. Jojo wants another employee, to manage the HR things
properly (payroll, ...), but he doesn't want to have 2 users, he
prefer to manage all its notifications in the same place.
We create another employee for Jojo, in the US company.
So instead of creating the employee in the user's company (Belgian),
as it would raise an error for the second employee, we should use the
contextual company instead, allowing to create the second employee
smoothly.
closesodoo/odoo#51435
X-original-commit: 0318f0acc5e98950c274c90a86a94d4588d2966d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the `Create Employee` button was not visible if user is linked to employee in any other company as the domain was based on `employee_count`. (Which represents Employee belongs to all companies)
With this commit, we check for `employee_id` which makes sure if the user has linked Employee for currently activated company.
Followup on 95564bcd2c
X-original-commit: cb9ac24caea53615e2808a36e850939a1ccaa041
- Install Inventory, base_automation
- Create an automated action on stock.quant, trigger on Update, code
raise Warning('My Warning')
- Create a transfer on a stockable product with e.g. 10 quantity on hand
e.g. Initial demand is 9
⁻ Mark as todo and Check Availability: on the transfer the reserved
quantity is not updated, but on the stock.quant it is updated to 9.
You can check availability again and nothing will happen on the
transfer, the stock.quant "Reserved" will be updated each time though.
You can update the quantity on hand to 0, and you will get
products with Reserved Quantity when Quantity in Hand is 0, and no
MO/Transfer or any other activity holding the reservation.
Adding the rollback when exception is raised
opw-2245109
closesodoo/odoo#51429
X-original-commit: 3f9ac9d3bb507eafe3c074ae817641b9d9dc1c87
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate routing
- Go to Inventory > Deliveries > New Planned Transfer
- Add a line
=> the 'Demand' field is editable
- Save
- Edit
=> the 'Demand' field is not editable anymore
The field should be editable as long as the picking is draft.
It seems working at creation because the fields `show_operations` and
`is_locked` are not yet computed yet. It happens because `picking_id` is
not in the tree view.
We change the read-only condition: if `is_initial_demand_editable` is
`True`, the field is editable.
opw-2257498
closesodoo/odoo#51428
X-original-commit: 51d4d95b186777a740cf98803148df593a71f0b9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of the task is to remove the needaction message counter from
kanban view due to below reason:
- The user has access to unread messages on records from the discuss
item in the systray.
- It is irrelevant for user handling notifications through their mail
client
- It is only less UI item to worry about on the kanban views (as
features increase, we need to be careful not to clutter the views)
- The user can still use the message_needaction filter to get records
with unread messages
So in this commit we removed the need action counter from all the
kanban view.
closes odoo/odoo#51299
Taskid: 2257624
Closes: #51299
Related: odoo/enterprise#10613
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit makes easier to select records in list views, by
extending the clickable area to the whole cell, instead of the
inside of the checkbox.
closesodoo/odoo#51156
Task: 2247387
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
[FIX] account: reconciliation models: don't mix currencies when checking the candidates for applicability of a model
Before that, similiar amount of different currencies could be matched together, regardless of the exchange rate. We now entirely forbid this case from the reconciliation models.
closesodoo/odoo#51153
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As part of the kanban view cleaning done the below improvement
- When there is no global click on the kanban card, prevent the
'focus shadow' on card so remove the show on kanban record it
will only apply for global click class and quick create.
- On the dashboard opening a dropdown should close any other dropdown.
closes odoo/odoo#50536
Taskid: 2206372
Closes: #50536
Related: odoo/enterprise#10341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=========================
The goal of this task is to set up some kind of guidelines to make
kanban views consistent.
It is fine having different kanban views, but if a UI element is shared
among several kanban views, it should behave/look the same so the user
knows what to expect.
Kanban views can be split into two types:
==> 'documents' kanbans, such as res.partner, crm.lead, etc.
- those records are created/edited often, numerous
- 'opening' the card means accessing the record
==> 'dashboard' kanbans,such as stock.picking.type,account.journal, etc.
- those records are not created/edited often, there are much less numerous
- usually presented as dashboard, where 'opening' the card means
accessing a set of related 'documents' (clicking on a account.journal
to access account.move, or stock.picking.type to access stock.picking)
- configuration of the 'card record' is done through a dropdown to
access configuration
Here are some guidelines for consistency. Bear in mind that those are
not rules, but guidelines for consistency that we'd like to keep in
mind when designing.
==> 'documents' kanbans
- the record is accessed through global click
- the user avatar is at the bottom right
- the activity widget is at the bottom left (in last position if
there are other elements)
==> 'dashboard' kanbans
- the record is accessed through a 'Configuration' option in the card dropdown
- there is no global click, and therefore no focus shadow
- the dropdown icon (o_kanban_manage_toggle_button) is always visible,
with icon fa-ellipsis-v
- the listview counterpart should be presented as a dedicated
configuration menu, and shouldn't be in the 'dashboard action'
- links in the body of the card are structured as follows: link with
<count>+label, then any additional aggregated metrics (not link) to the right
example https://drive.google.com/file/d/1ZP6HDHTtC7cQ6rDWgqLoPs6U8JCeNVkW/view?usp=sharing
==> global guidelines
- the title font color is #212529, with 500 weight
- the subtitle font color is #666666, with 400 weight
- the font size is 1.083rem
- text overflow is handled through linebreak, not ellipsis
- numerical values are aligned to the right
- the kanban state widget is at the bottom right
SPECIFICATION
=================
AS per guidelines Improved follwing kanban/dashbaord view
- hr_job
- hr_department
- hr_work_entry
- hr_appraisal
- fleet_vehicle
- product_template
- sale_subscription_template
- crm_team
- res_partner
- event
- stock_picking_type
- mrp_eco_type
- maintenance_team
- quality_alert_team
- account_journal
Added the department menu on employee with default kanban view
Added sequence in hr_work_entry list view
TaskID: 2206372
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10341Closes: #50536
- Employees > Configuration > Planning Types and ensure the activity
type "To Do" is set to scheduled date several days after previous
activity (default should be 5 days);
- Check that onboarding Plan has at least 2 activities with activity
type "To Do";
- Click launch plan.
Before this commit, the activity type configuration is ignored and all
activities are due tomorrow.
Now, the activities are due taking into account the activity type
configuration.
opw-2255586
closesodoo/odoo#51423
X-original-commit: c159479d7f714f2ec871cc4b965de3f961160789
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When we build a new box we make a update && upgrade of the raspbian image.
But it upgrade "firmware-brcm80211" from version "1:20190114+rpt4" to "1:20190114+rpt5"
With this update and when Odoo run on the box the "wifi access point" can't be activated
With this commit we unabled the update of this package and keep the "1:20190114+rpt5"
closesodoo/odoo#51409
X-original-commit: 5071867d7733d91e77ecf222a78a5993aca44781
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Add Total Receivable and Total Payable to contacts list view.
Create Vendor Bill for a partner with $0 Receivable and Payable - the
Payable amount is updated in the list view.
Create an invoice for this partner - the Total Payable is changed to $0,
and the Total Receivable is updated in the list view.
Create a Vendor Bill for a partner having a Receivable amount - the
Payable is not updated.
This occured after commit 9920f20e4c
In a situation in which the lines retrieved from the db are arranged
like
|pid| type | val |
|---|-----------|-----|
| 10| payable| 500|
| 14| receivable| 200|
| 14| payable| 300|
line 3 will cancel line 2 because partner credit will be set to false
after the debit update.
Fixing by checking that the same partner has not been processed yet
opw-2250989
closesodoo/odoo#51351
X-original-commit: 0274d61a11c6f5220d6af37a38adafb3e5276224
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Daniel Blanco