| Age | Commit message (Collapse) | Author |
|---|
|
Before this commit, in Project App, when the "Collaborative Pads" is
enabled in the Settings of this app, if the user create a task without
project or in a project that has not the pad enabled and he writes a
description for his new task and select (another) project in which the
pads is enabled then the description field in the form view changed to
have the collaborative pad and the problem is the description is not
copied in the pad and seems erase/delete for the user.
This commit checks if the pad_content_field is not empty after
generating the pad url for the new task/record, if it is the case then
we copy the content in the pad and the user can continue his edition
before saving the task/record.
Step to reproduce:
-----------------
1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project A"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the Project B. With this change,
the collaborative pad is actived for this task since the Project B has
the pad, and then the description in the pad is empty rather than have
the content that we have just written.
task-2515150
closes #70401
X-original-commit: d2b55c775d705128fa65c859c5f47bdaf4b705fe
|
|
Currently, when we have pad issue when we switch the pad to html
editor.
for Ex: In the Project app with the Collaborative Pad activated, if we
create a task and change the Project name multiple times (one having
the Collaborative Pad activated while the other not activated), then
at one point the Collaborative Pad doesn't show up and it will display
object object.
issue is due to object value of the url and it was not going to check for
the startwith 'http'.
So in this commit, When value is json method convert it to the json object
so the value must check proper condition for the startsWith(this.value, 'http').
closes odoo/odoo#63046
Taskid: 2336325
X-original-commit: 73bfe794351b2881fed041983b90f3d90025d23e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Since commit: https://github.com/odoo/odoo/commit/c31bf95e4e5e01e9f433ac13c6be33f85a57f9b9
There is typo while getting username from session so it was default set
as 'undefined' for collaborative pad editor name.
Get the proper username from session as 'username' instead of 'userName'.
but now we want's user's whole name so instead of username(login) take
the name(name of user).
closes odoo/odoo#43805
Taskid: 2154331
Closes: #43805
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
This reverts commit ff1c35513aecef5fbc30f7c2f3834450e719714e.
closes odoo/odoo#41480
X-original-commit: 116057b26e71db4692280463669f3e80d813ddcc
Related: odoo/enterprise#7110
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
When the adapation without jQuery promise was done for 12.3 (in
bfed574255fc) the hack for always saving a pad URL was added in
the deferrence of the start method.
This caused that in the following conditions:
- pad URL is set
- form is in edit mode
- a change in the form change the readonly status of the pad
=> we would have a mutex lock (of the form change) waiting for the pad
that is being rerendered to finish its start but that can only be done
once the mutex is unlocked (because setValue of the pad is protected by
the same mutex) => so we have deadlock and interface does not allow to
save or do any other change.
This happened for example if we had a project.project A without
collaborative pad, project.project B with collaborative pad, and if we
moved a task from project B to project A then back to project B.
With this change, we get back to the behavior before bfed57425 of not
waiting for the fake "setValue" in `start` of Pad.
Without the change, added test fails with:
Expected 1 assertions, but 0 were run
because interface is deadlocked so write does not happen.
opw-2150827
closes #41346
closes odoo/odoo#41406
X-original-commit: cc73abb218e17756b21824a192f4461eb8537c0e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
FontAwesome 5 introduced new names for some icons as described on
https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4#name-changes
This commit replaces the old names to the new ones.
closes odoo/odoo#35826
Taskid: 2050241
Related: odoo/enterprise#5180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
The system completely changed. I also had to adapt classes to new
screen breakpoints.
hidden/hide -> d-none
show -> d-block
hidden-xs -> d-none d-md-(block/inline/...)
hidden-sm -> d-md-none d-lg-(block/inline/...)
hidden-md -> d-lg-none d-xl-(block/inline/...)
hidden-lg -> d-xl-none
visible-xs-* -> d-* d-md-none
visible-sm-* -> d-none d-md-* d-lg-none
visible-md-* -> d-none d-lg-* d-xl-none
visible-lg-* -> d-none d-xl-*
hidden-print -> d-print-none
visible-print-* -> d-none d-print-*
...
and all possible combination of those had to be handled too.
|
|
In mobile devices, the pad widget did not behave in a satisfactory
manner. Also, once it was in fullscreen mode, it was not possible to
come back to normal mode.
Task: #31545
PR: #15817
|
|
Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".
This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.
|
|
Before this commit, the pad widget did not force the view to save the
current value, since it did not change (pad values are just the url for
the pad). However, this is a problem for the server, since it uses the
fact that the web client forces a save to update the description field
in the model (get the data from the pad server and add it to the
database).
This was not a big deal when looking at the pad (the pad widget fetches
its data each time), but it is a problem that the database is not
synchronized with the current data.
|
|
The pad widget does something unconventional: it creates the pad url
only when rendering in edit mode. This was done to prevent creating pad
by default for record in readonly mode.
Because of that, if the user clicks on create, then discard, the record was
considered dirty, so a confirmation modal popped up. In this commit, we
just make sure that the initial setValue from the rendering does not
'dirty' the record.
|
|
Before this fix, it was possible to set the widget 'pad'
on char fields but it only worked if the current model
inherited from 'pad.common'.
In the other cases, it crashed on closing Studio.
As there is two models only (project.task and
note.note), we decided to remove the possibility to set
this widget in Studio.
opw-745997
|
|
The pad widget was partially updated to the new views, but was no longer
working. In this commit, we rewrite the widget to make it work.
Note that we did some functional changes:
- we do only one rpc to check if the server is configured. the result is
stored on the prototype, so we do not need to do it again
- we do some rpcs with shadow: true, so we will not stop the rest of the
ui if the server is slow to respond
- we display a loading message in readonly, when the content is not
loaded yet.
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
|
replace the icon for fullscreen by the same one used on YouTube (or a similar one) + add tooltip 'Full Screen' and 'Exit Full Screen'
|
|
as it prints the helper saying that the pad will be initialized
on first edit.
|
|
|
|
- better use of deferred
- avoid useless re-render of widget by using `internal_set_value`
- encode username in pad url
|
|
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
|
|
|
|
|
|
revid:dle@openerp.com-20140409162932-y5fxd5wbojing2t2
bzr revid: dle@openerp.com-20140409163132-n3apqh6nvfg2qof9
|
|
value calls wait for each others
Proper fix than 9968 revid:dle@openerp.com-20140409160214-1anxi8z07xj49vsp
bzr revid: dle@openerp.com-20140409162932-y5fxd5wbojing2t2
|
|
value calls wait for each others
bzr revid: dle@openerp.com-20140409160214-1anxi8z07xj49vsp
|
|
bzr revid: acl@openerp.com-20140409114825-t10ps6o7qn7qbd7y
|
|
odo@openerp.com-20140314143519-x6rzcfkkqxwc0e1g
bzr revid: odo@openerp.com-20140314143911-c2mxesg31xezeyr9
|
|
edition warning in read-only mode for new pads, translate messages
Added a small method to detect the proper server configuration,
and make it degrade gracefully if the method is not present.
This avoids having to force a pad URL generation in order to
test the config (possibly creating useless pads).
Add a user-friendly message when the pad has not yet been
initialized for a given record, in read-only mode.
bzr revid: odo@openerp.com-20140314131849-rnjvk1pqpiyvtc1c
|
|
chs@openerp.com-20140313163420-ifa4hyixj722d6jo
bzr revid: mat@openerp.com-20140313091920-bahej198pu339e28
bzr revid: chs@openerp.com-20140313170940-yoqg6izfw74s2i3a
|
|
bzr revid: chs@openerp.com-20140313153535-ogyip9tfm2hkwn1f
|
|
dle@openerp.com-20140213115951-h7c2o65lgg26aosv
bzr revid: chs@openerp.com-20140212182315-clifgy95ug2rd6d8
bzr revid: dle@openerp.com-20140213120325-zq9bnl035i1s6xd4
|
|
bzr revid: chs@openerp.com-20140212181014-rk1qh1pcovtmjhqu
|
|
lp bug: https://launchpad.net/bugs/1267108 fixed
bzr revid: chs@openerp.com-20140212134747-moiyebzdti4ieyc4
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130424074638-aq3o08v7z9j1asz0
|
|
by solving another, more serious, bug that didn't updated correctly the database backup of the pad
lp bug: https://launchpad.net/bugs/1155039 fixed
bzr revid: nicolas.vanhoren@openerp.com-20130419143529-jku5titoacaajft0
|
|
bzr revid: chm@openerp.com-20121213145855-0aq9wqtovyrxzxkw
|
|
bzr revid: chm@openerp.com-20121213145714-b9d4f2u8iqdg8r1m
|
|
list view, etherpad is dipslay on readonly mode but with the oe_editing class. Why: The deferer for read only arrive after the display of edit mode. Fix: check in the deferer if the etherpad is already in readonly mode.
bzr revid: chm@openerp.com-20121203085116-jn83em3pd5le28rp
|
|
lot of incorrect css
bzr revid: nicolas.vanhoren@openerp.com-20121120155155-y1wd0px4trljf453
|
|
bzr revid: tta@openerp.com-20121109065144-hut93odny1ur16db
|
|
'done'/'fail' and 'pipe's in 'then'
bzr revid: fme@openerp.com-20121031103148-r1slfpl2kcnajjd3
|
|
bzr revid: nicolas.vanhoren@openerp.com-20121029153653-m5f8uorbhqt4s8gp
|
|
bzr revid: nicolas.vanhoren@openerp.com-20121012121126-atu1vf14rc4fxu0g
|
|
bzr revid: fva@openerp.com-20120925135557-09s58wkbt038yxpo
|
|
bzr revid: fva@openerp.com-20120924134600-5avqr2vohdsh7y9n
|
|
bzr revid: chm@openerp.com-20120920105713-meckyb4pnlxbapzk
|
|
bzr revid: chm@openerp.com-20120920075031-lx6k382cd8kcyct9
|
|
bzr revid: chm@openerp.com-20120919143553-lmlvshitpkkftyln
|
|
bzr revid: al@openerp.com-20120829123833-4b9kp33d9ne2gyom
|
|
bzr revid: al@openerp.com-20120829093743-syqklh5mypeiqxjp
|
