The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
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
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
This commit aims to change the behaviour of <a> links in readonly pad
widgets.
If the <a> redirects to a page that isn't in the domain (hostname
different of the current location hostname), we open it in a new
browser tab by adding a target.
Limitation: If you use the collaborative pad for a while and then
go back to a web editor html field, you'll have to edit each link
in order that the link opens a new tab by clicking on it.
Part of https://github.com/odoo/odoo/pull/64622
task-2377544
This commit makes the pad quick editable like a html field.
When we click on the pad, the form switches to edit mode but
not if we click on a link. A link has the priority over the quick edit.
closesodoo/odoo#66359
X-original-commit: c9e7c6bcde6a568bc5141a29644ab1f1e6a4a312
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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').
closesodoo/odoo#63047
Taskid: 2336325
X-original-commit: 73bfe794351b2881fed041983b90f3d90025d23e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If you want to prevent pad creation without the API key, you configure
the etherpad server with the 'editOnly' parameter set to 'true'.
In this case (copy/pasting the settings.json):
* users may edit pads but not create new ones
* pad creation is only via the API
But if you secure your etherpad server like this, you won't be able to
create pads in odoo in certain circonstances.
This use case does not work (using 'pad_project'):
* secure your etherpad server ("editOnly": true)
* open the Project app and choose a project
* open an already existing task (or create one)
* from this task, click on the "Create" button to create a new task
* the 'description' field displays: "You do not have permission to access this pad"
* if you save, you'll get a traceback: "ValueError: padID does not
exist"
The same issue arise if you create a task from the list (not kanban)
view.
If you create a task directly from the kanban view, there is no
problem because there is an 'object_id' in the context dict.
closesodoo/odoo#60333
X-original-commit: 8ffc00fb2a88dbf2c340b6e7fc48ae137464e59d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, the pad key and server were saved on the company. It was an historical decision whose reasons no longer applies.
The "Root url" called later "URL template" was company dependant but it no longer exists.
closesodoo/odoo#57014
Taskid: 2326514
Related: odoo/upgrade#1739
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
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>
Purpose fo the task is to improve the UX of timesheet, project and task.
Done the chages for below point:
- improve the stage demo data to unified the project stage
- on the task timesheet 'sub-tasks hours spent' should be clickable
and on click, it will display the list of subtask timesheet.
- display in warning tasks for which Remaining Hours < 0 if Planned Hours > 0 in task list view
- improve the settings of collabrative pad and planning and project form view
Task-2129052
closes odoo/odoo#41092
Closes: #41092
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When the adapation without jQuery promise was done for 12.3 (in
bfed574255) 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#41346closesodoo/odoo#41406
X-original-commit: cc73abb218e17756b21824a192f4461eb8537c0e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Xavier-Do