First fix for user FMCS scoping

[snipe]

This corrects some of the scoping we were doing around users for exporting lists, editing, etc and adds a lot more info around FMCS in the code (because it's always miserable to try to detangle that hot mess.)

We cannot use the standard CompanyableTrait that we use everywhere else on the user model because it's a global scope, and that causes an infinite loop by Laravel as it tries to add that scope onto the user model of the currently logged in user, in addition to the users listings/view/etc. This took me way too long to remember, but it explains why we handle the scoping on the User model slightly differently.

I also moved the scoping methods in the Company model to the bottom of the file, to keep it consistent with the way we handle query scopes elsewhere.

I'd like to continue working on a better way to handle this so that we get the same benefits of the CompanyableTrait without all the complex manual query scoping we have to do for the User model now, but this solves the immediate issue.

How to test:

Create a company, "Brand Spankin New", and three users:

• spankinadmin1 (admin with "Brand Spankin New" as their company)
• nospankadmin2 (admin without any company)
• spankuser1 (regular user with "Brand Spankin New" as their company)
• spankin asset (asset belonging to "Brand Spankin New")

Easiest way to test this is using three browsers so you have three different sessions. Make sure you have Full Multiple Company Support enabled.

spankinadmin1:

• spankinadmin1 - can only see all of the assets and users within "Brand Spankin New"
• If you fuzz the url to change the /users/{:id} to a user you know doesn't belong to "Brand Spankin New", you should get kicked back with a not found error.
• You should be able to view/edit/clone/delete users and assets within "Brand Spankin New"
• Exporting the user list (via the Export button above the table) should ONLY show users that belong to "Brand Spankin New"

nospankadmin2:

• spankinadmin1 - can only see all of the assets and users without a company assigned
• If you fuzz the url to change the /users/{:id} to a user you know does have a company association, you should get kicked back with a not found error.
• You should be able to view/edit/clone/delete users and assets that have no companies associated
• Exporting the user list (via the Export button above the table) should ONLY show users belonging to no company

Regular superadmins should of course have access to everything they would normally have access to.

Fixes #14539, Fixes [sc-25183], [sc-25258]

[what-the-diff]

PR Summary

• Enhancement in UserController
  The delete user functionality in our system has been improved. Now, it validates whether a user is linked to any other model before it attempts to delete the user.

• Company Model Adjustments
  Changes have been made in the logic that our system uses to handle company-related data. We've simplified it by merging two functions into one, and also made some improvements to the way children companies are managed within our system.

• Permission Clarity in SnipePermissionsPolicy
  We've added comments in the code which give a clearer understanding of how permissions are checked within our system.

• Improved Error Messages
  We've updated some of our error messages to be more descriptive. This includes when a user doesn't exist, and also if a superadmin is trying to update user information in a demo environment. These improved messages will provide a better user experience by making error conditions clearer.

[snipe]

This has broken a few of our automated tests - trying to determine why now.

[bzeus]

Test results are spot on so far.

[snipe]

@bzeus - are you also testing the API or just the GUI?

[snipe]

@bzeus can you test again - I just pushed through some changes

@marcusmoore - can you take a look at the tests I added and make sure I'm not doing anything too crazy?

[marcusmoore]

Tests look good 👍🏾

One minor suggestion on clarity.

Side note: it's best practice to only run one request per test case but I'm guilty of doing exactly what you did here without issue so

[snipe]

Side note: it's best practice to only run one request per test case but I'm guilty of doing exactly what you did here without issue so

I know, I get it. :( But the build up and tear down would be identical if I made them separate tests, so... damned if you do, damned if you duplicate a bunch of code. :(

[bzeus]

Tests are on point, works as it should.