Resolution: Expiration Date

[jens-erdmann]

In a workshop we discussed the potential feature of an expiration date for a resolution. The example scenario was the following: ORT did find a commercial license of a dependency in a project. The user has bought a 1-year limited license for the component. So the right thing to handle this finding would be to write a resolution and to revert it after the license ran out.

So this situation could be improved if the resolution would expire with the license.

[mnonnenmacher]

The are also use cases for an expiration_date for other types or resolutions:

• For vulnerability resolutions it can make sense to revisit the resolution after some time to verify that the reasoning for resolving the vulnerability still applies.
• For issue resolutions it might be decided that it is ok to ignore a technical issue for some time to give teams time to fix the issue.

So it would be good to support the expiration_date for all kinds of resolutions.

[sschuberth]

The idea for the implementation would be to simply add a expirationDate property to the resolution classes and take that property into account in the matches() logic, i.e. not match if the resolution has expired but instead warn / hint about the expiration.

[sschuberth]

The user has bought a 1-year limited license for the component.

Another use-case could be a "review this later" kind of resolution for temporary work-arounds.