Fixing #15064 - to not fail ldap sync on single data issue with ldap …

[maciej-poleszczyk]

Description

Change answers issue described in #15064 and the goal is to not fail whole ldap synchronization because of single invalid manager entry.

Fixes #15064

Type of change

Please delete options that are not relevant.

• [ x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Changes were tested with SnipeIT instance that encountered described issue. After introducing change the sync process finishes even if there were some issues with individual entries.

• Test A
• Test B

Test Configuration:

• SnipeIT version: v6.1.1-pre - build 10653 (master)
• PHP version: 7.x
• MySQL version: n/a
• Webserver version: n/a
• OS version: n/a

Checklist:

• [ x] I have read the Contributing documentation available here: https://snipe-it.readme.io/docs/contributing-overview
• [ x] I have formatted this PR according to the project guidelines: https://snipe-it.readme.io/docs/contributing-overview#pull-request-guidelines
• [x ] My code follows the style guidelines of this project
• [x ] I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• [n/a] I have made corresponding changes to the documentation
• My changes generate no new warnings
• [n/a] 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

• Improvement in Error Management
  A measure was implemented to ensure system stability when retrieving certain user-related information. We now have a safeguard in place to prevent the entire process from stalling when an issue occurs - instead, it will be isolated and can be addressed separately.

• Option to Cache Manager Information
  A new feature has been implemented to optionally store ('cache') the manager's details for quicker access in the future. This is determined based on successful data retrieval, thus enhancing system efficiency.

• Selective Caching Based on Successful Retrieval
  The system has been enhanced to store manager data conditionally. It now intelligently decides whether to cache this information based on the success of retrieval, ensuring the cache only stores relevant and accurate data.

• Logging Exceptions for Improved Troubleshooting
  When the system stumbles upon an issue during the synchronization process, it now 'logs' - or records - the issue. This can greatly assist the tech team in identifying and resolving potential problems faster and more effectively.

[snipe]

Hi there - thanks for this! Can you please re-target this PR to point to the develop branch, per our Contributing documentation?

You usually don't need to close and re-open. After you create a pull request, you can modify the base branch so that the changes in the pull request are compared against a different branch. By changing the base branch of your original pull request rather than opening a new one with the correct base branch, you’ll be able to keep valuable work and discussion.

Thanks!