The company_id field is present twice in the view.
Fixes#40328closesodoo/odoo#40353
X-original-commit: 8d5b25417eb890aed56c9f1365100aa061b9bd8c
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a tax of type "Fixed".
- Put some name in its 'Label on Invoices' field.
- Change the type to "group of taxes".
The view hides the field Label on Invoices, since it doesn't make sense
any more. However, it doesn't actually remove the label on invoices.
As a result in the taxes list you can still see the old label on invoice
information, this behaviour misleading.
We modify an existing onchange to avoid that unfortunate situation.
opw-2115984
closesodoo/odoo#40346
X-original-commit: 1aea26c72d451e13754e911a6bb74fff0e2578df
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Currently, if the first week day was Saturday the calendar week view
would possibly get the wrong week.
This is because current heuristic would get date of current week from 6
(Saturday) to 12 (Sunday).
Thus if we were:
- on Friday 14th, we would have a week day ranges: 15-21 (wrong)
- on Saturday 15th, we would have a week day ranges: 15-21 (ok)
- on Sunday 16th, we would have a week day ranges: 22-28 (wrong)
So it would only get the right range when getting range from saturday.
If a week:
- start on monday, the week range would only be wrong on sunday.
- start on sunday, the week range would always be alright.
Added test without the fix fail:
- CalendarView: Saturday week start week mode
The domain to search events in should be correct
(domain range 14-20 instead of correct 07-13 whilst the day was 12th)
- CalendarView: Monday week start week mode
The domain to search events in should be correct
(domain range 16-22 instead of correct 09-15 whilst the day was 15th)
opw-2091448
closes#40244closesodoo/odoo#40327
X-original-commit: 6c3d74846581d6c1bfc0c6e3a7104440515ddbc5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
*: point_of_sale
In c212cfe899 the field 'datas_fname' was
removed as it was mostly almost always a duplicate of the name or url
field. Two uses of this field were not removed in the rest of the code,
one in web_editor which caused a crash when trying to save a cropped
image. There was also one in pos_order, which I changed at the same
time, even though it isn't known to cause a bug yet, the create call is
bound to fail if it is ever triggered.
closesodoo/odoo#40329
X-original-commit: 7088d11b7f2de7ffaa5b7045b562784f7176f75d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Pingen is a service that print (like really, using a printer) pdfs
document in order to mail them (using the real post and postmen). In
order to ensure we are compatible with their API, we send to their
sandbox environment a bunch of standard documents (like an invoice).
Those PDFs documents are generated our side using wkhtmltopdf but as the
test were not started using a HttpCase, the assets were not correctly
available.
This also reverts commit 3f5a0a1ef4.
closesodoo/odoo#40323
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Reproduce this bug
- Install Calendar
- Create a recurring event starting at the date of yesterday
(later than your actual time)
- Set the recurrency to every day, 1 time (today)
- Click on the today's event
- Add attendees > Invitations > Send mail
- Run the mail queue manually (Technical > Scheduled actions)
The mail you sent are for the date of yesterday
The behavior is the same for the reminders
Cause
The mail are sent with the `_send_mail_to_attendees` method
who pass the attendee_id to the templates.
The `attendee_id.event_id` is always the first one.
This commit pass the correct event to the template via the context.
I replaced only the dates values in the template.
closesodoo/odoo#40320
X-original-commit: 1926c6cfea0e21842fbd71fd85629b13fce9b413
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
Promotion programs can be added in 3 ways, no_code_promo_program_ids,
code_promo_program_id, and through applied_coupon_ids.
So free delivery obtained by the two latter would not correctly update
the cart page, because the result of _get_free_shipping_lines would be
empty.
closesodoo/odoo#40317
Forward-port-of: https://github.com/odoo/enterprise/pull/6663
X-original-commit: bfde75dd72d1e529bfb93d2b83b22b8c2f0fcea1
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Purpose of the task is to add python tests to check the values
returned by '_qweb_prepare_qcontext' method
Task-2084995
closes odoo/odoo#39299
Closes: #39299
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this fix translations of the order names missed a crusial space
that is needed to get information out of it in the front-end.
* Load Spanish-PE translation.
* Change localization preference for a user (either admin or demo) to
Spanish.
* Login to Odoo POS using the user with spanish localization.
* Go to POS, select BAR POS, select a table and place a draft order
with at least 1 order line (do not proceed to payment)
* Go back to table mgmt view and click again to the previous selected
table and the error appears.
This issue happens in any translation where pos_reference for a draft
order is not separated with white space as it happens in English. I mean
in english the pos_reference is something like "Order 00003-001-0002"
but in spanish it is "Pedido00003-001-0002" (no whitespace), so
https://github.com/odoo/odoo/blob/13.0/addons/pos_restaurant/models/pos_order.py#L143
assumes that there will always be a whitespace which is not true for
some odoo translations like spanish one.
This fix adds a variable to the translation string making it more clear
the space is part of the string. To make sure the code will also work on
languages with the words in another order `order['pos_reference'].split(' ')[1]`
is replaced by `search(r"\d{5}-\d{3}-\d{4}", order['pos_reference']).group(0)`,
we know the uid will always be formatted as nnnnn-nnn-nnnn
solves #40036closesodoo/odoo#40302
X-original-commit: c32126da5ac55a03637d82cf520b8655be8546e6
Signed-off-by: Gert Pellin - GPE <switch87@users.noreply.github.com>
In a view month of calendar, when seen the details of a non-all day
event.
Before this commit, the end hour was always 00h00m.
Now, the end hour is the encoded one.
opw-2093111
closesodoo/odoo#40287
X-original-commit: 92fe5f11c16ee6749c4b0834ec12e5e858b1748d
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
In a view month of calendar, when moving a non-all day event from a date
A to a date B.
Before this commit, the event will be changed to an all day event type.
Now, the event will be staid unchanged, only the date will be updated.
opw-2093111
X-original-commit: df001af5341bf35f36fe455d69bbb46f4b0fa00c
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Ignore exceptions when resolving dependencies in that case.
This reimplements a behavior from former versions.
closesodoo/odoo#40300
X-original-commit: 826c86e9ab31963e410887a30326f45bcfadf5ea
Signed-off-by: Christophe Simonis <chs@odoo.com>
With this PR we can use the IoT Box with the new Raspberry Pi 4 B
using raspbian 'Buster'
With buster we remove the kiosk mode of firefox and
replace this mode with a fullscreen view of firefox.
To do that we adapt DisplayDriver to expend window with a 'call_xdotool(F11)'
We remove postgresql and patch 'odoo/odoo/http.py' for he does not return a DB.
Task id: 2089286
closesodoo/odoo#40292
X-original-commit: d20676b69f37905c7994b3c55cb1bb6dfda3460e
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When installing requirements on MS Windows platform with Python 3.8, the
Pillow requirement is defined two times. This leads to a pip crash.
With this commit, the Pillow requirement is only defined once.
Fixes#40080closesodoo/odoo#40272
X-original-commit: cce9660c2969cc2715ff29b6dfa12e1b726bce25
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
stdnum is not a mandatory dependency
It is often present as required to install the base_vat module but
having a system with account without the dependency should be
possible.
As the calc_check_digits is pretty small, it is easy to extract
Forward port of 6091be6556d to 13.0
closesodoo/odoo#40265
X-original-commit: ef245e14730e5c4858b81adfbe7e309631688663
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
After loading the calendar view, making a search with an inactive
domain in the list will trigger a search "partner_ids not in []" which
returns zero result.
The code intention was to initialise the avoidValues, not to send an
empty list.
To reproduce the issue:
1. create an event shared between user 1 and 2
2. as user 2, open the Calendar menu
-> shared event is present
3. click on "week" tab (forcing a refresh)
-> shared event no longer appears
Fixesodoo/odoo#39839closesodoo/odoo#40264
X-original-commit: 299a6dbcb53e583b177079116ada63a1255d1cfa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, when modifying a Many2one in a form view to add a
new record, it will create the new record, and calculate the inverse
and write it in all the records of the list. This will call the write
method in all records even if they weren't changed.
Now, the inverse is set to be modified only if it's different from the
current value.
opw-2091842
closesodoo/odoo#40258
X-original-commit: 417cee7f0fdb7ed7eb424178efb656b967fa0a5e
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
Problem description:
Using the chatter, send an email to someone having non-ascii characters
in their name: the body of the received email looks like it contains
a mix of the original body and headers.
Python encodes the name into either base64 or quoted-printable but
leaves some redundant carriage returns at the end of the header. Those
redundant carriage returns are not RFC conformant but are interpreted
as newlines by some email clients, thus are read like a headers/body
separator and the next headers are considered part of the body,
corrupting the email structure.
This problem is internal to Python and has been fixed in 3.8, cfr
bpo-34424 [1], and later backported to 3.7.4. As we also support 3.6
and earlier 3.7 and it is not possible to easily monkey-patch the
function, we fixed it by squashing duplicate carriage returns.
(There is no case where a series of bare CRs can occur in a normal
RFC5322 email message)
Task: 2003936
[1]: https://bugs.python.org/issue34424
Issue: create an immediate transfer, add a move and a done quantity, the
picking is in waiting state instead of ready.
Due to rev[0], the moves added in an immediate transfer have an initial
demand. After auto-confirming them, their state were 'confirmed' and not
'assigned'.
Solution: we force the state to assigned
[0] 8303b1a69eclosesodoo/odoo#39492
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, move added in a planned transfer once it is ready are
directly marked as assigned and the reservation is disabled on them.
People found it hard to understand why the check availability button did
not appear, plus the push rules were not applied.
Now we chose to use the autoconfirm mechanism on the added move and we
don't reserve them, so the check availability button reappear.
task-2081844
Do not insert variable inside a translated message, it will not be
translated.
Fixesodoo/odoo#40178closesodoo/odoo#40255
X-original-commit: 4b7782e8f259480550d10479f43c95441306e48e
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Changing the filter color and its intensity was not working anymore
because of failed JS refactoring when the logic was shared for both
blog posts and events in website.
closesodoo/odoo#40227
X-original-commit: 3296468beded14d4ef52d221ef8683941f12291c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Somehow, the fact that this test has been converted (partially)
to a SavepointCase makes the assets to be rollbacked after generation.
Notify the registry to be in "test" mode, where one cursor serves several
requests, solves the issue (no 404 when getting the assets, and no
registry reloading).
closesodoo/odoo#40243
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Python 2 `email.tools.formataddr` doesn't encode not RFC-2822 compliant
realname to base64 or quoted-printable. This is the wanted behavior to
output formatted email addresses on screen.
Python 3 `email.tools.formataddr` does encode the realname to be
RFC-2822 compliant. This is the wanted behavior when connecting to a
smtp server to send emails.
That method has been deprecated by pep-594 as the new python email API
is capable of automatically formatting email address in a RFC compliant
way. As the method was still in use in a lot of modules as the
preferred way to format email addresses, a refined P3-like
implementation as been included in the tool suite.
This commit changes the default behavior so it mimics P2 implementation
with an easy way to use the P3 behavior.
Task: 2003936
It seems the emails > < are missing.
By the way one manual formataddr is replaced by an email_formatted field.
Result is the same but let us use fields doing it for us.
Cherry pick of 6317e47409f066312f1f5517b0be9ed386235397 failed
The spaces should not be important in a structured reference.
Also, we should not have to include the second batch as that batch
(previously the first) was intended to match the payment reference.
By including it, we may have too much false positives proposed in the
widget and even worse: auto reconciled.
closesodoo/odoo#39820
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Cash rounding only allowed for one account to be specified => Belgian accounting requires 2 types of account depending on whether the rounding line on the invoice is a + or - amount.
On cash rounding config (account.cash.rounding), one account is added (many2one). Existing account is renamed Profit account, new account is named Loss account.
The loss account is used when rounding line has a negative amount, and vice versa for profit account (account.move).
If no Loss account is set, only Profit account is used.
task : https://www.odoo.com/web?#id=2091658&action=327&model=project.task&view_type=form&menu_id=4720closesodoo/odoo#39488
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- Let's consider two storable products P1 and P2 from the same vendor V
- P1 and P2 have the routes 'Buy' and 'Make to order'
- Create a SO for 1 P1 and 1 P2 and confirm it
- A delivery order DO has been created
- A PO has been created for V, confirm it
- Process the shipment, receive 1 P1 and 0 P2 with no backorder
- Process DO with no backorder
- Return DO by clicking on 'Return' button
Bug:
1 P1 and 1 P2 were suggested to be returned but the movement for P2 had been canceled.
Closes#39547
opw:2116582
closesodoo/odoo#40220
X-original-commit: bb94b6591fb148a4c1b94f9c28d2c10e44e12283
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
_action_done() creates extra stock move when quantity_done is superior
to initial demand. This extra move should be, after confirmation, either
merge into the original stock_move, either stay extra but the move lines
still linked to the first one should be shared accordingly to the quantity
done. The fix 561b3461a0 adapted the code
for MRP to split the move lines but neither those cases are applied in
MRP because the extra move has no picking_id field.
condition :
```if merge_into_self and extra_move.picking_id:```
will therefore be false as well as
```if not merge_into_self:```
To be sure the two extra move management cases are complementary, this
Commit keeps make sure the conditions are mutualy exclusive.
closesodoo/odoo#40230
Opw: 2087864
X-original-commit: 4e8ac38a6d67bcd5040af0b580bfa43da7841548
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Reproduce this bug
- Log in as portal user
The top right address detail is over the icon.
Cause
The others fields are using a `span` who have a style who push them
right.
This commits add the `span` style for the div.
Fine-tuning of 9e302765
OPW-2092345
closesodoo/odoo#40225
X-original-commit: af0fd50b14f32032f0870812dd615ac988183174
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There is a constrains preventing writing debit/credit on an already
reconciled journal item. However, this constraint isn't aware about
monetary fields and then, was raising an error when writing amount
like 1.000001 on a debit of 1.0.
closesodoo/odoo#40214
X-original-commit: 7599758494198e64b5b391dbecdfe30baa01e50b
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In 4d5c3b9fc1c5 the arguments of the MenuEntryDialog widget were
altered, and one instantiation of this widget was not adapted, resulting
in the last parameter being undefined and causing a crash. This commit
adapts that call.
closesodoo/odoo#40187
X-original-commit: ab7f501ff401cc1a85a95dd3cc65d80ecfeec2cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Create a contact
- Create a child contact without name
Opening POS causes an error as the Name Field is not a string.
opw-2121499
closesodoo/odoo#40218
X-original-commit: 0171ed4c8ae9ed208d3896a97d1ae0bd0196c9ab
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a Sale Order with a product
- Confirm and deliver the product, create an invoice.
- Cancel that invoice, go back to the SO.
- Recreate the invoice, you have 2 of them (one cancelled).
- Post the second, and try 'Send and print' and 'Preview'.
A traceback is raised.
The traceback arises because we sort on the `invoice_date`, which is
`False` for a canceled invoice.
Actually, we should not take into account canceled invoices.
opw-2119870
closesodoo/odoo#40215
X-original-commit: 6f304973785669f1c3b297c96eb8be7de7242ebe
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fields `Nome` and `Cognome` cannot be identical. However, Odoo has only
a single field for name. Therefore, we split the name based on the
assumption that the name is written as 'Name Surname'.
opw-2093035
closesodoo/odoo#40209
X-original-commit: 9e8b33d61430bd834ac2970919c3df2a0bb76fa4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Planning the workorders depends on the quantity to produce of those workorder
This will create as much as production batch needed regarding the workcenter
capacity.
This method is good except in case of product tracked by serial number. In that
case the quantity to produce on the workorders is force to 1 regardless of
the quantity to produce on the production
closesodoo/odoo#40226
X-original-commit: 3c4133ddac256c63802a99461db49cc9bd9fa1d6
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Make sure to update the standard price with the computed unit cost of
the candidate and not its `unit_cost` field, as the computed could
contain an extra value from a landed cost.
closesodoo/odoo#40208
X-original-commit: 9234ea1e32609ee7b5c22b836c33eefa20220d37
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Without this commit, if you have the hr_timesheet installed, the one2many analytic lines view (in the Journal Items form) shows the hr_timesheet_line_tree view instead, which is not desired.
closesodoo/odoo#40196
X-original-commit: 0b92bde84afac4a78512c475de3c8c822a1fa4b2
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Victor Feyens