Change capital letter "A" in Invoicing Address ..etc
Added space between address and "Quotation number"
Remove the time of the quotation date
Replace "expiration date" next to "quotation date"
Rename Optional Products to "Options" and place it above the terms and conditions.
TaskID: 1920476
closesodoo/odoo#30550
The list view of account.move.line is now editable (and grouped by
account.move by default).
Morever, when grouping by move, there are now action buttons in the list
view header.
Part of task 1915702
closesodoo/odoo#32337
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
By using proper BS4 classes for alert, so it looks better and it is more
compatible with themes.
Also removed the unused "Option not available".
closesodoo/odoo#32061
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Base issue: unnecessary inherit of composer on mail.message. Indeed there are
a lot of unused fields coming from mail.message as well as message specific
behavior (notify, check access, various business methods) not relevant for
composer.
Specifications
* remove inherit from mail.message;
* re-define used fields;
* ensure everything still works;
Commit linked to task ID 1907153 and PR #28464
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Mail composer does not support channels. Indeed as it can be used to post
a message or send an email it only supports partners. Previously field
channel_ids given to the composer was used only in website_forum. However
it is not used and therefore simplest way of solving it is to remove it.
Anyway allowing to have channels followers of forum tags and being notified
of new publications is probably more spammy than really necessary. Especially
that it never worked.
Commit linked to task ID 1907153 and PR #28464
Some counters are not up to date notably taking in to account community-only
and test-mail with enterprise only counters. Those are used notably when
developing to ease quick check of counters.
closesodoo/odoo#32370
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 1934667
1. That's the partner type (and not the payment type) that should define if a payment is a customer or a supplier payment :
a. When the partner type on the payment is "customer", the payment should be considered as a customer payment
(and thus be visible from the menu customer payments)
b. When the partner type on the payment is "supplier", the payment should be considered as a supplier payment
(and thus be visible from the menu supplier payments)
2. The PoS should only create customer payments (you never pay suppliers through the PoS)
The payment created should be with a partner type "Customer"
But the partner field can stay empty if the customer wasn't set on the PoS Order
3. When I change the payment type while creating a payment from scratch, it shouldn't change the partner type
Example : I'm creating a payment for a reimbursement, I'll create it from the customer payments menu (as I'm paying a customer), I'll tick the payment type "Send money"
I don't expect the partner type to change to vendor.
closesodoo/odoo#32201
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Removes the 'Show Reserved' option in operation type (PickingType).
Task #1944853closesodoo/odoo#31523
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In case it's appropriate (using multilocation or lots/serial numbers)
the 'show detailed operations' option is active by default when a new
operations type is created.
Task #1944853
The code that is in charge to prevent deletion of required fields or
duplicate of model field was not working anymore since 11.0.
That code should still be refactored in master to be more robust.
opw-1919630
closesodoo/enterprise#3337
Before this commit, RTL on frontend was only enabled for connected user.
To have RTL, we add the direction on the element, and the RTL version of
the stylesheet for the applicable languages are generated thanks to rtlcss.
opw-1892757
closes#28434
Odoo 12.0 does *not* officially support any python version below 3.5,
but no effort had been made to gracefully announce this to the end user
if they were to run Odoo in an unsupported python version.
This is done because Odoo 12.0 uses py3-only constructs which can
and will raise different errors if ran in python 2.
With this patch, Odoo will display an appropriate error message and won't
launch at all unless it is being run with python 3.5 or greater.
closesodoo/odoo#28502
Suppose you are editing a SO to add a new line. Depending on the configuration,
a sale order line wizard may open (e.g. if packages are activated).
This wizard is a form view, opened from the tree view of the sale order lines.
We have commit 8e5156938a
that adds extra fields from the originating view.
(However it doesn't work if the other view is inlined, so we modify this part to
add the extra field even in this case.)
Then we need the field info from the origin view in the target view;
we do so by extending the former with the content of the latter.
opw 1904337
closesodoo/odoo#28441
Stock moves show a detailed operations icon if the tracking, locations, or
consignment allow to be configured.
However it did so on a per move basis, only displaying it if the considered move
has some of these features.
This fix makes it that the "detailed operations" icon is always displayed if at
least one group of group_tracking_lot, group_stock_multi_locations, or
group_tracking_owner is active, or the move is tracked,
unless the move picking type already does show detailed operations.
opw 1893106closesodoo/odoo#28072
Create an automated action to create a new activity on update of a record
(e.g. a CRM lead).
At update, many fields recompute may be triggered, triggering as many write.
Thus it would generate many activities.
We simply do nothing if we are in a recompute.
Coauthored by rco
opw 1904156
closesodoo/odoo#28498
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
Also the behavior of not clearing the message if there was an error is
introduced back.
Without change in code, added test fails with:
"Should keep unsent message in the composer on failure" (result: "")
"Send button should be re-enabled on message post failure" (result: true)
issue found when checking opw-1904029
closes#28475
- Create a SO
- Paid the SO using a transaction
- Create an invoice from the SO
=> The invoice will now be reconciled automatically with the payment transaction
Was task: 1890029
Was PR #27390
Before that, with "post at bank reconciliation option" activated on bank journal, the following scenarii did not work as expected:
1. When creating an invoice, making two payments for it, and then matching only one of them with a bank statement
=> the invoice was marked as 'paid' while it should have staid 'in payment' until the second payment gets a bank statement.
2. When directly reconciling a bank statement with an invoice for its full amount
=> the invoice staid in "in payment" state, while it should have been "paid"
[IMP] account: add tests for the aforementioned cases
closesodoo/odoo#28428
Sometimes, a sale.order in the SALE state doesn't have a confirmed date,
which can cause a traceback. To avoid this, when confirmation_date is
null, use the write_date, which is never NULL when sale.order is in sale
state.
In migration, we will try to populate the confirmation date with
the mail.message subtype. As ultimate fallback, we will take
the write_date.
closesodoo/odoo#28296
Create an accrual leave, and set it e.g. by employee tag.
For each employee having the tag, a child allocation will be created.
When doing so, it will prepare the values for these creations.
However the relevant fields for accrual leaves were missing from these values.
opw 1906476
closesodoo/odoo#28492
1. Create a payment term with:
- 50% due now
- balance due in 14 days
2. Validate an invoice with this payment term and partner Agrolait
3. Create a payment from Agrolait with the 50% due
4. Add this outstanding credit to the invoice
It is reconciled with the balance due in 14 days instead of what is
due now. Because of this e.g. the Aged Receivable report will show the
customer being overdue with a payment.
This issue was first fixed in 9.0 at
adad192cc0. It was then reintroduced in
saas-11.4 at d3d2612061. This commit
adds a test to avoid regressions like this.
To fix the issue this sorts journal items by their Due Date if there
is one. Otherwise we use the date from the journal entry as before.
Note that before this commit journal items were not sorted at all by
the two 'sorted' statements. sorted returns a sorted recordset, it
doesn't modify the recordset it's called on.
opw-1906665
When changing the field `image` on `res.users`, the `write_date` of the user is
not updated because the field is inherited from `res.partner`.
Related to Issue : 1839603
This code is called by account_reports to build the Aged Receivable/Payable.
However, no support for the multi-company/multi-currency is there and then,
the multi-company filter on account_reports never worked.
In a multicompany environment, an user who has access to multiple companies is
able to select accounts and analytic accounts of multiple companies. This can
easily lead to mistakes in the definition of the asset category.
With this commit the user can only read/select accounts and analytic accounts
belonging to the company already set in the asset category.
This is what is already done in most invoice or other accounting views
Closes#26578
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
payment_term.id, creates a tuple wich works if payment_term.id is set
in case payment_term.id is False this creates the tuple (False,) which
is then converted by the Odoo ORM to a account.payment.term(False, )
record set, which in term may cause weird behaviour as this value does
not eval to false in cases like `if self.payment_term_id:`
Closesodoo/odoo#28397
Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
Prakash Prajapati