-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExtentHtmlReporter doesn't seem to respect JS config setting on 4.1.0 #105
Comments
Adjusted title because CSS actually does appear to import. This kinda ruins my theory about the "BasicFileReporter" changes since both CSS and JS are on the same configuration object (RichViewReporterConfiguration), so it's just the JS content that is being dropped. |
I 100% see the issue. The "Scripts" partial view that you have is pulling "JS" from MasterConfig, but the "RichViewReporterConfiguration" class is storing the value as "js". Since keys are case sensitive, either the "Scripts" partial view needs to switch to "js" or the "RichViewReporterConfiguration" class needs to store that key as "JS". |
@anshooarora tagging since it has been 3 days |
@btvanhooser This has been fixed in version 5 (currently in alpha). The default reporter is |
Previously when using 4.0.3, we were loading our custom JS to the config on the ExtentHtmlReporter via the "Config" property. When upgrading to 4.1.0 in an effort to take advantage of using .NetCore, it appears that something changed that prevents that from being properly set to use on the templates. I've tried the SPA and default views and both the Xml and in memory config options and they don't work. I have isolated the issue in the following repo where you can run the tests to see that the "Framework" tests (using 4.0.3) correctly load the custom JS regardless of input, while the "Core" tests (using 4.1.0) don't correctly load the custom JS.
https://github.com/btvanhooser/ExtentConfigIssue
I believe the culprit could be on "extentreports-dotnet-core/Reporter/BasicFileReporter.cs". It looks like there is a previously existing loop that was commented out on this release (lines 61-69) that previously handled some of the "ExtentHtmlReporterSettings"-specific properties, so that could explain why "DocumentTitle" and "ReportTitle" are still being respected, but the non-BasicFileConfiguration properties are not being included.
The text was updated successfully, but these errors were encountered: