I have a module that has been installed on this server multiple times. I did an update to the code and was trying to test it and now the module has been placed in quarantine because the license has not been accepted and yet when I installed it and when I hit install later, it does not show me the license to accept.
How do I accept the license after the fact? Or how do I clear accepted licenses for 3rd party modules to allow me to accept it again?
Is there anything in the logs after attempting to "install" the module from the Config -> Modules page in the web UI (in the quarantine section)? It should prompt you if it doesn't already have an accepted record for that module. And if it doesn't (but should have), I'd expect something in the logs that might be helpful.
If you do want to try and clear any existing records for accepted EULAS, you can navigate to http://localhost:8088/web/status/sys.internaldb and then delete the specific record of interest from the EULAS table, e.g.:
DELETE FROM EULAS WHERE MODULEID='com.flexware.lift.mir';
Disclaimer: Poking around in the internal database can easily cause damage. Be careful!
If that still doesn't work, it might be worth reaching out to support. They might be able to inspect your 3rd party module and its construction to determine why it isn't loading.
The module depends on case insensitivity in the filename. There was a change in how module EULAs are handled in 8.1.38 that introduced this behavior. I'll submit a ticket to fix this, because I don't see any reason why we couldn't just ignore case here.
Ultimately, you might as well refer to the same file as you're packaging in the zip though. I've always found that things are case insensitive until they're not--i.e. I always treat things as case sensitive.
For those interested in a corrective action here, you can do the following to surgically replace the license.html with License.html to match what is in module.xml.
These commands should work on a Linux/WSL2/macOS system with zip/unzip tools:
# Preserve original module before manipulations
cp mymodule.modl mymodule-original.modl
# Extract the file
unzip mymodule.modl license.html
# Rename, remove old entry and update zip with renamed file
mv license.html License.html
zip -d mymodule.modl license.html
zip -u mymodule.modl License.html
# Adjustment of signatures.properties file for the rename
unzip mymodule.modl signatures.properties
# NOTE: using GNU sed below,
# if you're on macOS, `brew install gnu-sed`
# if you're on Linux/WSL2, change the below to `sed` instead of `gsed`
gsed -i 's|^/license.html|/License.html|' signatures.properties
I am resurrecting this. The manipulation of the .modl file after package is not a viable solution for a few of our customers and now they are asking for support for the recent versions of Ignition.
Here is the symptom and I would love some input as to what is causing it.
Our maven project has the file named "License.html"
The module.xml calls for "License.html" as described above.
I run these through a devOps pipeline so that it can get signed and versioned appropriately and thus we can't unzip it, rename, and zip it after the fact to meet our customers needs.
Anybody have any idea what is renaming the file?
How do I stop it BEFORE packaging?
I tried that, but on the package process, the module.xml file calls for License.html. I don't generate that. That happens automatically so it has the same problem. Is there a way to modify that file before packaging?
I am testing that now. To do that the "license.html" file has to be in the -build part of the project. Mine has always existed in the root of the project.