Currently, if users try to send invoices / quotations / purchase orders to
themselves in order to look at final result, they can't do so because our
default chatter protection prevents sending mails to authors themselves.
This commit uses 'mail_notify_author' context key and allows users to send
mails from the header buttons available on SO / PO / invoices to themselves
if they are in recipients.
This commit targets only those buttons as this is the main case where we
want to allow people to send emails to themselves. In order to avoid
side effects no other use case is supported.
Task ID-2294130
closesodoo/odoo#56370
X-original-commit: 08c0dc929da38595e29a9d1db93065547cd98ad1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 2034073
The reconciliation widget is now entirely part of the enterprise version
as it is an advanced accounting feature
closesodoo/odoo#38424
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
PURPOSE
This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. We will also add relevant
statistics on utm campaign model in order to use it in various applications.
SPECIFICATIONS
This commit adds revenue and quotations statistics on the
kanban and the form view of the utm.campaign
Kanban and form views will now display the invoiced_amount
and the number of quotations generated by the campaign.
TaskID: 2002029
PR: #34452
In the previous commit the analytic entries generation when posting a
move was optimized to be done in batch. The performance is break
when sale module is installed. Indeed, in case of reinvoicing a
analytic line, AAL creation will trigger a sale.line creation.
This mecanism is very inefficient because
1/ AAL creation and Sales line creation are not batched
2/ sale line creation is done after the AAL creation, and then linked
with a `write` operation. So one `create` and one `write` per AAL to
reinvoice.
3/ To determine on which Sales Order to reinvoice, many `search` can
be performed per AAL.
Also, this looks strange that AAL creation might result into a sales line
creation.
This commit changes this in order to optimize and clean the code:
- the account.move.line (that creates the AAL) will also create the
Sales lines
- SO lines creation will be done in batch
- minimize the number of `search` done during the process
- the SO line will be linked to the AAL by passing the SO line id in the
create values of AAL (no `write` operation one AAL and SOL are created).
This was the last part of legacy code of 'sale_analytic.py' that we need
to get rid of. There are still work to do, but I think now, the
business case handled here can now breathe and have a peacefull life.
Task-1911898
closesodoo/odoo#28939
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
We now display a message informing the user that the statement line is matching a sent/to_invoice SO. The user can thus decide to follow the link and confirm the SO, create the invoice and come back on the reconciliation widget to reconcile the prepayment with the validated invoice (automatically detected).
Was task #1879015closesodoo/odoo#29312
According to the setting set on the pricelist
More the discount_policy field from sale to product to be usable in point of
sale, even without sale installed
Task id: 1853454
closesodoo/odoo#27310
[MOV] move sale_payment into sale
=================================
Almost all use cases of sale require sale_payment down the line.
There is only one case which does not: using sale_management without website_sale or website_quote.
However, since we want to move most of the features of website_quote into sale_management, moving sale_payement first will make the task easier.
[MOV] move website_quote into sale and sale_management
======================================================
We want to use some features of website_quote without having to install the whole module.
The main issue with website_quote was that it had a requirement on website.
What is common to website_sale and sale_management has been moved into sale. This is primarily the sales order portal view.
What is only related to sale_management has been moved into it. This is notably: sales order templates, optional products, sign and pay, ...
Everything that requires website has been moved into a new module named sale_quotation_builder. This is related to using the HTML builder to customize the quotation view.
Models, files and routes have been renamed to better convey their purpose and to follow guidelines more closely.
[IMP] merge sales order portal views
====================================
The old sales order view on the portal has been merged into the one from website_quote. The new view contains features of the two.
A lot of fixes and improvements have also been done, related to BS4 issues but also to improve the sales order view in general.
[IMP] add new settings
======================
The commit adds new settings related to activating the features that previously were activated by installing website_quote.
PR: #26345
Task: 49205, 1838924
The goal is to be able to more easily create section and notes on sale order, invoice, and quote.
================================
Problems of the existing feature
================================
The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.
Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.
==================
New implementation
==================
Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.
We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.
=========
Reasoning
=========
We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.
Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).
The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).
We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.
No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.
===========
Limitations
===========
The current solution has several limitations:
* since the sections don't have business logic, it's not possible to make any reporting based on them
* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display
- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section
===========
Technically
===========
The commit will:
* update the models to add the display_type field (along with related sql constraints to guarantee integrity)
* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button
* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)
!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.
* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)
!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.
Task #53996
PR #25209
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
The field `auth_signup_uninvited` is defined in the 3 aforementioned
modules, yet they are independant modules in respects to one another.
This means that whichever module is installed first will create an XMLID
for the field, if this module is uninstalled before the other two: boom!
crash when changing general settings because the res.config.settings
field set by the other two modules no longer exists.
To solve this, we simply ignore the field during ir_model_field.unlink()
Fixes#23171
The handling of analytic lines to sell is a little
mess. We can reinvoice analytic lines from timesheet
or expenses, or manual lines.
This commit tries to clean the code, factorize it,
make proper hook (see _sale_postprocess method)
and move specific in its corresponding modules.
Code was properly split, in order to make modules responsible
for only their own features:
- sale module handle the link of SO line to an analytic
line, and increment the delivered qty accordingly.
sale also provide the mecanism of determine magically
the SO lines of an analytic line with an expensable product
to reinvoice it at cost.
- sale_timesheet identifies the so line concerned when
timesheeting on a project directly. Also provide the domain
of analytic line when setting the SO line on AAL.
Cleaning is necessary for futher dev.
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
Dharmraj Jhala