| 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
|
|
closes odoo/odoo#62335
Related: odoo/enterprise#14982
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
STEPS:
* install pad
* switch to a company different from res.users::company_id (Default Company for
user)
* set credentials for that company
* Open a form with pad, e.g. project.task
BEFORE: it doesn't work, pad_generate_url returns empty values
AFTER: it works
WHY: Since Odoo 13.0, current company is computed by context values provided by
company swither, while user.company_id is default value
https://github.com/odoo/odoo/blob/d6d26ea8ac0c160b1fa12f86083965a087aedc75/odoo/addons/base/models/res_users.py#L245-L246
https://github.com/odoo/odoo/blob/5c79992f1f0f1b5a8ac4c1f464347abc10a6d8d8/odoo/api.py#L555-L562
---
bug is founding during work on
opw-2369677
closes odoo/odoo#61185
X-original-commit: cbf6fd596dd87b3ad453e76957cd4c6ea8d57d80
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.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.
closes odoo/odoo#60324
X-original-commit: 8ffc00fb2a88dbf2c340b6e7fc48ae137464e59d
Signed-off-by: Martin Trigaux (mat) <mat@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>
|
|
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'`
|
|
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.
|
|
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
closes odoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
closes odoo/odoo#30412
|
|
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
|
|
Before installing pads, create a second company
On the first company, create a task and initialize its pad
Switch companies and try to edit the task
Before this commit:
There is a traceback because since the pad credentials of the second company are not set,
the url cannot be computed
After this commit, we prevent the Null field to concat with a string
hence there is no traceback
OPW 1837059
closes #24263
|
|
The duplication of a task crashes at the following:
`content = myPad.getHtml(path).get('html', '')`
The copy mechanism is quite cumbersome:
- In `copy` method, generate an URL of a pad which doesn't exist since
`object_id` is still undefined.
- The `create` method somehow attempts to fill in the previously created
pad thanks to `_set_pad_value`.
The logic is made simpler. The pad URL field is set as `copy=False`,
therefore the create mechanism will take care of handling the pad
creation and its synchronization.
opw-1818757
|
|
|
|
Before this commit, when duplicating a task,
the pad of the original one was updated with plain text
Hence losing all the layout.
This was because, in all likelihood, Odoo's Etherpad server did not support pushing HTML
At the time of the commit, Odoo's pads can receive HTML.
We then push HTML by default, falling back to pushing text as before
if necessary
OPW 806064
|
|
|
|
|
|
|
|
|
|
Purpose
=======
Currently if a project doesn't use pads, the created and duplicated tasks will initialize/copy them. That could be a real issue when migrating customers if we create a task for all the existing issues, since the models have been merged.
Specification
=============
Avoid this falsy behavior. We're forced to crappy fix with a context key as the project.task model 'inherit' from pad.common.
|
|
Avoid error during pad creation
TypeError: cannot use a string pattern on a bytes-like object
|
|
In python3, items() and keys() returns iterators.
Modifying a dictionnary while iterating on it may trigger an error:
dictionary changed size during iteration
|
|
Now that we only have one model (res.config.settings). Uniformize everything according to the guidelines.
|
|
Purpose
=======
Settings are often way too long and hard to scan and sometimes you don't know where to find the settings you're looking for.
By adding a left navigation, you can already have an overview of the settings, and switch easily between them.
Specification
=============
- Add a search bar on all the apps that have settings which can search results from all the installed apps.
(If i'm on sales settings,and I search anything then it shows results from sales settings and also shows
all the other matching results from all the other apps such as, Inventory...etc) with app name.
- Able to activate feature from the current page results (no matter if the searched result is from another apps).
- Highlight searched word in results
- Delete the sheet, have a full white background
- Add left navigation bar on setting
- Left navigation bar fixed
- List displayed based on installed apps
- On right panel, by default display current app setting and change accordingly
- [Mobile] Left navigation bar displayed on top
- Add Breadcrumb on top of the page: have the name "Settings" + Save / discard CTA + Search
- Add General Settings on the nav bar
- remove "save this page..." notif in all settings
- Delete all recommanded apps section + all checkbox that install app should disappear:
payroll: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrSkMzWVpuZ0ZoaFE/view?usp=drivesdk
Events: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrYXlHMHd2NTM2blE/view?usp=drivesdk
Manufacturing: Delete Repair - Quality Control - Maintenance - Product Lifecycle Management [LAP][ok]
Timesheets: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrdFg5XzNydkd2TlU/view?usp=drivesdk
project: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrraWo3NE04TktwcTQ/view?usp=drivesdk
inventory: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrQkRaVUR5ekFQYTQ/view?usp=drivesdk
recruitment: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrbDdqLWQweF80UkE/view?usp=drivesdk
purchase: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrRlAyUDBnb0trQWs/view?usp=drivesdk
email marketing: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrOUZONjhvX2k3Y2s/view?usp=drivesdk
expenses: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrrR0JpN1ZpQmtxU3M/view?usp=drivesdk
attendances: https://drive.google.com/a/odoo.com/file/d/0B1uIL9E_zXrralpjZ1VJclNpMWs/view?usp=drivesdk
- About duplicate settings:
Docsaway: Delete from Sales + delete Default Print Provider
Attributs & Variants: Delete from Purchases - Manufacturing
Multi-currencies: delete from Sales
Unit Of Measures: Delete from Purchase & Expenses
- Add a scroll bar on the left bar when there's too many apps
- Keep the navbar visible even when you search
- Move General Settings to the bottom of the list
- Update on Settings:
- Accounting:
- rename automatic rates
- Anglo Saxon Account: Should be in technical feature
- Place Accounting Reports section before Taxes section
- CRM:
- Phone Validation: Enforce international format becomes
- Local Numbers: (2 radio buttons proposals) Add international prefix / No prefix
- Fleet: typo " ... a new car if ..." + text is too long <br>
- project: fix tooltip for colab pads
|
|
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
|
|
|
|
Backport of 0de067cae919937cfc5fa4cd3161d58f48d472b5
(and 9b8bc5e5a11d625a72043e2b076d99be3c24d2c4)
Rev. c5bd50927441ba98ae99d56ff765111cf4f6d2f3 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
|
|
Rev. c5bd50927441ba98ae99d56ff765111cf4f6d2f3 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
|
|
|
|
|
|
If the pad content field is modified in Odoo, the content of the pad should be modified too.
Example: When merging tasks, the tasks descriptions are concatenated into the target record. But the taregt pad is not modified if it already exists.
|
|
|
|
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
|
|
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
|
|
* LDAP import: python-ldap is not python3-compatible, pyldap is
Warning: only supported from debian Stretch (current testing)?
https://packages.debian.org/search?searchon=names&keywords=pyldap
* implicitly relative imports
* imports of moved or removed stdlib modules
issue #8530
|
|
|
|
|
|
|
|
related modules
=======
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).
|
|
|
|
|
