* Windows facts for ansible_winlicense_edition, ansible_winlicense_channel, ansible_winlicense_status added
* bugfix, replaced = with :
* changed facts to ansible_os_license_* in win_product_facts.ps1
Shortened the short_description in win_product_facts.py
removed errant - options: {} from win_product_facts.py
* Code optimisations and changed return code to $null from NA when unknown license information returned from CIM SoftwareLicensingProduct class.
* code optimisation
* Windows: Add special parameter types
Adding explicit parameter types now exposes this information in the
module documentation, and proves really helpful.
We only do this for non-string types as strings, mostly because strings
are implicit.
PS We also make copyright statements consistent and use #Requires for
explicit library imports
* Type "string" must be type "str"
* A few more Copyright corrections
* More fixes
* Don't add file encoding to Powershell files
* Don't add missing interfacetypes parameter
Otherwise CI demands an incorrect version_added
* Small fix
* win_setup: Add Product ID and Product Key in facts
So this is actually a very nice way to get product key information from
systems collected centrally.
Especially with systems that have been upgraded from Windows 7 or
Windows 8 to Windows 10 may not have a valid Windows 10 product
license key printed anywhere, it was a digital license.
If you ever have to reinstall the system, you may recover the system
from the recovery partition, or the original media, but cannot upgrade
to Windows 10 for free. By collecting the product key, one can always
reinstall your free Windows upgrade.
My only question is, do we want this to be part of the default facts, as
it may be considered important information. Or should we make a special
**win_product_key_facts** ?
* Add ACPI product key support
* Add integration test
* Remove Get-ProductKey function, move inline
rhydian76
Dag Wieers