* web_editor
Previously, the user could choose their anchor names using a modal
window, anchor names also have weird rules, this was not a great user
experience.
This commit makes the anchor button generate anchors automatically based
on the first title in a section, or the snippet name if there are none.
If the anchor name is already taken, it is suffixed by a number. After
it has been generated, it is also copied to the clipboard and the user
is shown a toast to tell them the anchor has been generated and copied.
The anchor is displayed in the toast along with an edit button that will
open the same edition modal as previously, but it is now less
restrictive.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088270
This commit adds buttons to move sections up or down and to move columns
left or right, which is more user-friendly than drag-and-drop in some
cases.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088265
* website
Now snippet options can be defined as a button which can be placed next
to the clone and delete buttons, through a new "isTopOption" method.
This commit also review the buttons and title design and take advantage
of the feature to review the way snippets options are added in their
container (that code indeed contained useless part since 13.0).
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
* web_editor, website_blog, mass_mailing
In preparation of the new left panel UI, remove all snippet options UI
icons as we do not want them anymore to simplify the UI.
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
Before this change the manual taxes widget in the invoice form view was
broken for Argentinian invoices, with this change now the widget is
working.
It was broke because this method is used for the report/portal and
manual taxes in widget in the form view, and for Argentinian case
report/portal invoice should not discriminate some of the taxes depending og
the responsibility of the customer/issuer and the type of document
(example: Factura A, Factura B).
Also update the method in order to match the original one in odoo
account module and add missing group_id
closesodoo/odoo#40400
X-original-commit: 6260da7604b2a831668be42bf8745c53a09e8d16
Signed-off-by: Josse Colpaert <jco@openerp.com>
Install accounting and activate a new language. Under
Accounting>Settings>Terms and Conditions input something, save and then
click on the near lanuage button.
A popup will appear with only the possibility to close and save but with
no text.
This is because no row is fetched from the ir.translation table, because
the domain for the search is
```
['&',
['res_id', '=', None],
['name', '=like', 'res.config.settings,%'],
['name', '=', 'undefined']
]
```
* wrong res.id "None" instead of the correct one (1)
* wrong name pointing to somewhat related to 'res.config.settings'
(the field name is "res.company,invoice_terms")
* another wrong condition on name equal "undefined"
The domain is malformed because in
addons/web/static/src/js/views/basic/basic_controller.js
record.res_id is unset while record.res_ids is it. Rewriting res_id to
make sure the id is there fix the issue
Thanks to mart-e
opw-2091779
closesodoo/odoo#40394
X-original-commit: 20e84558de476c17fed73f7ea5a11989401bffaf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since stdnum.ar.cbu is not available in odoo saas enviroment because is
using an old version of stdnum package, we add a try exept in order to
catch this and manage the error properly which is raise an exception and
leave a message in the log telling the user that the cbu was not able to
validate.
closesodoo/odoo#40383
X-original-commit: 25d483fc3fc05fd47c72c3d96c02fed12b998b0d
Signed-off-by: Josse Colpaert <jco@openerp.com>
Create a pricelist item with a fixed price, e.g. 10.20. The amount is
displayed as 10.200....01.
To avoid this, we format the float correctly.
opw-2122622
closesodoo/odoo#40391
X-original-commit: 1edcab8c8caabeb5ebfec4bc6fcba1b5506f73ca
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The field `account_id` has been removed from the tax, it is not on the
repartition line.
opw-2121720
closesodoo/odoo#40370
X-original-commit: 537dd88aced8b181f921e0daa0bf146fee9366cb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create Product A:
Routes: MTO and Manufacture
Manufacturing Lead Time: 20 days
- Create Product B:
Routes: MTO and Buy
Add a supplier with Delivery Lead Time: 10 days
- Create a BOM: 1 unit of B to produce 1 unit of A
- Create a SO for A, validate
A MO is created with a Deadline set at SO order date - 20 days => OK
A PO is created with order date set at SO order date - 10 days => Not
OK, it should be - 30 days.
In v13, the raw materials expected date is the order date.
In v12, this date is computed as: order date minus Manufacturing Lead
Time
However, in both versions the PO order date is computed as the raw
materials expected date minus Delivery Lead Time of the supplier.
This comes from a change in the semantic of 'Planned Date' and 'Planned
End Date'. In v13, the Manufacturing Lead Time is only taken into
account in the Deadline, while in v12 it was taken into account in the
Planned Date. However, the expected date of the raw materials still
relies on the latter, not on the Deadline.
In order to solve this, we apply the 'Manufacturing Lead Time' of the
product and the company to 'Planned Date', 'Planned End Date' and
'Deadline' when the MO is created. Note that the solution is still not
ideal in case no routing is set on the BOM since 'Planned Date' and
'Planned End Date' won't be updated later in the process.
opw-2118951
closesodoo/odoo#40360
X-original-commit: b523f991572e32e69c5f8000a21553191ca54773
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before that, when trying setting to None the tag_name of a tax report line whose tags were referenced by some move lines, a exception was raised, telling that some account.move.line objects still referenced an account.tag we were trying to delete. Removing the tags from db was legit (since we're removing the tag_name, we need to remove the tags that it generated), but first needed to remove all these tags from the account move lines linked to them.
closesodoo/odoo#40375
X-original-commit: 3eb5a3e947bb371f90c9f2357ff410816419bbb0
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When a call to init_models() fails, the post-init queue still contains
callables that refer to a soon-to-be-closed cursor. If one calls
init_models() in another request, the post-init process will inevitably
fail because it refers to closed cursors.
closesodoo/odoo#40379
X-original-commit: 33f87ffebaa1cb38e3ce8ce44c8b8b538b49e5b9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Commit https://github.com/odoo/odoo/commit/f6bbc40fbe16ea5ab01ad03b8e1519c4e559bf6d
introduced a method to destroy all current editors to refresh them when
necessary... but forgot to empty the array that contains them.
In a 12.0 without custo, this is only slowing down the editor but in
master (or with custo) this makes the editor crash.
closesodoo/odoo#40372
X-original-commit: 2b5661937d9772b98c73f9f64aa419fec7676052
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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.
Samuel Degueldre