In a @odoo-module js file, importing a legacy module that did not have
a name respecting the "addon.name" format was not supported.
This commit will support all keys that do not start with a "." or "@".
This commit will also improve some regexes allowing to extract path.
Legacy module name supported:
import X from "some/path"
import X from "addon.name"
Legacy module name not supported:
(relative path and @module/path are only used to import @odoo-module js
files)
import X from "@some/path"
import X from "./some/path"
import X from "../../some/path"
closesodoo/odoo#68152
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Problem :
In the website settings, there are related fields with a default value.
The ORM will therefore only take the default value and ignore the value of "related".
Solution :
Remove default value from related fields
opw-2467959
closesodoo/odoo#68230
X-original-commit: a7110b616cb26641a546c22ff5ecf6aff073edfb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Generated PDF was shrunk down, not taking up the full width and size of the A4
format, leaving big margins on right and top. Setting `disable-smart-shrinking`
to `True` helps with this, but layout is slightly too big. Setting `dpi` to
`96` and removing the `width` and `height` on the parent element fully fixes
the issue.
This merge also adds a boolean field `disable_shrinking` in model `report.paperformat`.
If set to True it adds one argument `--disable-smart-shrinking` in commands
that prevents the pdf shrinking. See issue[1] for more information.
This options is utilized for printing survey certificaiton.
Task ID-2483393
COM PR odoo/odoo#68188
UPGPR odoo/upgrade#2293
issue[1] - wkhtmltopdf/wkhtmltopdf#3226
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a boolean field `disable_shrinking` in model
`report.paperformat`, which, if set to True, will add one
argument `--disable-smart-shrinking` in commands that prevents
the pdf shrinking. See issue[1] for more information.
This options is utilized for printing survey certificaiton.
issue[1] - https://github.com/wkhtmltopdf/wkhtmltopdf/issues/3226
taskID-2483393
Open Calendar weekly view
Scroll the weeks
The 'Responsible' filter will accumulate entries from the events and not
deleting them.
This create issue with the view in db with heavy calendar use and a lot
of responsibles
This reverts commit 64d0fe4118, coming from
task 2146842, addressing the following issue in calendar view (i.e. in planning
app) not reproducible anymore
"
In calendar view, when you unselect all filters of a category, all
events disappear (it's expected), but all filters also disappear.
So you can't selectd anything, you must reload the view to unlock
the situation.
"
opw-2479920
closesodoo/odoo#68118
X-original-commit: 0ae22aa773f9343fc79937cceb5bf60c5fb3ba3c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
This commit introduces a new wizard that allows adding existing contacts of a
specific mailing list to another mailing.list.
It's typically used on the list view of a mailing.list where you tick a bunch
of contacts and add them all at once to another mailing.list (existing OR new
one that you create on the fly).
That tool will help users manage their mailing.list a bit easier and avoid some
tedious copy/pasting if mailing.lists need to share common contacts.
Wizard has two options: either simply create a new mailing list, either create
it and use it directly in a new mailing. It allows to cover the following
user flow
* select contacts;
* add them in a new list created on-the-fly;
* jump on a new mailing targeting this mailing-list;
* fill body, launch, enjoy !
Task-2453990
closesodoo/odoo#65965
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Noureddine Bensebia <neb@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Changed the uom of product package if product_length_in_feet_param
of ir config parameter for product is not 1. Previously its value
was meter.
For following fields updated the uom -
1) packaging_length
2) width
3) height
closesodoo/odoo#64735
Taskid: 2418421
Related: odoo/upgrade#2089
Related: odoo/enterprise#15848
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
A canceled event track must be unpublished.
opw:2485928
closesodoo/odoo#68236
X-original-commit: c0aaf2412e586e038cf81646567268607e789f71
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When you want to validate a picking with a lot of products, the system notifies "You have not recorded done quantities yet, by clicking on apply Odoo will process all the quantities."
Nice and easy, except when you were not able to process all the quantities.
In that case you have to update all but the few lines manually.
Also added to batch pickings
task-2158092
closesodoo/odoo#58487
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
*: web_editor
Adding the option to show/hide on mobile at snippet level + review the
UI (now a top action button).
task-2431659
closesodoo/odoo#65013
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
TLS 1 and 1.1 are not recommended anymore
This configuration was generated with Mozilla SSL Configuration
Generator (https://ssl-config.mozilla.org) with a fairly conservative
approach:
- nginx 1.10.3, OpenSSL 1.1.0l (Debian Stretch)
- Supports Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on
Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9
Fixesodoo/odoo#68002closesodoo/odoo#68227
X-original-commit: ece5778c205765e5e5b1a3fd86e6f031bf25c12d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When a template string that contains an expression is translated, the
resulting msgid is wrong.
e.g.:
_t(`blah blah ${expression}`)
will generate a wrong msgid like this:
msgid "blah blah ${expression}"
With this commit, a new test is added to find and forbid translations of
JS template-strings.
closesodoo/odoo#68165
X-original-commit: 9184ae45e0df179fc093c1fc48a7fa56d8fe9594
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In order to integrate and use GS1 nomenclature into `stock_barcode`,
adds a new module with GS1 nomenclature and rules, and overrides parsing
methods.
task-1968113
closesodoo/odoo#65858
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: ryv-odoo<ryv@odoo.com>
Before this commit, on mobile in the Accounting app, the link in a
kanban card was not well placed.
After this commit, in mobile we consider a link as a block so he is
moved below.
Steps to reproduce:
* Open Odoo on Mobile
* Go to Accounting => Bug ("Create Manually" is in a strange position)
Task ID : 2200168 (4.a)
closesodoo/odoo#67692
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
when the partner is Tesoreria de la República, and exclude the credit note.
closesodoo/odoo#67630
X-original-commit: 8ca3ea063050f2ab2d19cce8a68116489872a734
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit, when a calendar view was resized the full view was
rendered again to recalculate the resize.
After this commit, we now set manually the new size.
This avoid to lose the current position-y in the calendar.
Steps to reproduce:
* Open a window (not maximized)
* Go to calendar (day/week view)
* Scroll to the end of the calendar
* Resize the window => the calendar returns to the begging.
Note:
By the same way it also fixes a performance issue in TimeOff's render as
it makes an RPC to calculate the popover for the year view.
Task ID: 2200168 (5.a)
closesodoo/odoo#66387
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Let's consider an included tax T (10%) and a product P (11€) with invoicing policy based on delivery
- Create a sale order SO with one line L with 2 P and T
- Confirm SO
Bug:
The untaxed_amount_to_invoice was 20€ on L instead 0€
The untaxed_amount_to_invoice must be 20€ when the delivery is processed
opw:2457660
opw:2457660
closesodoo/odoo#67682
X-original-commit: d6ed6b9fa204fcfcabf1c1c330b5ae8ada34744c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Those are not launched anymore by default. Indeed framework and code followup
is not ready for that level of details.
Task ID-2480727
closesodoo/odoo#67678
X-original-commit: f950399e6e4aaaf88b743abfeb37a2de4c99fa5c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
According to last runbot state. Should probably be removed someday as actually
there is not much gain with those tests.
X-original-commit: dc05f873571ca60b7fbbb701a86760f13a6d3172
Identification type was always been overwrite by the _onchange_country even when just opening the contact form, this was always setting the is_vat identification type as default without taking into account if the user has defined their own default.:
* If Identification type is set and it is compatible with the country then we leave it as it is (this is the case the identification type has been set by a default).
* If Identification type is set but is not compatible with the country then compute and set the Identification type that is is_vat True for the country
Where country is the one set in the partner record, if not set will use the country of the move's company, if not defined then will use the country of the environment company
closesodoo/odoo#67628
X-original-commit: 8e9b1c404a71c0a7dce37c7f5f6ecef1396e0a1a
Signed-off-by: Josse Colpaert <jco@openerp.com>
Steps to reproduce the bug:
- Create an Expense E
- Create a report R from E in the journal J (type=purchase)
- Generate the journal entry JE from R
- Go to Accounting Dashboard and click on J in the kanban view
Bug:
JE was not displayed in the entries filtered for J
PS: When creating a journal entry from an expense sheet, the move_type of the entry
is 'entry'.
opw:2474729
closesodoo/odoo#67674
X-original-commit: 31ca461ee3a6b9560fe6d78642e8fe5017b1085e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, the first step of the tour pos_basic_order
waited for something not precise enough, and that was true
before anything was loaded
After this commit, we wait both the the webClient and the Chrome to be loaded
with a more specific selector
Runbot issue fingerprint: bd10372b7db10c743f38312470ff528a74bfe9dcc0348a3e1f0bd47f55764378
Runbot issue id: 1357
closesodoo/odoo#67904
X-original-commit: 166e30b132fb659aa5a35a03cc73e5225575af2b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Translation overwriting was not working when forced by command line
arg --i18n-overwrite
This is due to the change of signature of the method, no longer
relying on the context
Fixesodoo/odoo#67419closesodoo/odoo#67873
X-original-commit: 44624f5d51a266c4fc37644d3fc36b810e722ee4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The crash manager doesn't recognize ImbalanceJournalEntryError as
a user error and when creating a journal entry that is not balanced,
a traceback is shown instead of the normal UserError dialog.
In this commit, we fix this issue by getting rid of the new error
and put back the use of UserError when checking the balance of an
account move. We also make sure that the feature in pos where we
show a wizard to unblock the user from closing session with
imbalance amount is intact.
closesodoo/odoo#67743
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The popup to apply the discount of the first SO line to the other lines didn't appear
when the first line was a section or a note.
closesodoo/odoo#67907
X-original-commit: 995ba0c2033455a2092439e9728b3f731381c742
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The 'addMockEnvironment' test utils allows to patch a lot of stuff,
including the session, for the sake of a test. However, it assumes
that it is only called once inside a test (or at least, that its
cleanUp function is always called before it is called again).
In this hr_attendance test, it isn't the case. 2 client actions are
instantiated, and addMockEnvironment is called for each of them,
in particular to patch the session.
The first call stores the current session (the real one), to restore
it in its cleanup (1). The second call stores the current session
(the mocked one, produced by the first call), to restore it in its
cleanup (2). The cleanup functions are called in order, so (1)
before (2), meaning that at the end, we end up with the session
being the mocked one of the first call to addMockEnvironment.
The very short term solution is to ensure, in this test, that the
cleanup functions are called in the correct order. For the long
term, we are working on a robust mechanism to correctly clean up
everything after a test.
Issue spotted in the assets revamp task, which mixed a bit the
order of the tests.
closesodoo/odoo#67891
X-original-commit: bb43c74dd10c76b8a80d5749106b86432b13909e
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Without this commit, all tests executed after that one would use
the patched version of the FormViewDialog.
Issue spotted in the assets revamp branch, by moving form_tests.js
after calendar_tests.js
closesodoo/odoo#67887
X-original-commit: ff19ee8d8b39a719a09dd9f6060faa3afa474da3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The tour system is based on many assumptions, some of those not being
true all the time. In practice, it works most of the time, but when
some slight changes occurs, we may observe undeterministic behavior.
This was actually the case in a dev branch working on assets: the order
of some files was changed, and it caused crashes in various tours.
This helped us identify two issues in the Tip class:
- the Tip class may be destroyed before it is completely started (so,
the destroy method should not assume that the code in start was called
- the attach_to method should not resolve if the tip was destroyed
meanwhile. This is critical, because some code uses that promise to act
on the widget.
This commit fixes both of these issues.
closesodoo/odoo#67896
X-original-commit: b88b634a0363a55411290e54e37806cfec1b2de5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The code added in [1] to update style for multi image selection
is not compatible with .fa icons and causes a strange behaviour when
trying to select one.
The goal of this commit is to fix style for selected icons on media
dialog.
Also fixes the fact the icons were not centered before.
[1]: https://github.com/odoo/odoo/commit/bb65b742e7eec000248b7df0f048dda61ac3ff5aclosesodoo/odoo#67846
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Currently, In channels listing, the order of the channels is case sensitive.
The Uppercase names are listing first and then all the Lowercase ones.
but it should be displayed in the alphabetical case insensitive order.
With this commit, we have resolved this issue and now channels are listing
in case insensitive alphabetical manner.
Task : 2453592
closesodoo/odoo#67889
X-original-commit: 4445207161c84d2854055df63013c1361e5d4697
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
When deleting/archiving any user, the user’s related chat changed name due to
losing one of its members.
After this commit:
Chat name should remain the same after archiving/deleting the user.
Reasoning:
The unsubscribe was meant to target channels of type channel specifically.
`test_channel_auto_unsubscribe_archived_or_deleted_users` has been reintroduced
after having been removed by mistake in eda542c82f84d7b5589846691b9cb6b7f1021947
task-2442235
closesodoo/odoo#67884
X-original-commit: cb4bd4cbc4a36276cc6c9cb68e51c260e7c0d761
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since e86f892a7b
We have the possibility to display a "lost" and a "won" ribbon on the crm.lead
kanban view.
In this commit, we change things around a bit:
- The "WON" ribbon was removed.
Since it was redundant with the stage anyway and not very useful.
- The "LOST" ribbon is now always displayed in the kanban view.
And not only when coming from "duplicate leads".
In addition, leads displayed when coming from the stat button on the
res.partner form view now also shows lost leads (active_test=False).
This can be helpful for the end user because he wants to know "all the deals
that are in progress/lost/won with this specific contact".
Task-2349526
closesodoo/odoo#67693
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Until now, if you have 2 tags (t1, t2) on blog post (P) of blog (B),
we ask to index:
/blog/B/post/P
/blog/B/post/P/t1
/blog/B/post/P/t2
Now, we only ask to index:
/blog/B/post/P
opw-2413811
closesodoo/odoo#67845
X-original-commit: bd8268a36cbe098935555edee8c16b7667c912fc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Issue:
If we get a 'false' for the real_owner_id from the extendedProperties, we will get an error
ValueError: invalid literal for int() with base 10: 'false'
Fix:
We make sure to set a user for the real_owner_id var if it return a 'false' before
closesodoo/odoo#67840
X-original-commit: 735614a127499843bc7bd701794870234e743a88
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, when the user creates a SO with a service product
which does not generate a task or a project, the analytic account is not
set on the new SO. Then even if the user creates a task and add timesheets
for this product in this SO, the compute_timesheet_ids gives 0
timesheets in the sale.order model because the SO is not linked to an
analytic account.
This commit removes this condition and directly searches the timesheets
linked to the SO and thus provides the correct number of timesheets for it.
This bug is appeared from this commit: dc9ef81ab2
Steps to reproduce:
1. Create a SO and add a SOL with 'Service on Timesheet'
2. Confirm the SO
3. Create a task in project for the same customer than the SO or a
project with no customer set.
4. Add the customer of the SO in the task if it is not already the case.
5. Add the SOL in the task and add a timesheet.
6. Go to /my/orders
7. Select the SO that you have created and in this view, normally, you
should have the View Timesheets buttons on the left side.
Current behaviour:
The 'View Timesheets' button does not appear in the view because the
compute_timesheet_ids from the SO return no timesheets for it.
Expected behaviour:
The button should be visible in the view because we have a timesheet for
this SO.
closesodoo/odoo#67770
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit removes 2 css rules that were applied on ALL odoo reports by
mistake.
Indeed, adding rules on "*" and "body" will most likely break other reporting
layouts and is very dangerous / unintended.
If these rules are needed for the survey reports, then it should be fixed to
make them only applied to those reports instead.
We also took this opportunity to get rid of some scss variables.
These variables names were too "global" and could also conflict with other
reporting css rulesets.
If we want to use variables for that report, they should be correctly pre-fixed
to avoid collisions.
Source: 212b107fa1
A proper fix will follow to make the survey reports work properly
(see task-2483393).
Task-2341847
closesodoo/odoo#67836
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee introduced a change that
allowed field_triggers to be computed lazily per registry, this change
introduced a behavioral change that is not easy to notice, in order to
explain the behavioral change I will use the following example which was
the original bug reported:
- Install studio
- Create an app (create a new custom model M)
- Uninstall studio
-> Uninstall fails because field display_name of the custom model M
depends on field M.x_name which has been removed due to the
uninstall process.
To understand why it didn't happen before the aforementioned commit, we
must first understand what happens with said commit applied:
- We trigger the uninstall of studio, this triggers the uninstall of
any modules that depend on it, namely studio_customizations which is
the module in which all customizations done with studio live in.
- We gather all data belonging to the studio_customization and we
start deleting in the following order: ...,
ir.model.fields.selection, ir.model.fields, ..., ir.model
- During the unlink process, we first remove the actual fields from
the model instances before deleting their database reflections, this
is done in the ir.model.fields._drop_column() method, it is this
method that will delete the x_name field but **not** the
display_name field, since it is a base field and not a custom one.
- After the deletion of the fields in memory, we call modified() to
mark fields that might've depended on the fields we just modified so
that they can be recomputed later.
- The call to modified will in turn access field_triggers, but since
we're in a new registry and field_triggers is a lazy property, it
will be computed right at this moment, this means that it will call
resolve_depends on the display_name field which still exists, and
this field has a dependency on the x_name field that we just
deleted! This is what will trigger the crash.
With that context, we can now understand how it didn't crash before
commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee:
- Before the aforementioned commit, the field_triggers attribute was
computed during the registry's setup_models(), in the case of an
uninstall this call to setup_models was done way before the
uninstall step of the registry (Step 3 is the last to call
setup_models before Step 5).
- This means that the old behavior was technically a bug, because
right after removing x_name from the model, the field_triggers still
contained a dependency from display_name to x_name, the former being
no-longer present in memory.
With this commit, we simply reset the _rec_name and the dependencies of
the display_name if the x_name field is being removed, this ensures that
the computation of field_triggers won't crash and burn.
opw-2452498
opw-2478589
closesodoo/odoo#67823
X-original-commit: e6d22a43ff9f40e5fc7b8c84cd4dfe43f926d872
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Oversight of 20b34ae867
This commit fixes the display condition of the small alert block on top of the
mass.mailing form view.
The condition was not working because it would hide the alert if:
('failed', '=', 0)
OR
('state', '!=', 'in_queue')
AND
('sent', '=', 0)
AND
('scheduled', '=', 0)
Instead, we want to hide it if:
('failed', '=', 0)
AND
('state', '!=', 'in_queue')
AND
('sent', '=', 0)
AND
('scheduled', '=', 0)
This would for example prevent showing that the mailing is "scheduled" or that
it has successfully been sent with various mailing statistics.
Task-2457227
closesodoo/odoo#67752
X-original-commit: 98786b70d92d8a3bdfb961945f475b64899cc2e0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before it was only done on MyCompany, but interferes easily
with other demo data. Better for the Italian localization
to try the demo immediately in IT Company.
We also added an Italian demo partner, so it is clear
which one can work immediately.
closesodoo/odoo#67615
X-original-commit: 91ff96a79121c1b7018f8a1f7fa9850170852c41
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Francois (fge)