Manage EOL date by checkbox of eol_explicit

[Robert-Azelis]

Description

[ It's re-created PR #13846 as I made adaption code to new version 6.3.0 , sorry for confusion ]
This improvement allow setup EOL date manually by user on damand by set eol_explicit checkbox.

BEFORE:

AFTER:
If checkbox is not checked then EOL date is hiden and calculation of date is on the base Model EOL rate

If checkbox is checked then EOL date is showed and user can input EOL Date manually.
Status of checkbox is saved as eol_explicit value

In this way is much easier to manage EOL date and explicit marker status instead of build complex rules :)

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Test Configuration:

• PHP version: 8.1
• MySQL version 10.6.5-MariaDB
• Webserver version IIS
• Web browser: MS Edge, Chrome

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

• Introduction of 'eol_explicit' parameter in Asset Management
  The parameter 'eol_explicit' has been added into the 'AssetsController.php' file. This will allow for better tracking of the status of assets.

• Implementation of 'eol_explicit' and 'asset_eol_date' during asset addition and modification
  A new feature has been implemented where both 'eol_explicit' and 'asset_eol_date' fields can be set when we are creating or updating an asset in the 'AssetsController.php' file.

• Bulk asset update feature enhancement
  The feature in 'BulkAssetsController.php' file where assets can be updated in bulk, has been updated to include updating of 'eol_explicit' and 'asset_eol_date' fields. This drastically improves time efficiency when dealing with large asset databases.

• Changes made to the 'AssetObserver' file
  Improvements have been made to the 'saving' method on 'AssetObserver.php' file thereby making it more robust.

• Addition of language support for newly added parameters
  In 'general.php' file, the translations for 'eol' (End of Life) and 'eol_date_help' have been added. It ensures our app maintains its multi-language support, and remains user-friendly.

• Enhancements in Asset Edit View
  Updates to 'edit.blade.php' file enable displaying of the 'eol_explicit' checkbox and the 'eol_date' picker. This adds convenience during asset editing.

• Updates to the 'eol_date' view
  The 'eol_date.blade.php' file has been updated to incorporate the 'eol_explicit' checkbox and 'eol_date' picker, which provides enriched information about an asset's lifecycle.

[spencerrlongg]

I'll work on getting this reviewed this week. Thanks @Robert-Azelis!

[spencerrlongg]

I think I'd like to actually keep the behavior the same on the API, just allowing the eol_explicit option to be set manually. Let me know if that doesn't make sense to you.

[spencerrlongg]

I'm not sure about this, I think I'd like to still do a diffInMonths() to make sure it is explicit, unless they are also sending eol_explicit in the request.

[Robert-Azelis]

For create new asset via API (store() method), I think it is ok, not required to use function diffInMonths() addtionally for check. In this case we leave decision for user. Using attribut asset_eol_date user want to set eol date manully, out of the model eol rule. This same if is used eol_explicit attribut with value 1. In both cases it's intentionally user's action.
Otherwaise applyed is asset model eol rule if purchase date filled and model eol rate greaten then zero.

[spencerrlongg]

Same as above comment on the store() method.

[Robert-Azelis]

For update asset via API (update() method), similar as it is for store() method.
Only one difference is to check, what is current status of eol_excplicit set under asset to make update asset_eol_date or not, if purchase date or model is changed.

[Robert-Azelis]

I use this modification by some time (last few months) no issue so far 👍

[spencerrlongg]

Hey @Robert-Azelis , while this method is working for you, we have lots of people that may be using this feature differently, so need to make sure that any change is going to work for as many people as possible.

If someone isn't aware of the changes, they might not be aware that they need to send that explicit value now - making their data invalid or misleading.

If we can do the diffInMonths() check than they can continue to just send us asset_eol_date and still have a reliable value in eol_explicit and we can then also allow them to set that manually if they'd like.

[Robert-Azelis]

hi @spencerrlongg , thank you for your comment, but still don't catch your poin.
Argument eol_explicit is optional used only if user would like to force manually set explicity marker, independents to other arguments (much more usefull for switch on/off eol_explicit during update asset - it's not in this part of code.
The main triger is usage of asset_eol_date argument, if has been provided during create or update asset it means user would like to set date manually, not based on automatically calculation. It can be also used in scenario when purchase date is not set, but user would like to keep EOL.

Can you describe scenario or propose exact changes in code (how you would like to use diffInMonths() function)?

I'm open for improvements, but need to good understand how it is expected for use :)

[Robert-Azelis]

Hi @spencerrlongg, no feedback from you so far, if proposed changes in API/AssetsController.php are so difficult to accept, we can skip it at this moment, allow to implment other changes and will return to this part under new PR, what do you think about this?
I don't want to keep on hold this PR.

[Robert-Azelis]

no feedback so far, @snipe can I ask for review?