| Age | Commit message (Collapse) | Author |
|---|
|
Steps:
- Install Projects
- Go to Settings / Translations / Languages
- Install Dutch
- Go to Settings / Users & Companies / Users
- Edit demo:
- Language: Dutch
- Go to Projects
- Click the three dots on the first project in the dashboard
- Click Share
- Select demo as recipient
- Send
- Go to Settings / Technical / Email / Emails
- Click the email you just sent
Bug:
The email is not translated in the partner's language
Explanation:
The context of the template didn't take the current partner's language
into account since it was out of the partners loop.
The subject of the email wasn't aware of the partner's language as the
context hadn't been changed.
Wrapping the translations with the right `lang` context value fixes the
issue.
Also, the subject used the formatted string as the translation source.
This makes it impossible to find a matching translation since the source
is different every time.
opw:2475398
closes odoo/odoo#68140
X-original-commit: ef81516f807ad69954787c2180c384887776f840
Signed-off-by: backspac <backspac@users.noreply.github.com>
|
|
Prevent mistakenly adding "portal" to existing internal users through
the portal wizard as that can lead to odd behaviors (to the extent
that since 12.0 the "user type" uses radio buttons so it's not
possible to easily set a user as both internal and portal).
|
|
Convert deprecated tags through the codebase.
|
|
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closes odoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
|
|
Leftover typo from #36804.
The company_id key in the context was removed and replaced
by the generic with_company mechanism, we therefore have to use self.env.company
(and not self.env.company_id which doesn't exist).
closes odoo/odoo#42348
X-original-commit: 4a627816e9c803ff414e6d5a5267b6f44aa25e72
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
|
|
Somehow followup of dbb6cfdbf803d2ab86ba11450b5928abf5ab658b . Purpose is
to use formataddr from tools instead of manually handcrafting the full
email address format. Indeed the tools one correctly encapsulates and
format name and email.
Task ID 2068986
|
|
closes odoo/odoo#38488
X-original-commit: 89270ee39c0daa46ae8e2e3e57d7e512a1a65ddf
Signed-off-by: Romain Libert (rli) <rli@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'`
|
|
Rename the action menu 'Grant Portal Access' by 'Grant portal access'
for the model 'res.partner'.
Linked to task 1984526
Related to PR #33720
|
|
Before this commit, when granting portal access to a res.partner through the
wizard, it would show all the partner + its child_ids, including shipping
addresses partner, billing addresses, private (hr) addresses etc, which makes
no sense.
This commit hide contact-address from the list.
Fixes #32848
closes odoo/odoo#34522
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Xavier Brochard <xavier@alternatif.org>
|
|
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closes odoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
|
|
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.
|
|
Task 1843603
* src_model is redundant with binding_model_id
* multi -> binding_view_types (if empty => all views) (maybe should be
empty by default yo?)
* in convert, type => rec.get(type) but no @type possible on <act_window>...
* removed deprecated auto_refresh & auto_search (not used anywhere (?))
closes odoo/odoo#24738
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
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>
|
|
|
|
|
|
|
|
- When creating a user from the "Grant Portal Access" wizard, the code
checks for duplicate users.
It does so by checking if there is a user with the same login as the
one we want to create.
The check is case sensitive which could lead to issues.
For example a mistyped email (with a uppercase somewhere) could fail
the duplicate user check.
Since emails are not case sensitive, we want the check to be case
insensitive too.
OPW-1932918
closes odoo/odoo#31818
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
|
|
|
|
|
|
Before this commit, we used dict keys before they existed
And made the share button crash
After this commit, there is no crash
OPW 1943301
closes odoo/odoo#31427
|
|
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
|
|
Have a partner which is a company, with some children
Click on the action "Portal Access Management"
Before this commit, only the children of the company is selectable in the wizard
but not the company itself
After this commit, the company is part of the list
OPW 1931920
closes odoo/odoo#31344
|
|
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
|
|
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes #25629
|
|
BS4 "btn-default" class was replaced with "btn-secondary", which makes
more sense.
|
|
Currently it is embedded in a strange condition about reactivating an
existing user or adding the portal group. Let us send the connection
email each time as it contains basic information on the account and is
useful for the newly created or activated user.
This commit is linked to task ID 1843361 (and 1868112) and to PR #25299
(and #25889).
|
|
Purpose
=======
The Contact form is one of the most used/important view. It is quite
important to find the piece of information easily and to navigate in
a few clicks to the related views.
Specification
=============
Stat buttons
------------
- Restructure stat buttons with the following order:
Opportunities -> sales user
Meetings -> sales users
Sales -> Sales users
POS Sales -> pos users
Subscriptions -> Subscription users
Events -> event user
Tasks -> project user
TIckets -> helpdesk user
Purchases -> purchase user
Due -> billing: user
Invoiced -> billing: user
Vendor Bills -> billing: user
Customer/Vendor Partner Ledger -> accounting: billing
Analytic Accounts -> accounting: billing
Credit Cards -> sales user
Direct Debit Mandates -> accounting: billing user
Publish
- Use better/more relevant icons
- Check that the proper access rights are set
- Remove the bank accounts stat buttons and replace it by a one2many
tree on the Invoicing page.
Fields
------
Move some res.partner fields from the "Accouting" page to the
"sale & Purchase" page:
- Fiscal positions
- Payment terms
Miscellaneous
-------------
- Remove dead code.
- Display nothing instead "Please complete customer's informations and email"
on the popup when sending an email to a contact without email address.
|
|
|
|
|
|
|
|
Introduced during forward port at 6a7db305
_company_default_get returns a res.company record, not an ID
opw-1855856
|
|
Purpose of this commit is to standardize portal user creation when
creating new portal users (when 'Free sign up (B2C)' option activated). It
copies the portal user template. The same behavior now applies when
converting a partner into portal user using the portal wizard.
This commit is related to task ID 31399 .
|
|
The is_portal flag was used before to define if a group is a portal group. This is not true anymore since the default portal group should be used for this purpose. All logic associated to this flag can be removed.
TASK: 47937
|
|
|
|
This commit moves the whole customer portal to the portal module.
It now completely uses portal and http_routing features and is not
dependent on website anymore.
An override of web controller is added in portal in order to redirect
portal users to /my instead of /web. That way once having the customer
portal installed all share users are correctly redirected to their
account.
All modules defining customer portal templates and controllers are
updated accordingly.
|
|
And specify which group is incorrect
Closes #17275
|
|
Before the migration, send_mail() used to be called with an untainted
context but after the API migration it inherited the altered context
with active_test=False which caused subsequent calls to
ir.mail_server#connect() to fetch inactive records.
|
|
The goal is to prepare the removal of
'portal' module.
Converting a partner into a portal user,
though the wizard is moved in website_portal.
'base' will manage portal user and group, but if
website_portal is not installed, there is nothing
to display for portal user.
|
|
|
|
The field company_id is not required on the res.partner and is used when the
portal user is created for portal access.
If the partner as no comapny set, the creation crashes (required on the user).
Use system default company, with possibility for overwrite.
Closes #15030
|
|
|
|
|
|
|
|
Do these steps:
1. Create a partner.
2. Grant him portal access through *Actions > Portal Access Management*.
3. Delete the created user.
4. Delete the partner.
You will get this error:
```
Odoo Warning - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: Portal User Config - portal.wizard.user]
```
This happens because the wizard (which is a transient model) does not let the partner to be deleted.
With this patch, we avoid that bug.
Closes #12608
|
|
|
|
|
