Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
In belgian accounting, some tax lines in the tax report must be carried
over to the next period if they are negative.
If the balance for the next period is positive, it will be deduced by
the maximum possible amount that is carried over. If it is negative,
the negative balance will simply be added to the carried over balance.
This process repeats itself from one period to the other endlessly,
until the carried over balance come back to 0.
This is done by putting the carried over balance in dedicated analytic
accounts.
task id #2271978
If a user has no access to Invoicing module, he can not send and print his invoices.
To reproduce the error:
(Need sale_management,account)
1. Connect with admin account
2. Settings > Users & Companies
3. Create/Edit a salesman
- Remove access rights to Invoicing module
4. Connect with this user
5. Create & Confirm a SO
6. Edit the SO and fill in the "Delivered" field, Save
7. Click on "Create Invoice", "Create Invoice"
7. Connect with admin account
8. Invoicing > Go to the previously created invoice
9. Confirm it
10. Connect with the user account
11. Sales > previously created SO > "1 Invoices"
=> The user can read the invoice, but he can not send and print it. This is an error.
OPW-2389428
closesodoo/odoo#64508
X-original-commit: f64f7ca309f9228e58b1487a286f2302ff8f035e
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
This reverts commit 7e3e99adb4.
Usability of that new wizard was too poor. We revert it for now; it'll make a comeback eventually.
closesodoo/odoo#63436
X-original-commit: 1d75786b8b45fd4f6b08d726165b60875b62b1e7
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Task 2005940
account:
* Use stored compute methods instead of default for
{out,in}bound_payment_method_ids
* Track is_move_sent in the chatter
* Split 'Invoices' and 'Bills' in the smart button of payment form
* Because account.payment.method can be shown on the res.partner form,
we need to relax the security level to readonly for all users
account_check_printing:
* Add the preferred payment method for partners, with a related on
account move allowing to do a group by and doing payments in batch
* Add a constraint to forbid twice the same check number in the same
journal
* The amount in words is now readonly to prevent typos and mismatches
with the amount in digits
* Remove the field `check_number_int`. The check number is kept as Char
so that '000012345' is not displayed (and printed) as '12,345' but it
is parsed so that comparison and incrementation are possible.
closesodoo/odoo#56179
Related: odoo/upgrade#1669
Related: odoo/enterprise#12527
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Task 2227389
The wizards for creating Accrual Entries and Transfer Entries are quite
similar. We are merging them as they share code and business logic.
Entries in the future should not be posted for both wizards, but set to
be auto posted instead.
- Make sure to have 'Billing' access rights
- Create an invoice
- Fully paid this invoice
- Try to unreconcile the newly created payment
=> You should have the access rights to do that
closesodoo/odoo#53785
X-original-commit: 5b2f9bac2a430b77637c28f4ee54ae66789ea116
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Purpose of this task is,lots of business flows can be crashed if
the field Private Address(address_home_id) is a private address instead
of a regular contact.
so in this commit,we change the demo data for employee and set the
private type address on employee for private address and also fix
the flows on which errors could occur.
Currently billing administrator does not have right for private address
and while creating payment from expense it was going to set the
customer from the employee's private address on payment so give the
private address right to the billing adminnistrator.
Also chaned admin/demo user's private address as 'private' instead of
regular contact.
and on hr_expense use the Sudo while accessing the home address this
method is used from payslip too.
TaskID:2170016
closes odoo/odoo#46628
Closes: #46628
Related: odoo/enterprise#8924
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Partner mapping is a new field defined on invoice matching reconciliation models. It allows defining a mapping between partners and regular expressions. When ran, on a statement line without any partner set, those rules use this mapping to assign a partner to statement lines without any one set, using the regular expressions to match the payment reference of the statement line.
It is important to note that the mapped partner will only be set to the statement line when the reconciliation is actually performed (so, when clicking the validate button, if the matching rule is not auto_reconcile = True), just like with the partner_map.
Task 2201948
*These actions were either unused or only used in enterprise modules.
The first ones have been deleted, and the second ones have been move to
the corresponding enterprise modules.
* account.fiscal.year: the whole model has been moved to enterprise
closesodoo/odoo#46110
Related: odoo/enterprise#8706
Related: odoo/upgrade#1083
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The model account.setup.bank.manual.config (menu "Add a Brank
Account") was with the group account.group_account_user ("Show Full
Accounting Features").
Since 65530dfd6a, transient models have ACL and are not accessible
if the user does not belong in the group.
The account.setup.bank.manual.config model is triggered via the server
action account.action_new_bank_setting instead of a classical
menu. It's also displayed in an onboarding step of account.
Because of this, the group must be relaxed (and not just adding a
group of a view/action)
In saas-13.2, 65530dfd6a made simply the wizard appears in readonly
but in saas-13.4, since 56a8c9e431, trying to display a model on
which we do not have access produces and access rights error.
closesodoo/odoo#51330
X-original-commit: a4a2b8198d5d2d368e279929a5cdbcca0376d8ef
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Merge account_analytic_default into account
Merge account_analytic_default_hr_expense into hr
Merge account_analytic_default_purchase into purchase
Prevent having to manually install default modules after activating analytics
closesodoo/odoo#50816
Task: 2182900
Related: odoo/upgrade#1186
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In the same xml file (meaning one of the two rule is useless, or wrong
if giving less rights than the other).
Removing rules that had no impact will ease the understanding of
security problems, by reducing the number of interconnecting rules.
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Purpose:
If the user is not using receipt functionality in his organization then it's can be hidden.
Current behavior before PR:
Sale and purchase receipt by default show when the account module is instaled.
Desired behavior after PR is merged:
Now users can activate Sale or purchase receipt from accounting settings.
closesodoo/odoo#44464
Task: 2028813
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The recently added group "Show Full Accounting Features - Readonly" was
shown in the selection of groups of accounting, but the "Show Full
Accounting Feature" wasn't. It was inconsistent and allowed to see the
features too easily (not debug mode needed)
closesodoo/odoo#45419
X-original-commit: ed3adb320c6680bb213965c84b6b7fd5654c8121
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@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
Without any access rights on the 'account' module, a salesperson should be able to
create a new invoice from a sale order.
Since the merge of account.invoice with account.move, we need to manage carefully the
access rights when dealing with invoices. A salesperson must not be able to manage the
journal entries except the one being an invoice created for a sale order.
To make such restriction on the journal entry's type, we need additional record rules
- in sale: to restrict the access to invoices.
- in account: to exit such restrictions when having billing access rights.
closesodoo/odoo#44023
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The recent refactoring made at 30cf7bc798 introduces a new object for the different writeoff lines that could be created from a reconciliation model. Unfortunately, Billing users were forgotten during that refactoring which made them unable to read/use the reconciliation models anymore.
This patch grants them the Read and Create permission on the new account.reconcile.model.line object, as they already have to the reconciliation model.
closesodoo/odoo#42009
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closesodoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Introduce a new account.tax.report object
> Tax report lines now refer to a tax report, and the tax report to a country
- Tax report lines can share tags accross reports within the same country
> To support the cases where some report is a simplified version of another one: some of its lines can be computed in the same way as the 'bigger' report.
> This is done by giving the same tag_name to the tax report lines, and the same country_id to their parent report.
> Full support for tag name modification, and the way it impacts the shared tags (sometimes, we can overwrite them all, sometimes we must delete them, sometimes, we create new tags to replace them on some report lines).
- Support copying tax report (and the lines/tags linked to it), so that it is possible to duplicate them and change the country set on the duplicate for use in another country (coopying is way better as replacing in place, as we don't keep any link to an xmlid, and still allow using the original report in the original country it was created for).
- Make all l10n* modules compatible with those changes
closesodoo/odoo#38964
Related: odoo/enterprise#6217
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Task 2092104
Accounts group Hierarchy should be automatically well done without to
have to specify the parent (based on the account group CODE)
Before, we had to set all the accounts in the correct groups manually
and it was cumbersome.
Now:
* No need to fulfill account group parent
* No need to fulfill account group id on account
We can still change the groups if there are exceptions; the groups are
only set at create and write time.
As the group_account_invoice doesn't have the access rights to unlink the
account.partial.reconcile/account.full.reconcile, there was impossible for
the user to undo a reconciliation.
closesodoo/odoo#40934
X-original-commit: 0288adb0c315a1da63fe7e2d9b1f586ad6c9555b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When the only app installed is 'invoicing', people were getting an error while trying to generate the account.reconcile.model from its template. Could have done it in sudo(), truth is: account.reconcile.model object is not security critical
closesodoo/odoo#37622
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2072312
* Change the label "/" by "Draft <document type>" for draft entries (change name_get() of account.move)
* New left-bar menu for a chart of account & general ledger view: Take into account the company (for multicompany, avoid having the number 7 if the current company doesn't have 7xxxa accounts)
* New filter "Accounts With Entries" for the chart of accounts
Show only account which has at least 1 journal entry on it
* Show the move_id on the move line tree view
Task 2008956
* Add the root of an account (first 2 digits/char) as a searchable model.
* Create a custom searchpanel for this account root on account.move.line
* Add the account_root searchpanel to the account.account view too.
When validating a invoice, the billing user should have access (read) for all analytic
lines. A problem appears when timesheet is installed, since there is a mismatch with
ir.rule (a timesheet is an analytic line with a project set).
The rule "account.analytic.line.billing.user" already exists for this problem, but should
be extended to work in any case.
To reproduce:
- set a user as timesheet manager and billing user
- try to validate an invoice (or post an expense)
- got an access error with "account.analytic.line.timesheet.manager"
opw-2041615
closesodoo/odoo#35297
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
[IMP] account: make all tax report lines accessible in every company
The former implementation, with a record rule, did not support the new multicompany implementation. Furthermore, making the tax reports accessible by every company whatever their contries is more consistent with the way other accounting reports work.
closesodoo/odoo#34154
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
This table tracked standard price changes.
It was used to compute the valuation at date in AVCO and standard
through `get_history_price`.
The next commits will introduce the stock valuation layers, separating
the valuation from the stock move. As a valuation layer will be created
when a standard price is updated on the product or when a stock move
impacts the valuation, the information from this table will be
duplicated.
We don't plan to adapt `get_history_price` to work with the valuation
layer since the valuation report at date and today will be the same: a
grouped list on the valuation layers with eventually a domain on the
date.
task-1875873
This commit removes some groups that are now useless since their
only purpose was to allow the user to hide or show some fields
depending on its value, but those fields are optional now.
Task-1902765
closesodoo/odoo#31944
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Add repartition lines on taxes
- Link account tags directly to account.move.line; remove the tag_ids field from account.tag
- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.
>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.
- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount
- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)
- Modify every l10n_* module in order to keep them consistent with these changes
closesodoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When validate an invoice, if the user is member of the timesheet user
group and the billing user group, it is forbidden to create an analytic
line without a project set. The previous commit (81218a8) allow the user
to create an analytic account line by adding a record rule in the
sale_timesheet module.
If only the account and timesheet modules' are installed, before this
commit, an error was raised when trying to validate an invoice in the
account module. This issue occurs because the record rule to allow the
user to create an analytic account line is found in sale_timesheet
module, and this one is not installed.
As an invoice can be validated without the need of the sales module's,
from the purchase module, or directly in the account module.
In this commit, the record rule was move to the account module.
opw-1948132
closesodoo/odoo#31661
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Nicolas (vin)