"Global Multi-Company Access" permission for non-admin users

[RobertAzelis]

Related Issue

Relates to: #19200 – [Feature]: Add "Global Multi-Company Access" permission for non-admin users in FMCS mode

Description

This Pull Request introduces a new permission: multicompany
When enabled, this permission allows a user to access all companies, regardless of the companies explicitly assigned to them.

Purpose

In environments using Full Multi-Company Support (FMCS) with a large number of companies, managing access on a per-company basis becomes difficult and time-consuming.
This change simplifies access management by providing an optional global scope permission for non-admin users.

Behavior

When multicompany permission is enabled:
✅ The user automatically has access to all companies
✅ No need to assign companies individually
✅ Works independently of the assigned company scope

When disabled:
🔒 Default behavior remains unchanged (company-based access control)

Scope & Impact

✅ Applies only to users with this permission explicitly enabled
✅ Does not modify existing permission logic for other users
✅ Fully backward compatible
✅ Designed as an optional extension of the current permission model

Use Case

In environments with 100+ companies, such as centralized IT support teams:

• Users require visibility across all companies
• Assigning access company-by-company is not scalable
• This permission significantly reduces administrative overhead

Example:

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 8 complexity

Metric	Results
Complexity	8

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[snipe]

This doesn't feel like the right solve to me.

The PR adds an isMultiCompany() permission check at 10 calls in Company.php and CompaniesController.php, intending to grant non-superusers cross-company access in FMCS mode.

There are roughly 50 other isSuperUser() calls across the codebase. Leaving them un-updated means a multicompany user gets inconsistent behavior — full cross-company visibility in some places, scoped-to-own-companies in others.

There are actually two distinct pain points that this PR conflates:

1. Scaling: "I have 100+ companies and assigning a user to each one is tedious."
2. Access semantics: "I want certain users to have cross-company visibility without being a full superuser."

This PR addresses number 2 by adding a bypass-all-FMCS-scoping permission. This accidentally creates a near-superuser tier with messy boundaries, and it misses quite a few spots.

A better solution treats the two problems separately and keeps access auditable — you should be able to look at a user and see exactly which companies they have access to and why, not "well, the system bypasses scoping for this person."

Something like adding a parent company that easily groups other companies might work better here (though I don't think they should be nested as deeply as locations allow.

[RobertAzelis]

Thanks for feedback - I understand the concerns regarding consistency and broader architectural implications.

I agree that a parent-company or grouping approach could be a good direction for modeling company hierarchy and improving long-term access management. It would definitely help organize structures like:
Main Company → Region → Country companies

At the same time, I would prefer not to extend this PR in that direction.

The intention of this change was to provide a simple and immediate solution to a practical problem:

• environments with a large number of companies (e.g. 100+)
• where assigning access company-by-company is not scalable

This PR is intentionally scoped as a minimal and explicit permission:

• multicompany grants access to all companies
• no changes to existing assignment logic
• no modification of company structure

I see this as a lightweight operational shortcut rather than a complete redesign of access control.

I fully understand that a more structured approach (e.g. company grouping) could address this differently, and I’m happy to leave that direction to the project maintainers.

If this approach is not aligned with the project direction, I’m also fine with closing the PR - but I wanted to propose a simple option that could be useful in real-world large-scale deployments.