FP request: hide the field from the view as too technical
MAT analysis: it should be true by default as most expected behaviour
(it was the reason why it was displayed in the first place)
closesodoo/odoo#35679
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Improve the usability of the employees profile / "My Profile"
TaskID: 2048672
closesodoo/odoo#35587
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
Next to 883c96b781 and recent ribbon widget update some form views
have to be updated. It is best displayed following those rules
* after oe_button_box in order to fix overlapping;
* before image to overlap it cleanly;
LINKS
Task ID : 2032621
PR : #34662
Task
Since ed18095127, some google fonts are included. The "Open Sans" fonts
prevents RPM packaging to work because of white spaces in file names. This
is a Python setuptools bug (https://bugs.python.org/issue809163) which is
not yet fixed.
With this commit, the "Open Sans" directory and ttf files are renamed
into "Open_Sans", solving the packaging problem.
closesodoo/odoo#35661
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
All views defined in the 'enterprise' addons have their validation done
manually in their respective addons. Each one ? No, one rebel still
resists to the standart way to work.
This commit moves the gantt validation to put it in its module. The idea
is (for developper) to have only one module to change when adding feature
in gantt view.
Task-2050019
- Clean form view
- Add a new widget to check if IBAN account number is correct
- On the res.partner model, default value for "is a company" is True.
TaskID: 2025362
closesodoo/odoo#34691
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If we use a kanban view to select a record we want to hide those elements:
dropdown boxes, buttons, anchors, some widgets, kanban color.
When it was too much change and used the new attribute
"kanban_view_ref" to explicitly define which view to open in selection_mode.
When also had to create previously unexisting kanban for
fleet.vehicle.model to show name and brand.
Task ID : 1924779
- many2one widget in mobile will open kanban view instead of listview when
records needs to be selected
- Add support of "kanban_view_ref" on many2x fields:
For many2one fields, this specific kanban view will be opened when you click
on this field. Note that in desktop, the behavior stay unchanged:
'Search More' will open the tree view.
For many2many fields, this specific kanban view will be opened when you add
a record in mobile.
- Add support "selection_mode" in kanban views.
This boolean is set to true when you want to use a kaban view to
select a record instead of open a record.
"selection_mode" is now passed in qweb_context to allow developers
to use t-if='selection_mode' in kanban views to show or hide elements;
buttons, dropdowns, anchor tags are not necessary when selection_mode
is enabled. So those elements can be hidden based on this condition.
Useful when kanban view is opened from m2o in mobile environment.
Task ID : 1924779
* set country VAT Label "CUIT" which is the country TAX id name in
Argentina in order to used in reports and other places in Odoo. CUIT
mean "Código Único de Identificación Tributaria",
* update address format of the country.
* Use the state name instead of the state code: The address for the
company and partner was showing the state code (defined by ISO) but
this one are not the ones know for the common use. In order to avoid
errors we use the state name instead of the state code.
* Also change the order of the city state and zip are shown in address
in order to match the address in Argentinain "way".
closesodoo/odoo#34961
Signed-off-by: Josse Colpaert <jco@openerp.com>
Improve design and introducing several usability improvements:
- Removed customization of an event card, just display event title.
- Added popover, popover consist of two sections:
1) Show the title, date and time of an event. Date and time are
automatically computed according to the user timing preferences,
language and event duration. Can be hidden with hide_date/hide_time
attribute respectively.
2) Display all the fields specified inside the <calendar/> element.
fields can be specified with a widget and its options.
e.g. <field name="name" string="Custom Name" widget="char" options="{}"/>
- Show avatar in popover for filters.
- Removed hide sidebar feature.
- Increase readability using a better color selection.
- Better UI in mobile.
And, Adapted test cases
Task 1919926
Co-authored-by: jat-odoo <jat@openerp.com>
Sending a quotation by mail is really rare and the option is still
available in dropdown menu. It is also confusing to see the document status
changed while you just want to print as a draft sometimes. So the PRINT button
is removed here.
Only displayed UNLOCK/LOCK for 'sales managers' if the
option “Lock confirmed orders” is activated in the settings.
Removed the ability to open the payment terms via external button
in edit mode
Removed the left,right and top borders in the field of terms and condition.
Kept only bottom border.
Event and Event ticket will come after Product regardless of it being a
template or the product.
In the sale order's form view, made certain changes like shifting
the positions, removing the field, adding title, keeping the field
in debug mode.
task-2033229
get_installed and _lang_get_id are both ormcached and correctly check
the context
Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation
closesodoo/odoo#35504
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It was very misleading that
self.env['res.lang']._lang_get('fr_FR')
used to return any language if fr_FR was not active or did not exited
There is a very frequent need to get a language from the code
There is rarely a need to get any language
While licence is technically correct, it is not used in America
Change only the label as the key is used at other places (e.g. app store)
closesodoo/odoo#35350
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Remove states according to new address format
No need to keep states that's why they have been remove.
From Module:
Belgium(l10n_be)
Germany(l10n_de)
Poland(l10n_pl)
Purpose :
========
Uniformity for define all state in base.
Specification :
===========
Move states from localization to base module
Localization modules:
China(l10n_cn)
Costa Rica(l10n_cr)
Dominican Republic(l10n_do)
Ethiopia(l10n_et)
Ireland(l10n_ie)
Netherlands(l10n_nl)
Turky(l10n_tr)
Vietnam(l10n_vn)
Romania(l10n_ro)
United Kingdom(l10n_uk)
that it is not a problem to put all these states in base, because the current csv only takes 0.34 s to be loaded
Related to task #1967713Closes#32767
Signed-off-by: Josse Colpaert <jco@openerp.com>
Currently, only 6 digits after decimal point is stored in database and for some currencies
it may require to have more digits after decimal precision to correctly convert rates,
like MXN -> USD currency. So, we allow maximum digits to be stored in database.
On the view side, wherever rate is editable(form or tree view), we show 12 digits
after decimal point and on list view, we truncate limit it to 6 digits.
Also, a bug is fixed for web where 'digits' attribute for float field on list view isn't considered.
Also, we have to remove a test case statement which only checks for 6 digits for a float number.
task: 2024668
closes: #34279
Signed-off-by: Josse Colpaert <jco@openerp.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Use pkg_resources.get_distribution() to check if python external
dependencies are installed, instead of trying an import.
The import test is preserved as a backwards compatibility measure.
This better expresses which python distribution needs to be installed
from PyPI and allows declaring a minimum supported version using PEP 440
version specifiers.
Closes#25541closesodoo/odoo#25549
Signed-off-by: Christophe Simonis <chs@odoo.com>
This commit removes the store property of `res_name` from `ir.attachment`
as it doesn't need to be stored and could contain outdated information
if the record name was changed after the computation.
Task: #1943295closesodoo/odoo#34930
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The following models are already using big images, or they might need big images
in the future:
- partner
- hr employee
- shop category
- lunch product
- gamification badge and karma rank
PR: #34925
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
The view name is often not very informative, add the external id for a better
error
closesodoo/odoo#29473
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If the connection test to mail server succeeds, we shouldn't see
"Oops something went wrong" and "User Error" either
Replace error generation to display success message by bus notify.
closesodoo/odoo#35292
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* account, crm, hr, im_livechat, l10n_ch, l10n_it_edi, mail,
mass_mailing, project, stock, base
- `String` -> `string`;
- `defaut` -> `default`;
- `defaults` -> `default`;
- `reandonly` -> `readonly`;
- removed redundant `placeholder` attribute for `Char` field;
- removed redundant `size` attribute for `Float` and `Integer` fields;
- changed to use `Selection` instead of `Char` for a field having a
defined `selection`.
closesodoo/odoo#35356
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
No need for selection fields
If in global variable, the _lt should be used instead
closesodoo/odoo#31211
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Introduces the method _lt
The translation method is now evaluated lazily.
It allows to declare global variables with translatable content
e.g. this code will now work:
LABEL = _lt("User")
def _compute_label(self):
context = {'lang': self.partner_id.lang}
self.user_label = LABEL
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
This commit allows to call `name_search` with context key
`res_partner_search_mode` that can take currently two values: "customer" or
"supplier".
When ordering search results, order partners by the number of SO they have when
the value is "customer" and by the number of PO if the value is "supplier".
Top suppliers/customers are displayed above in a PO/SO partner dropdown.
We have thought about different implementations before selecting this one:
- Keep the 2 boolean flags and automatically set them if a SO or PO is created
for a customer/supplier (helps a bit but doesn't work well for the first
SO/PO). As the onboarding is also a priority, we didn't implement it.
- Instead of filtering on the bool flags, sort the name_search() result according
to the number of orders they already have (e.g. if you search for "Foo" on a
PO, a supplier "SuperFoo" with 32 purchase orders will appear before supplier
"HorribleFoo" that has no PO). Problem is to do this in an efficient manner for
large databases - possibly we could store a "relevance index" based on the
number
of recent orders. Storing those values is an issue too, as it doesn't work well
for multi company database. Indeed, storing values that depend on the context
is certainly not a good idea.
- Same as previous alternative but with no stored columns, rather a JOIN in
name_search. This is the solution that have been kept. The only concern was
about the perfomances. We tested it on our production base, on a sales order,
as we have way much more customers than suppliers. After a deep analysis on
the querry and the bitmap generated by PostgreSQL, we can conclude that the
count(*) works rather efficiently and that the request is not significantly
heavier than without the context key.
Performance Analysis
====================
The following results have been obtained on our production database.
Before this commit
------------------
The original query is the following one:
```
EXPLAIN ANALYSE
SELECT res_partner.id
FROM "res_partner"
WHERE ("res_partner"."customer" = True) AND ("res_partner"."active" = True) AND ((("res_partner"."type" != 'private') OR "res_partner"."type" IS NULL) OR "res_partner"."type" IS NULL ) AND (res_partner.email ilike '%eezee-i%'
OR res_partner.display_name ilike '%eezee-i%'
OR res_partner.ref ilike '%eezee-i%'
OR res_partner.vat ilike '%eezeei%')
-- don't panic, trust postgres bitmap
ORDER BY res_partner.display_name ilike '%eezee-i%' desc,
res_partner.display_name
limit 8;
```
Here is the EXPLAIN ANALYSE returned by PostgreSQL:
```
Limit (cost=1625.50..1625.52 rows=8 width=21) (actual time=13.397..13.404 rows=8 loops=1)
-> Sort (cost=1625.50..1626.32 rows=326 width=21) (actual time=13.395..13.396 rows=8 loops=1)
Sort Key: (((display_name)::text ~~* '%eezee-i%'::text)) DESC, display_name
Sort Method: top-N heapsort Memory: 26kB
-> Bitmap Heap Scan on res_partner (cost=1282.79..1618.98 rows=326 width=21) (actual time=13.025..13.350 rows=56 loops=1)
Recheck Cond: (((email)::text ~~* '%eezee-i%'::text) OR ((display_name)::text ~~* '%eezee-i%'::text) OR ((ref)::text ~~* '%eezee-i%'::text) OR ((vat)::text ~~* '%eezeei%'::text))
Rows Removed by Index Recheck: 1
Filter: (customer AND active AND (((type)::text <> 'private'::text) OR (type IS NULL) OR (type IS NULL)))
Rows Removed by Filter: 1
Heap Blocks: exact=58
-> BitmapOr (cost=1282.79..1282.79 rows=328 width=0) (actual time=12.983..12.983 rows=0 loops=1)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=5.022..5.022 rows=54 loops=1)
Index Cond: ((email)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=4.128..4.128 rows=56 loops=1)
Index Cond: ((display_name)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..321.00 rows=1 width=0) (actual time=2.240..2.240 rows=0 loops=1)
Index Cond: ((ref)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..317.03 rows=4 width=0) (actual time=1.585..1.585 rows=0 loops=1)
Index Cond: ((vat)::text ~~* '%eezeei%'::text)
Planning time: 0.766 ms
Execution time: 13.489 ms
```
After this commit
-----------------
Without the context key, the query looks like this:
```
SELECT res_partner.id
FROM "res_partner"
WHERE ("res_partner"."active" = True) AND ((("res_partner"."type" != 'private') OR "res_partner"."type" IS NULL) OR "res_partner"."type" IS NULL ) AND (res_partner.email ilike '%eezee-i%'
OR res_partner.display_name ilike '%eezee-i%'
OR res_partner.ref ilike '%eezee-i%'
OR res_partner.vat ilike '%eezeei%')
-- don't panic, trust postgres bitmap
GROUP BY res_partner.id
ORDER BY COUNT(*) DESC, res_partner.display_name ilike '%eezee-i%' desc,
res_partner.display_name
limit 8;
And it quite clear when looking at the EXPLAIN ANALYSE that the request
is quite the same, except the aggregation that is made with a quicksort method.
Limit (cost=1645.00..1645.02 rows=8 width=29) (actual time=13.200..13.206 rows=8 loops=1)
-> Sort (cost=1645.00..1645.82 rows=328 width=29) (actual time=13.197..13.198 rows=8 loops=1)
Sort Key: (count(*)) DESC, (((display_name)::text ~~* '%eezee-i%'::text)) DESC, display_name
Sort Method: top-N heapsort Memory: 26kB
-> GroupAggregate (cost=1631.88..1638.44 rows=328 width=29) (actual time=13.090..13.160 rows=56 loops=1)
Group Key: id
-> Sort (cost=1631.88..1632.70 rows=328 width=20) (actual time=13.080..13.084 rows=56 loops=1)
Sort Key: id
Sort Method: quicksort Memory: 29kB
-> Bitmap Heap Scan on res_partner (cost=1282.79..1618.17 rows=328 width=20) (actual time=12.793..13.055 rows=56 loops=1)
Recheck Cond: (((email)::text ~~* '%eezee-i%'::text) OR ((display_name)::text ~~* '%eezee-i%'::text) OR ((ref)::text ~~* '%eezee-i%'::text) OR ((vat)::text ~~* '%eezeei%'::text))
Rows Removed by Index Recheck: 1
Filter: (active AND (((type)::text <> 'private'::text) OR (type IS NULL) OR (type IS NULL)))
Rows Removed by Filter: 1
Heap Blocks: exact=58
-> BitmapOr (cost=1282.79..1282.79 rows=328 width=0) (actual time=12.755..12.755 rows=0 loops=1)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=4.823..4.823 rows=54 loops=1)
Index Cond: ((email)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=3.941..3.941 rows=56 loops=1)
Index Cond: ((display_name)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..321.00 rows=1 width=0) (actual time=2.186..2.186 rows=0 loops=1)
Index Cond: ((ref)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..317.03 rows=4 width=0) (actual time=1.798..1.798 rows=0 loops=1)
Index Cond: ((vat)::text ~~* '%eezeei%'::text)
Planning time: 0.761 ms
Execution time: 13.317 ms
```
With the context key, the query looks like this:
```
EXPLAIN ANALYSE
SELECT res_partner.id
FROM "res_partner"
LEFT JOIN sale_order ON res_partner.id = sale_order.partner_id
WHERE ("res_partner"."active" = True) AND ((("res_partner"."type" != 'private') OR "res_partner"."type" IS NULL) OR "res_partner"."type" IS NULL ) AND (res_partner.email ilike '%eezee-i%'
OR res_partner.display_name ilike '%eezee-i%'
OR res_partner.ref ilike '%eezee-i%'
OR res_partner.vat ilike '%eezeei%')
-- don't panic, trust postgres bitmap
GROUP BY res_partner.id
ORDER BY COUNT(*) DESC, res_partner.display_name ilike '%eezee-i%' desc,
res_partner.display_name
limit 8;
```
The only difference is that a nested loop is made for the left join, as postgreSQL has
correctly identified the dicriminating table. The correct result is obtained within
a similar duration.
```
Limit (cost=2700.68..2700.70 rows=8 width=29) (actual time=12.561..12.568 rows=8 loops=1)
-> Sort (cost=2700.68..2701.50 rows=328 width=29) (actual time=12.559..12.560 rows=8 loops=1)
Sort Key: (count(*)) DESC, (((res_partner.display_name)::text ~~* '%eezee-i%'::text)) DESC, res_partner.display_name
Sort Method: top-N heapsort Memory: 26kB
-> GroupAggregate (cost=2687.56..2694.12 rows=328 width=29) (actual time=12.449..12.527 rows=56 loops=1)
Group Key: res_partner.id
-> Sort (cost=2687.56..2688.38 rows=328 width=20) (actual time=12.408..12.425 rows=305 loops=1)
Sort Key: res_partner.id
Sort Method: quicksort Memory: 42kB
-> Nested Loop Left Join (cost=1283.21..2673.86 rows=328 width=20) (actual time=11.629..12.340 rows=305 loops=1)
-> Bitmap Heap Scan on res_partner (cost=1282.79..1618.17 rows=328 width=20) (actual time=11.596..11.862 rows=56 loops=1)
Recheck Cond: (((email)::text ~~* '%eezee-i%'::text) OR ((display_name)::text ~~* '%eezee-i%'::text) OR ((ref)::text ~~* '%eezee-i%'::text) OR ((vat)::text ~~* '%eezeei%'::text))
Rows Removed by Index Recheck: 1
Filter: (active AND (((type)::text <> 'private'::text) OR (type IS NULL) OR (type IS NULL)))
Rows Removed by Filter: 1
Heap Blocks: exact=58
-> BitmapOr (cost=1282.79..1282.79 rows=328 width=0) (actual time=11.560..11.560 rows=0 loops=1)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=4.724..4.724 rows=54 loops=1)
Index Cond: ((email)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=3.825..3.825 rows=56 loops=1)
Index Cond: ((display_name)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..321.00 rows=1 width=0) (actual time=1.752..1.752 rows=0 loops=1)
Index Cond: ((ref)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..317.03 rows=4 width=0) (actual time=1.254..1.254 rows=0 loops=1)
Index Cond: ((vat)::text ~~* '%eezeei%'::text)
-> Index Only Scan using sale_order_partner_id_index on sale_order (cost=0.42..2.74 rows=48 width=4) (actual time=0.006..0.007 rows=5 loops=56)
Index Cond: (partner_id = res_partner.id)
Heap Fetches: 12
Planning time: 1.056 ms
Execution time: 13.791 ms
```
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
If a db is in single lang (en_US or not) but still has translations, the
translation should be updated in addition to updating the referenced record
Add tests to formalise the expected behaviour:
If one language only (en_US or not), when writing on a translatable field:
- record field should updated
- value of potential existing en_US translation should be updated
- src of potential existing translations should be updated
- no new translation should be created
If en_US and fr_FR, when writing on a translatable field in en_US:
- record field should updated
- value of potential existing en_US translation should be updated
- src of potential existing translations should be updated
- new en_US translation should be created if was not present
If en_US and fr_FR, when writing on a translatable field in fr_FR:
- record field should not be updated
- value of potential existing fr_FR translation should be updated
- src of potential existing translations should not be updated
- new fr_FR translation should be created if was not present
Adapt test_new_api test
get_installed is ormcached, just putting active = True is not enough
Instead, make sure the field src is always up to date
Add tests
Changes in _write:
- Replace _set_ids (to be deprecated) call by _upsert_translations as it works
in batch
- Call _upsert_translations for any language, including en_US
In case an English translation already existed for a record, only the master
value (on the reference record) was updated but the user kept seeing the
translation value (was revealed 73a7534bfc).
- Read src_trans without language
Similar as above, if an English translation already existed, the translation
was used for the result of the read and not the new value that has just been
inserted into the database
- Add _set_source method
When updating a master record of a translated field, the src field must be
updated, including in different languages.
Before it was ok that the src field was out of date as the source was computed
Changes in copy_translation:
- set src as the new value without lang
update the comment to reflect reality since 489494e733
src will contain the English version if no changes were made and it will
contain the modified value if copy was overriden
Changes in upsert_translations:
- Do not force a module, comment, state
Only src, res_id, name, value and lang must be given. Optional values will no
longer be set to null if not given
Fix for: https://github.com/odoo/odoo/pull/32132
We had changed the display of the warnings in the back-end to be like the
front-end (notification toast). This change needs to be reverted. Now
the warnings in the front-end are toast notifications and in the
back-end they are Warning modals.
Part of: https://github.com/odoo/odoo/pull/35209
The purpose of quiet parameter is to return a barcode image
without left and right margins.
It could be usefull on report where the barcode size should be
minize or align to another element.
closesodoo/odoo#29209
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of the commit is to set the new attribute OPTIONAL = SHOW/Hide on tree
view so the user can easily hide/show the optional fields on the tree view.
task-1997453
Closes: #33888
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closesodoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
This commit moves some ir_ui_view specific functions into ir_ui_view.py
and removes some old-api <-> new-api compatibility shims as well as
removes orm.py since it has 0 to do with the Odoo ORM.
closesodoo/odoo#34826
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
Currently, when we click on “Settings” on the Home Dashboard, we arrive
on a new Dashboard with several pieces of information like Installed Apps,
invite new users, or translations. Some informations are reachable in
several ways, which is not necessary.
We would like to remove this page and replace it with the General Settings
page directly. That makes more sense to the user who click on “Settings”. The
present informations will be dispatched in the menu or in the general settings
for a better usability.
Specification
=============
This commit move code from web_settings_dashboard in order to put the features
in settings directly. To do so, we choose to move code to base_setup, and create
widget on the settings form view to keep features. Concerned features are: invite
users, dev tools, odoo edition number and IAP account link.
TaskID: 2006910
closesodoo/odoo#34290
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Martin Trigaux