- Sep 02, 2016
-
-
Denis Vermylen (dve) authored
-
Denis Vermylen (dve) authored
rename options, add radio widget
-
Denis Vermylen (dve) authored
-
Denis Vermylen (dve) authored
installing a theme redirects to the website instead of the backend menu.
-
Thibault Delavallée authored
-
Thibault Delavallée authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Martin Trigaux authored
Several modules defines records with the external ID `base.foo_bar` while it is created inside this module (typically menus and groups). While there is no technical reasons to do so but this may introduce issues: - these records will not be deleted during uninstall - if a language is loaded before the installation of the module, it won't be translated The uninstallation will only remove the records with an external id linked to this module (these would only be removed when removing base). Installing a language before the module will drop the translations not linked to an existing external id (as it can not be resolved). This commit correct all the external ids tagged as from base or other incorrect modules.
-
Martin Trigaux authored
hr_gamification should be adding hr groups to the security of gamification. Creating the group base.group_hr_manager in gamification in case hr is not installed is confusing and redundant with existing manager groups.
-
Martin Trigaux authored
Creating a external id in a different module than the one where the record is declared is a bad practice. Setting a correct module is both important for a correct uninstallation of the module (which uses the module to decide which records to remove) and for the translations (records tagged with 'base' module needs to be declared in the base.pot file).
-
Martin Trigaux authored
one2many, many2many, text and html fields should take all space in a form view for a better rendering instead of taking only 2 col or not having the label in front the field.
-
Martin Trigaux authored
When a model has no form defined, a default view is generated displaying all fields of the model. The one2many and many2many fields were not displayed on the form, probably for aesthetic or historical (2008) reasons.
-
stefanorigano authored
The snippet section can have a color or a background. Previous commit added the functionnality for its innercolumn too... but having a bg image on top of another one does not make sense, so only keep the color option for columns.
-
stefanorigano authored
- s_references * Replace demo images (lighter ones) * Move title to left * Review responsiveness - s_big_message * Add background * Use grid system
-
stefanorigano authored
* Replace demo blog post covers * Add xml ID to demo images so they can be easily replaced by themes * Remove unused images
-
Yannick Tivisse authored
-
Yannick Tivisse authored
======= Purpose ======= The company form should be heavily simplified. It's complex to have some settings on the company form, and others on the Settings menu of the related app. It would be much easier to have all settings in Settings menu (res.config) and nothing on the company, even if some of the Settings are multi company. (Stored on the company but set from the Settings menu).
-
Denis Vermylen (dve) authored
-
Moises Lopez authored
Historically, developers had to use the `eval` attribute to set a False value for boolean fields in XML data files: <field name="active" eval="False"/> This is a source of errors for beginners, who tend to provide a string value directly, as for char/text fields. Unfortunately string values always evaluated to `True` booleans: <field name="active">False</field> <!-- active == true! --> This patch adds detection of some well-known falsy strings (case-insensitive): `0`, `false`, `off`, as similarly supported for the `noupdate` and `forcecreate` attributes of XML data records. Closes #13152
-
qsm-odoo authored
* The debug manager contains a feature to launch tours, adapt it to new web_tour.tour system * The website help menu allowed to relaunch tutorial tour in debug mode. This feature is not adapted to new tour system and was useless in the first place (debug mode in frontend is barely used anyway). -> remove the website help menu and the feature
-
Christophe Matthieu authored
-
Christophe Matthieu authored
(unlaunch, need to create an new test for menu)
-
David Monjoie authored
Since res.users is an inherits of res.partner, the onchange that should be triggered by tz to update tz_offset is not triggered. Considering tz_offset is never used on res_partner and is only used by the timezone_mistmatch widget which compares the offset with the one of the browser timezone, which only makes sense if you are a user, we could have completely moved this field on res.users. That being said, it feels strange to have a tz field defined on partner but having to be a user to compute the actual timezon offset, which doesn't need any additional information. For this reason, we chose to duplicate it until either we decide to truly move it in the next version, or the orm is fixed to correctly trigger the onchanges of the inherits models. This patch could be applied in 9.0 if needed, but considering nobody ever complained about this issue and the "workaround" nature of this fix, we decided to apply it in master only.
-
Martin Trigaux authored
and the bad computed & required & default combinaison
-
Martin Trigaux authored
stage_id is comptued and based on stage_ids The default value should be put on stage_ids, not stage_id, it has the same effect but avoids an unecessary chain update.
-
Martin Trigaux authored
Which is useless when there is no inverse method
-
Martin Trigaux authored
The account.move has already self.date for the date field (cf the method `_prepare_reconciliation_move`). As the field date on the account.move.line is a related, it makes useless updates to write it here. Same issue for journal_id field
-
Martin Trigaux authored
ref is a related set on the account.move. Writting on the line set the same reference for all the lines and the parent move (the one of the last line). Instead put it on the move if there is only one reference or do not put a wrong one if we can't determine one.
-
Martin Trigaux authored
Which does not make sense. it's the computation that should set the value. Also the default is no longer needed.
-
Martin Trigaux authored
journal_id is a related field that was set just before
-
Martin Trigaux authored
Avoid setting a value for a related field as it will trigger onchange update. This code was relevant when the date was different on the move and the line but is no longer needed. Remove all the `if vals.get(mandatory_field)` to simplify this method and remove dead code or condition always true.
-
Martin Trigaux authored
The field journal_id and date are both required on account.move and are stored related on account.move.line. Setting the required on the account.move.line allows to make it required in the views or for the ORM but in practice it will be same as it's required on the parent. Making it required is a performance killer as it forces to specify a value for the create which will retrigger an update on the parent move. This means that adding a line with a date value on an account.move with already 10 lines will trigger 11 updates (date of the new line -> date of the move -> date on the 10 existing lines), even if the value has not changed.
-
Mansi Gandhi authored
Currently some customers receive the automatic notification 'Quotation viewed by customer'. This should not be the case as this notifciation is purely internal and should only be sent to the quote responsible. Notification is now a note with the responsible being directly in the recipients.
-
Christophe Matthieu authored
Commit 93394908 added the odoo variable definition in the iframe template so the condition which checked if odoo.define is available had to be adapted.
-
Fabrice Henrion authored
-
Pierre Masereel authored
The 'purchase_ok' field has been moved into the 'purchase' module in rev https://github.com/odoo/odoo/commit/e945b86d5a61e53a9104ab6cc4ed4a1c060587e4 and removed from 'product' module in rev https://github.com/odoo/odoo/commit/fee03009cfcc41d108a79a2380912f21bc825d77 to fix a duplicated field. But it should actually stay only in 'product' module because the field is needed in the 'account' module which doesn't depend of 'purchase'. So to fix it we set back the 'purchase_ok' field in the product module as it was originally in the rev https://github.com/odoo/odoo/commit/e23e018285b17450af97cf93165704926f8248db
-