LoggerSettingsController_Tests Test Failures #257
Comments
|
@starkguerraj thanks for reporting this! When you installed Nebula Logger in your org, did you use the option "install for all users"? Those 4 failing tests are using the profile 'Standard User', so I'm wondering if perhaps in your org, the 'Standard User' profile actually does have access to some of the logger metadata. Regardless, I think those tests could continue to be problematic in other orgs - I'll plan to move these outside of the core package, and instead, I'll only include them in the pipeline. This will let me ensure that those pass in a clean scratch org, and avoid failures in some orgs. |
|
The install was for all users. Sounds good, I had not made any changes to the standard profile after installing the unlocked package. If you wanted me to check just let me know where I could check that for you and I can confirm, my schema settings have restrict access to metadata types enabled and the customize application setting on the profile is disabled. Alternatively if you plan to move them for the reasons above that will resolve the issue. |
|
@starkguerraj thanks for confirming! I was able to reproduce the issue in a scratch org by installing it for all users - I think this will be an ongoing issue in any org that uses that option, so I think moving these tests to be outside of the package is probably best. It shouldn't cause any major issues with code coverage, and I'll continue running the tests in the GitHub pipeline to ensure that nothing breaks in the future. I'll get this fixed in the next release ( |
|
Sounds good. Thanks! |
…ies, and docs (#259) * Fixed #253 by adding a filter on NamespacePrefix when querying ApexClass - previously, the tests could have failed if an org had 2 classes with the same name (1 with, and 1 without a namespace) * Fixed #257 - Moved security check tests to a separate test class, under extra-tests directory * Fixed #256 by adding a few extra null/isBlank() checks * Shortened the label for the field LogEntry__c.TransactionEntryNumber__c * Moved 'streaming/paused' btn in logEntryEventStream.html * Moved constants to top of LogEntryBuilder * Shifted around the metadata for the Slack plugin to better match the core package's folder structure. This will make it easier to consolidate the folders in orgs that deploy the unpackaged metadata (instead of using the unlocked package) * Added missing @param tags for JSDoc in logger.js * Consolidated several top-level directories to all be under the directories `nebula-logger` and `config` * Renamed `content` folders to `images` * Updated package aliases in sfdx-project.json, moved apexdocs config files, consolidated apex & lwc coverage files into `test-coverage` directory * Readded some deprecated metadata to the managed-package folder, and added deploy action for generating a beta managed package version Currently, deprecating metadata isn't available for managed packages (unless you opt in to a pilot feature, and I have not done so yet) * Switched to new pwsh script create-and-install-package-version.ps1 for pipeline This version of the script is fully generic - the package alias, README path, and target username can be passed as parameters, and sfdx-project.json is then parsed for other details, like version number & path * Improved packaging process & pwsh scripts for the managed package, improved an integration test for Experience Cloud * Added --branch and --tag parameters to package creation pwsh scripts * Removed some old pwsh scripts, renamed a few others * Fixed `prepare` npm script to use npx sfdx * Regenerated a clean copy of package-lock.json * Removed jsconfig.json files * Added CODE_OF_CONDUCT.md, based on v2.0 of the Contributor Covenant
|
@starkguerraj v4.6.15 has been released, which includes a fix for these test failures. Thanks again! |
|
Appreciate it. |
Package Edition of Nebula Logger
Unlocked Package
Package Version of Nebula Logger
4.6.14
New Bug Summary
Getting some test errors when run from the Apex test execution page for LoggerSettingsController_Tests.
Deploying change sets and running the tests does not seem to trigger the failures, only when run from this view.
/lightning/setup/ApexTestQueue/home
The text was updated successfully, but these errors were encountered: