Improved Permissions: Set purchase cost to null if user has no permission to view the price

[casdr]

Description

We want to give customers access to view all assets that belong to their company. While the current view_purchase_cost permission hides this value at the self-assigned assets view, it's still visible in other views.

When getPurchaseCostAttribute is implemented this way, it hides the purchase cost for all types of assets for users that do not have this permission.

Example (as VIP user):

Example (as customer user):

This also ensures this data isn't leaked through API/AJAX calls.

I wasn't able to find a related existing issue for this PR.

Type of change

Please delete options that are not relevant.

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Ran all unit tests
• Tested the implementation by creating a user that doesn't have the permission to view the purchase cost

Test Configuration:

• PHP version: 8.2.26
• MySQL version: MariaDB 11.5.2
• Webserver version: Apache/2.4.62
• OS version: Alphine Linux 3.19.4

Checklist:

• I have read the Contributing documentation available here: https://snipe-it.readme.io/docs/contributing-overview
• I have formatted this PR according to the project guidelines: https://snipe-it.readme.io/docs/contributing-overview#pull-request-guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[welcome]

💖 Thanks for this pull request! 💖

We use semantic commit messages to streamline the release process and easily generate changelogs between versions. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix if it doesn't have one already.

Examples of commit messages with semantic prefixes:

• Fixed #<issue number>: don't overwrite prevent_default if default wasn't prevented
• Added #<issue number>: add checkout functionality to assets
• Improved Asset Checkout: use new notification method for checkout

Things that will help get your PR across the finish line:

• Document any user-facing changes you've made.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

[what-the-diff]

PR Summary

• Improved Security Features in SnipeModel Class
  To bolster the security of our system, we've implemented an 'Auth' tool in the 'SnipeModel' class. This is a piece of program responsible for managing items in our application.

• Introduced Permission-based Item Cost View
  We have created a new function named 'getPurchaseCostAttribute'. This function is responsible for managing the visibility of an item's purchase cost, based on the user's access permissions.

• Filtered Purchase Cost Viewability
  Any user who is either not signed into the system or does not have the specific permission called 'self.view_purchase_cost', will not have access to view the purchase cost details of an item - the system will display this as 'null', signifying no data available.

[casdr]

Let me know if this fix is okay for this issue. I can also imagine you want to implement this on the presentation logic, my idea doing it this way was to ensure we wouldn't miss a spot where this check should be implemented.

[snipe]

Hi - thanks for this PR! All PRs should be targeted towards the develop branch, per our dev docs - also, we don't have that permission in the first place. The self permission deals only with a user's ability to see details about things assigned to them (via the Account > View Assigned Assets menu item), while your screenshot is from the POV of a user who has the ability to see assets in general.

[casdr]

@snipe good point. I'll add the permission and use the correct base branch.

[snipe]

I guess I'm just not really clear on the use-case here. If you have the ability to view an asset's history, when would you not be able to view the price of assets not assigned to you. We hide that for assets assigned to the user (via the Assigned Assets section), but it's hard for me to imagine a situation where someone who can view asset details for items not checked out just to them shouldn't be able to see it. Additionally, this presents opportunities for data leakage (for example in the asset's history, if the price was changed from null to a specific value, that change would show in asset history.)

[casdr]

About the use-case:

We want to give some customers access to our Snipe-IT instance. These customers can view all the assets that have been assigned to their company, including those checked out to a location instead of a user, but we don't want them to see the purchase cost. These assets will not show up in the Assigned Assets section.

The data leakage on the history page is an interesting note. If you're open to eventually merging this, I'll look into this as well.

I've also joined Discord if you want to discuss this further over chat.

[snipe]

but we don't want them to see the purchase cost.

That's the use-case I'm referring to - what would be the reason for them being able to view all of the other data on an asset but not the cost?

[casdr]

what would be the reason for them being able to view all of the other data on an asset but not the cost?

Customers buy these assets from us with a margin. Snipe-IT is primarily used by our colleagues internally and we fill the purchase cost from our vendor. The purchase cost for the customer is different from this price, so we want to hide this field for the customers that have access to Snipe-IT.