*= website_hr_recruitment, website_sale, website_crm
Adding 2 new types of fields: tel, url
email, url and tel type can now be applied on existing char fields.
task-2213083
closesodoo/odoo#50891
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = website_crm, website_hr_recruitment, website_sale
Changing label position on existing field was replacing the label with
the default one.
Redirection message was not updating the overlay
Going from show message to redirect without hidding the mesage made the
form d-none
When a select field's label's position was changed the select was not
editable anymore.
Some other miscellaneous fixes
task-2191409
closesodoo/odoo#44911
X-original-commit: 3cf87cc1cb179598cecb736728378e330d3b2e22
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor, website_crm, website_form_project,
website_hr_recruitment, website_sale
The form builder is now using the left panel option system. Many new
options are introduced to build better forms more quickly.
The tests are now running with the new website_form implementation.
Part of: https://github.com/odoo/odoo/pull/42189
task-2092425
closesodoo/odoo#42189
Related: odoo/enterprise#7365
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- install website and crm
- install a second language and translate website
- go to website > create a new page > add a form builder
> create a new opportunity > add a new custom field (selection or m2m)
Previous behavior:
default fields and some messages are not translatable
Current behavior:
more fields are translatable
opw-2168786
closesodoo/odoo#43224
X-original-commit: 2b1359f2d2f85772c98988be5714f31163b70a23
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit fixes the following points:
- While dropping a form builder, the default action is now set to
'Send an email' instead of first available action.
- Titles of the forms which previously were readonly, are now editable.
- When sending an email, the 'reply-to' address is now set from the
email field provided in the form, instead of the catchall mail.
- Hitting 'Send' button for 'Send an email' option now immediately
sends the mail instead of putting it in the queue.
task-2082970
closesodoo/odoo#42515
X-original-commit: 7ada68cc91fde1b6eff151549808a20e85cb5bf7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the rendering of inner content of the left panel
options was handled through _buildXXXElement methods in the options
widgets. Now they are handled through sub-widgets which also handle
the user events.
Each sub-widget is notified with the string value it should hold
according to the snippet option target and methods. Each sub-widget
notifies a string value following user interactions, which snippet
options can use to adapt their target through their option methods.
The current sub-widgets introduced by this commit are (others will
follow):
1) we-button
2) we-checkbox
3) we-input
4) we-select (typically containing multiple we-button widgets)
5) we-multi (typically containing multiple we-input widget)
Following this commit only 3 standard option methods remain, which can
be used with any meaningful widget:
1) selectClass
-> Same as before + handle the old 'toggleClass' method when used with
a checkbox-like widget.
2) selectStyle
-> Same as old setStyle, introduced recently (simply renamed)
3) selectDataAttribute
-> Handle both old selectDataAttribute and setDataAttribute, introduced
recently
The parameters these methods received are now:
- previewMode: same as before
- widgetValue: the string value the widget currently holds
- params: additional parameters (mainly dataset of the related xml)
+ params.possibleValues (all the possible values for the method,
meaninful for a select or a checkbox)
+ params.defaultValue (the value that the widget would give if it
even holds no value)
When defining a method in XML, the given value is the default value.
e.g. data-select-style="34px" data-css-property="margin-top"
-> if set on any widget, allows to retrieve a value from the user to
customize the margin-top, the default value being 34px.
-> if used with a we-input, allow to retrieve any value and an empty
value will be equal to 34px
-> if used on a checkbox, allow to toggle between no value and 34px.
-> ...
Hopefully, detailed documentation about all of this will follow. Code
documentation should already be helpful.
Last note: the _updateUI method (replacing the old _setActive) is now
async (so does all the functions calling it). In particular, the _select
method is now async.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
In 13.0 odoo/odoo@6404233bb0 adds a new website_form_key field that was
not taken into account when creating a form from website studio.
This would cause that when editing the form, we would not see it in the
list of form type, and so think it was doing another action that the
current one. And if saved that could cause an issue because the form is
now for doing something else and no way to change it back.
With this changeset, we get back to what was before 13.0 and display a
model in the "Change Form Parameters" modal even if it has no associated
form in the registry (through a website_form_key).
opw-2118567
closes#40533closesodoo/odoo#40578
X-original-commit: 6337a04b73e8030b13d5338cee8c045006c21eae
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit copies design of the last form-field and automatically applies
it on the newly added field to ease the designing.
Part of https://github.com/odoo/odoo/pull/30595
task-1874350
If user changes the form-parameters (like targetted model), it removes
all the existing fields without any warning and re-renders a new form
according to changed parameters.
This commit improves above behavior to prevent accidental loss of a well
designed form. Now when user changes form parameters, a warging will be
shown to user before re-rendering the form if the model is not same.
Part of https://github.com/odoo/odoo/pull/30595
task-1874350
This commit implements following changes:
- aligns radio / checkboxes with their label
- adds an option on radio buttons and checkboxes to
display them horizontally or vertically
Part of https://github.com/odoo/odoo/pull/30595
task-1874350
This commit focuses the first form input on the opened modal (or footer
button in case there's no form input).
This behavior will enable users to navigate through the modal using
keyboard right away (without having to click on input).
Part of https://github.com/odoo/odoo/pull/30595
task-1874350
Co-authored-by: Dharmraj Jhala <dja@odoo.com>
By default, the name of a file input field is 'Custom File Upload'.
If there are two fields with the same name, then they both end up in
self.form_fields with the name 'Custom File Upload[0]', and their values
are concatenated, which are file objects. So the concatenation of two
files is a String, ('[object File],[object File]'), because JavaScript.
(And if you don't like it you don't like the web nor human progress.)
The resulting bug is that instead of adding attachments to the created
record, it adds the string message to the notes.
Adding the outer loop index disambiguates the names, so that all
attachments are created as intended.
opw 2092653
closesodoo/odoo#39674
X-original-commit: 5df3f662dc9f7e3030a899a6f4196245083ad415
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
* website_form
To support old theme options, a hack had to be made to allow access to
left panel UI. This will be improved in master.
Part of https://github.com/odoo/odoo/pull/38495
task-2083198
X-original-commit: 5ac6a7a5dbd2af1190d0d027d0239dd1cfc257b0
-Import a subscription with end date beyond 200 in the future (ex: 2500-01-01).
-Open the subscription and click the Edit button.
Before this commit:
A stacktrace appears indicating that a date is not valid. It's not possible to
edit the subscription.
After this commit:
The maxDate of the date picker has been increased to 31/12/9999, allowing the
user to edit subscriptions whose end date is that far in the future.
A test `toggle datepicker far in the future` for this case has been created.
closesodoo/odoo#38527
Opw: 2079696
X-original-commit: 32b6131c04fef7a542a0ccbdb924d177627bfe38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The modal of the website_form snippet was broken. Now it uses Dialog.
Hidden inputs were not aligned with there labels.
task-2078138
closesodoo/odoo#37545
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Select fields were not `contenteditable=true`, which means they could
not be edited. Besides, being that each of their option was individually
considered a snippet, and that they were contained in `div` tags, they
were effectively unbreakable, which means that adding new options by
hitting `ENTER` did not work (note: this also currently doesn't work
properly in v12.0, for other reasons as the concept of an "unbreakable"
node didn't exist yet). This fixes those issues.
closesodoo/enterprise#4817
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
X-port/Cherry-pick of odoo/enterprise@af51d9ff2a
In python false is written `False` however JSON only support the notation
`false` otherwise JSON.parse fails
Again in python a null value is written `None` however `None` is `null`
in JSON notation
A solution to this incompatibility problem between python and javascript
can be to replace `False` and `None`by empty strings on the javascript
side.
closesodoo/odoo#34995
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
In case of selection or many2one field, while saving the page, the field
is re-rendered and loses the applied design changes.
This commit fixes the behavior by re-applying those changes on a newly
rendered field.
task-1961733
closesodoo/enterprise#4657
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
X-port/Cherry-pick of odoo/enterprise@298a9b3a94
As we now have a new debug mode 'tests' which load a new asset bundle
containing tour-test files, we moved those files to a new folder hierarchy.
That will clean the .js files trees.
Also, those files should be included in the new asset.
Basically, the .js tour files (not test) should be inside /static/src/js/tours
while .js tour test files (test=true) should be inside /static/tests/tours next
to QUnit tests, inside a tours folder.
+ test_new_api: don't run the test in debug assets
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
`t-att-` inside form should be removed because it makes the form not editable
by the form builder.
Instead of having these values set to the `<form>` DOM element, it will use a
`<span>` outside it.
task-32212
Now, the default form already has multiple fields by defult, including
`subject` one.
The test was adding that field, so it now needs to add another one that is not
on the form.
task-32212
That way, it is possible to add the template, fields and success page to
different type of form.
Next commits will use what has been done in this commit.
task-32212
* website_blog, website_crm_partner_assign, website_event,
website_event_track, website_form, website_forum, website_links,
website_mail, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_stock, website_sale_wishlist, website_slides,
website_twitter
While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
The 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.
The 'control-label' class was renamed to 'col-form-label'.
The 'help-block' class was renamed to 'form-text'.
The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
* website_form, debian
Our old library for datetimepicker for bootstrap 3 is deprecated and
an updated version is developed by the same team under the new name
"tempusdominus", for bootstrap 4.
The lib is imported by taking the *unminified build* JS and the *src*
scss. Odoo is also bundling the lib better by putting the scss file
in both backend and frontend assets instead of only in common (so that
the scss is compiled differently for the frontend and the backend).
Note: the lib also needed to be patched inline to solve a bug at one
line.
Before this patch, when a user was editing a website page containing a form
and he clicked "Send", for some reason, the form tried to be sent.
Now, the button behavior is disabled when entering editable mode.
Closes#23852
Before this fix, the chatter always showed dates of messages in military time format.
This was not the expected behavior, as the user could have had customize
the date and time format in the settings of the current language.
Steps to reproduce the issue:
1. Set Odoo in English
2. Settings > Translations > Languages > English
2.1. Set Date Format to %m/%d/%Y
2.2. Set Time Format to %I:%M:%S %p
3. CRM > (Select any opportunity with at least one message) > Mouse hover on elapsed time (e.g. "an hour ago")
Expected:
- It shows the customized time format (e.g. 11/07/2017 5:33:36 PM)
Results:
- It shows the military time format (e.g. Tue Nov 07 2017 17:33:36 GMT+0100)
opw-781647
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
Only the validity of a date was enforced but the date could also be
wrong in other situation (required so must be filled, validation
attributes, ...).
opw-744273
closes#17329
This commit proposes to ease field error management by having a
structured json response having field name as keys and error message
as value. Controllers can return a specific error message for some
fields that is displayed in a popover.
Replace deprecated options for the updated version of the
bootstrap-datetimepicker lib.
Lazy load the library in the front-end as well in order to avoid loading
it in all the front-end views.
fja-odoo