As the `purchase.order.line` `state` field is invisible but editable in
the RFQ form, when the user will create a new line, this new line's
state will be save with an empty value instead of taking the RFQ state.
closesodoo/odoo#53952
X-original-commit: bd2172e2a0f2b1e0e4de48f25381677f5ac24820
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
1. Show only date not datetime on update portal. When update the
scheduled date, set it to be the last minute of that date.
2. Send updated date immediately when user pick a date.
3. If an activity for update the date already exist, update the
note instead of creating a new one.
Task #2265912
PR 52809
Purpose of the task is, we have added the activities on various
listviews, the goal of this task is to update SO/PO/invoice demo data
with activities and also set tags on sales orders.
So in this commit, We added the activity on several SO/PO/Invoices and
also added the some tags one sales order and set the user as False
where the user is set as 'Odoobot'.
closes odoo/odoo#51799
Taskid: 2254708
Closes: #51799
Related: odoo/enterprise#10743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit sets attribute sample="1" in a bunch of list and
kanban views, to enable the new sample data feature when views are
empty.
Task 2232801
X-original-commit: 5471309b35619f307242c2704c7681ba63d2be42
Some changes in AbstractModel have been done to ease the
implementation of the sample data feature. This commit reverberates
those changes in other addons.
Part of task 2232801
X-original-commit: dd8069a3c80570e7fa03a80dbb100ab0a182692a
For the sample data feature to work, rpcs done by the view need to
be mocked. This commit properly mocks the 'retrieve_dashboard'
function. It also remove custom no content helper style that was
conflicting with the new style in web.
Task 2232801
X-original-commit: 300bc6d9ac2c1bea823bfc80675ffcf8e5dd3e9f
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
When set scheduled date on PO line, set it to be the last minute of
that day to correctly decide the late of the receipt.
Task 2265912
PR #52693
Related: odoo/enterprise#11034
Related: odoo/upgrade#1323
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Some change to imporve reminder mail usability:
1. Scheduled date on POL of the PO form now is always editable.
2. Improve tooltip for the reminder email
3. don't show number of days when reminder email not checked on
both PO and partner form.
4. only show "confirm receipt date" button in debug model
5. In the mail, format date by partner.lang
6. Add button to send preview reminder mail
7. On default, receipt_reminder_email on res.partner is False
8. merge expected_date with date_planned (done by FP)
Task 2265912
PR #52693
Purpose of the task is to remove the activity_exception widgets to
avoid redundancy. We have already added the activity on some list view
so activity expection widget on those list view is useless.
So in this commit, remove the activity_exception widget from
following tree view
- hr.expense.tree
- hr.expense.sheet.tree
- note.note.tree
- project.task.tree
- purchase.order.inherit.purchase.order.tree
- sale.order.tree
closes odoo/odoo#52109
Taskid: 2266720
Closes: #52109
Related: odoo/enterprise#10846
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1. automatically send a reminder mail to vendor to confirm the receipt
date. If confirmed, (confirmed by vendor) will be added next to the
receipt date. If not, vendor can update the date on the portal website.
An warning activity will be set for the purchase representative for this
update.
2. Vendor can also comfirm recieption of the PO when we 'send PO by mail'.
If confirm, (confirmed by vendor) will be added next to the confirmation
date. An filter is added in the PO search view to show all unconfirmed
PO.
Task 2230811
PR #49921
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The management of the join contexts now relies on the `Query` object,
that has all the necessary logic to do so. The refactoring also removes
the class `ExtendedLeaf`, which is no longer necessary: the join
contexts are all managed by a single `Query` object, and the parsing
stack now only contains triples like (leaf, model, table_alias).
Also inline directly the SQL translation made in `_to_sql`, which
overall simplifies the management of SQL parameters in the domain
compilation. The algorithm is illustrated in the code itself.
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
Merge account_analytic_default into account
Merge account_analytic_default_hr_expense into hr
Merge account_analytic_default_purchase into purchase
Prevent having to manually install default modules after activating analytics
closesodoo/odoo#50816
Task: 2182900
Related: odoo/upgrade#1186
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit adapts several views to make them use newly defined
widgets, the new decoration-xxx mechanism on fields, and to adapt
them to the new design of buttons.
Part of task 2195254
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
Improve onboarding and guide first clicks of users in the purchase application
to create a purchase order.
In case Stock module is installed, it will also guide the users
through the receipt first clicks process.
Task ID 2219988
closesodoo/odoo#49031
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Minor improvements/fixes:
- Prevent overlap of 'o_view_nocontent' (when there are no relevant
records) with kpis table in list/kanban views on small screens/windows.
- Create separate list views to prevent kpis table appearing in
appropriate situations (e.g. action windows showing linkages between
purchase orders and other models.)
- Override bootstrap styling that was making kpi table wider than the
width of the window in list view.
closesodoo/odoo#49509
Task: 2228175
X-original-commit: ee831f7aff400f76e20e54b7cb9b5610bcec4839
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In compute method _compute_expected_date() all PO lines
are processed to get expected date, but in note and section
line we dont have date_planned, it generates error. filtered
the PO line to process if only they are not having display_type.
Fixes-2234053
closesodoo/odoo#49433
X-original-commit: 2163c6a05476ddfbf899e46eac565b7f5cc5f46e
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Currently, when we add many2many field relation with purchase.order in view
where view does not have state field, it throws error, it is because
purchase.order list view has attrs for column_invisible which parent.state
which is wrong, purchase.order will not have parent.
With this commit, remove wrongly added column_invisible attrs on invoice_status
field.
task-2195175
closesodoo/odoo#49416
X-original-commit: 79a738fb7fa852c4e2e9fc127fa63dbc4ffd4a53
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Filter out section and notes from the invoice status computation.
opw-2233550
closesodoo/odoo#49301
X-original-commit: 55d3c59235cadb70aa9206eaec7ff1e4631fb019
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before the commit, when there is no pricelist, we set the unit price to be 0
on the PO. After the commit, when in the same situation, we use the cost
set on the product form.
Task 2072560
PR #49067
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- moved company_id in other info tab
- currency_id is shown near journal_id
- invoice:
-- ref renamed to 'customer reference' and move to other info tab
-- payment_reference hidden if state is draft
-- Fixed bug in l10n_in where xpath did not find removed element
- vendor bill: auto-complete only shown in edit mode
was task:2209497
closesodoo/odoo#48913
X-original-commit: 170635c901914cfe8f33fdbe8d498cbd5f54054e
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- Let's consider a vendor V with a supplier currency €
- Let's consider the current company's user C in $
- Let's consider two vendor bills journals J1 in € and J2 in $ from C
- Create a vendor bill for V
Bug:
The default currency was $ instead of € and the default journal was J2 instead
of J1. This fix keeps the same behavior as implemented in 82794c8662
opw:2226115
closesodoo/odoo#48857
X-original-commit: 801182f6222521c2961560b3b67743a143a22eff
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Adds a customized table to top of list and kanban views of requests for
quotation (RFQs). This table includes the following values:
- RFQs to Send (PO.state = 'draft')
- RFQs Waiting (PO.state = 'sent' and PO.date_order >= now)
- RFQs Late (PO.state = 'sent' and PO.date_order < now)
- Avg Order Value (specifically only for POs)
- Avg Days to Purchase (PO.date_approved - PO.date_created and PO.state
in ('purchase', 'done'))
- Purchased Last 7 Days (specifically only for POs)
- RFQs Sent Last 7 Days (hacky calculation looking at chatter for state
change 'RFQ' => 'RFQ Sent')
This change corresponds to "Requests for Quotations KPI's" subsection of Purchase
KPIs task.
Task: #2198420
"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.
Added new values "Average Days to Purchase" and "Average Receipt Delay" to be
used in purchase enterprise reporting tab where:
Days to Purchase = confirmation date (i.e. 'date_approved') - creation date
Receipt Delay: effective Date - ('date_planned' or 'expected_date' if
no 'date_planned)
Note that these 2 new values are specific to purchase orders only.
Because of this the standard query result cannot be used since it is
done at the purchase order line level. This means duplication of PO
values occur and results in incorrect aggregation calculations. A hack was
done to ensure that these value will aggregated correctly when used at the
enterprise level. Therefore these 2 new values should only be used in
aggregate.
To support these new measures the following updates were also done:
- Addition/improvement of help descriptions for other date related
measures to avoid confusion
- Change state string to "Status" to match purchase.order (for
consistent filtering purposes)
This commit supports "Adapt Reporting" subsection of Purchase KPIs task.
Upgrade PR: odoo/upgrade#877
Enterprise PR: odoo/enterprise#8945
Task: 2198420
Adds "Expected Date" and "Effective Date" fields to purchase orders to
match what exists in sales orders. "Effective Date" mirrors sales logic
(= first completed stock move). "Expected Date" has simplier logic due
to simplier nature of receiving stock vs shipping (= earliest "Scheduled
Date" of all PO lines). Form view has been updated to include these new fields.
Additionally code was changed to not have PO 'order_line.date_planned' be
overwritten by the 'purchase_order.date_planned' value. Previous behavior
was both confusing and made it so info was lost. Also logic for related
stock move picking line expected date values has been updated to now consider
'purchase_order.date_planned' value if set. Related changes include:
- not overwriting when PO is edited+saved (this only occurred in write()
logic, not create() which caused inconsistent behavior anyways.),
- updating related tests,
- removing PO line date_planned editing restriction when PO date_planned
is set
- updating of relevant stock moves/picking expected date due to
PO.line.propogate_date = True ('purchase_order.date_planned' if
exists, otherwise 'order_line.date_planned')
This change also includes some small related improvements:
- Removal of outdated code comment.
- Addition of Help strings to better explain fields.
- Prevent copy of 'date_planned' value into new POs (now mirrors sales
logic).
This change corresponds to "Receipt Date on PO's" subsection of Purchase
KPIs task.
Task #2198420
Several improvements in order to improve user interface are done here.
[IMP] purchase: Prevent create PO&RFQ in calendar
It was possible to create PO's and RFQ's from the calendar view.
The Product Owner wanted to prevent the users from doing so.
[IMP] purchase: Add tooltip to Receipt Date
[FIX] purchase: Align report & stat button data on product form
The use of Last 365 days time_range in the purchase analysis was automatically
excluding today's purchases wich was confusing users as the stat button info
was taking those into account.
Different behaviours were implemented for product template and product product
in the filters that were used which makes no sense.
Use of context_today() instead of datetime.now() in order to take the user's
timezone into account.
[IMP] purchase: Use relevant dates for RFQ's and PO's in calendar view
The date used in order to display RFQs and POs in the calendar was date_planned
which is not mandatory and so not always filled. It has been decided to use the
order_date for the RFQ's and date_approve for PO's.
[IMP] purchase_requisition: Making Agreement selection type more explicit
[IMP] purchase: Show UOM menu only if installed
[IMP] purchase: Add product variant in settings
[IMP] purchase: Remove Favorites predefined filters
[IMP] purchase: Rephrase PO action helper
[IMP] purchase: Allow open/edit Agreement Type
[IMP] purchase: Rephrase RFQ action helper
[IMP] purchase: Remove PO's and RFQ's name from fields in calendar
The Product Owner originally wanted to have a link on the PO name field
that was shown in the calendat popover. As the Edit button already allows
to edit the PO's or RFQ's from the popover it was decided to simply remove
the field (as it was already displayed at the top of the popover)
[IMP] purchase: Open the right view when click on Reporting top menu
Task ID #2196688Closes#47810
Related: odoo/enterprise#9294
Related: odoo/upgrade#961
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
========
Purpose
========
Currently, purchase missing some billing functions that we have in sale
invoicing:
- Create credit note when necessary
- Create vendor bill in batch in list view
========
Spec
========
- In case of retures, when create a bill for a purchase order, we check
the total amount we want to bill to decide whether it's a vendor bill or
a credit note.
- In the list view, add a new action to create vendor bill/credit note
for all selected order.
========
Links
========
Task 2170715
PR #44210
Related: odoo/upgrade#919
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The 'vendor bills' stat button on purchase order, once clicked, will
have a specific behavior depending on the invoice count :
0 : open a new invoice with pre filled fields (not saved yet)
1 : open the form view of the invoice
2+: open the list view of the invoices.
Before this commit, the invoice count was computed with an environment on
the current user. That means a record rule could make the invoice count
lower than the real count and so give an unwanted behavior. Ex: create a
new invoice even if there is already one created because the user cannot
see the other people's invoices.
After this commit, the action_view_invoice with make an explicit read()
in database to fill the cache with all the purchase order's invoices and
make sure the count is the real one.
Task : 2206969
closesodoo/odoo#48274
X-original-commit: e3101d92187946b2bd539e05956e4e83cd9c9097
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, the purchase users get an access violation error
at the invoice creation from a purchase order. This was due to
some missing ACL between v12 and v13.
Task : 2206969
X-original-commit: 4c4fb33e4bbc78a85ad309baf5df906cf16566ea
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
stdout:
stderr:
closesodoo/odoo#48197
Error: could not apply b0c5370fd25... Revert "[FIX] web, purchase, sale: fix no currency in calendar view"
Hint: after resolving the conflicts, mark the corrected paths
Hint: with 'git add <paths>' or 'git rm <paths>'
Hint: and commit the result with 'git commit'
X-original-commit: e8d6f1eae0f4f9c0f4df78553b7d51a03087940f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
svs-odoo