Skip to content
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

Resolves a logging issue #3936

Merged
merged 2 commits into from
Jul 27, 2020
Merged

Conversation

valadas
Copy link
Contributor

@valadas valadas commented Jul 27, 2020

Closes #3906

Apparently some files where deleted as part of #3843 which caused the extra logging.

This PR brings those files back and also fixes stylecop warnings. Some class names had to be changed both for clarity and to respect the stylecop rule that the file name should match the class name. Because of that change, the dnn manifest was also changed so it all works with the new names.

Closes dnnsoftware#3906

Apparently some files where deleted as part of dnnsoftware#3843

This PR brings those files back and also fixes stylecop warnings. Some class names had to be changed both for clarity and to respect stylecop rule that the file name should match the class name. Because of that change, the dnn manifest was also changed so it all works with the new names.
@bdukes
Copy link
Contributor

bdukes commented Jul 27, 2020

Looks good to me. Thanks for tracking this down @valadas!

Was any functionality broken by these going missing? Do we even need these classes? I feel like it's a warning to look closer if we can lose a handful of classes and the only symptom is stuff filling the logs…

@valadas
Copy link
Contributor Author

valadas commented Jul 27, 2020

@bdukes Well, each of these controllers control a menu item, from the looks of it it controls the visibility per role and on some it injects settings that I guess trickle down to the frontend initialization code. Those controllers are defined in the manifest and the logging issue was caused by them being defined but missing and reflection was choking trying to find them. It looks like in the case of not being defined in the manifest, it defaults to show to hosts only, so I guess for those who don't do anything else, it would be safe to remove, I decided to keep them because this is a bit cryptic to many people (including me) and I though it safer to leave it set as it was to prevent a possible change elsewhere that would change that default behaviour and expose menu items to users that should not see them...

@bdukes
Copy link
Contributor

bdukes commented Jul 27, 2020

Yeah, in terms of this PR as a bug fix, just reverting this change is definitely the right approach.

I'm just wondering out loud if 1️⃣ this is not cryptic for anyone, and 2️⃣ if it's worth a closer look to see if this makes sense or not.

Copy link
Contributor

@david-poindexter david-poindexter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thanks for tracking these down @valadas - are there any "lessons learned" from the mass stylecop implementations? Or are we now beyond that and looking at more small chunks of manual implementations?

@david-poindexter david-poindexter added this to the 9.7.0 milestone Jul 27, 2020
@david-poindexter david-poindexter merged commit 63ea5cd into dnnsoftware:develop Jul 27, 2020
@valadas valadas deleted the issue-3906 branch April 14, 2022 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clean Install of DNN v9.06.02 throwing a lot of errors from PersonaBar MenuController
3 participants