Added #15677: API Route for Generating Asset Labels

[NebelKreis]

Description

This PR introduces a new API route /labels that allows users to generate asset labels in PDF format. The labels are encoded as Base64 and returned in the API response. This feature streamlines the process of creating asset labels programmatically, enhancing flexibility for integrations with external systems.

Key Features:

• New API Route: POST /labels
• Request Format: The API expects a JSON payload with an array of asset tags.
  Example Request Body:

  {
    "asset_tag": ["100000", "100001"]
  }

• Response: The route returns a Base64-encoded PDF file containing the generated labels for the provided asset tags.

Fixes #15677

Attached below is an example of how the resulting labels appear:

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update (API Explorer)

How Has This Been Tested?

The implementation has been tested through the following methods:

• Unit Testing: Verified that the API route handles valid and invalid input appropriately. Tests include:
  • Generating labels for valid asset tags.
  • Handling invalid or missing asset_tag fields gracefully.
  • Manual Testing: Tested with various sets of asset tags to ensure correct label generation and Base64 encoding.
  • Integration Testing: Ensured compatibility with existing asset management workflows and external API consumers.

Test Configuration:

• PHP version: 8.1.2
• MySQL version: 8.0.39
• Webserver version: Apache 2.4.52
• OS version: Ubuntu 24.04

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

[what-the-diff]

PR Summary

• Uniform Language Strings
  Our team updated the existing language strings in the hardware messages file to provide a more consistent user experience.

• New Language Strings Added
  We have also introduced some new language strings. These include 'labels_generated', 'error_generating_labels', 'no_assets_selected'. These will be useful to provide more specific and clear messages to the users.

• New API Route for Labels
  A new API route for generating labels has been implemented. This new route will streamline the process of creating labels for assets.

[snipe]

Hi there - thanks for this! It looks like we have some failing tests - is that something you can look at?

[NebelKreis]

Sure, I’ve taken a look at the issues:

The Codacy Static Code Analysis Check is failing due to the following message:

The method getLabels() has a Cyclomatic Complexity of 10. The configured cyclomatic complexity threshold is 10.

This issue arises because the method includes several checks to ensure robustness, such as verifying whether the label was successfully generated or if the PDF content is empty. These additional checks are crucial for the integrity of the process but do contribute to the higher cyclomatic complexity.

Regarding the MySQL / PHP 8.3 Test failures, I suspect this issue is similar to what was observed in PR #15747. In that case, the failures were unrelated to the submitted code itself. After rebasing to the latest develop branch and then switching back, all tests passed without any code changes. Based on that experience, I believe these failures might be environmental or related to external factors rather than the code in this PR.

Let me know if you’d like me to make adjustments to the code or provide further clarification.