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

Fix to settings saving in MVC modules #3756

Merged
merged 2 commits into from
May 12, 2020
Merged

Conversation

donker
Copy link
Contributor

@donker donker commented May 12, 2020

Fixes #3692

@mitchelsellers
Copy link
Contributor

@donker it looks like this broke a whole bunch of tests, can you review?

@bdukes
Copy link
Contributor

bdukes commented May 12, 2020

Looks like ModuleSettings needs to be mocked out for the tests now

@donker
Copy link
Contributor Author

donker commented May 12, 2020

You're right, Brian. It fails because there are no ModuleSettings on the mocked ModuleInfo. And since you can't just create them empty there is no easy fix. Or is there?

@bdukes
Copy link
Contributor

bdukes commented May 12, 2020

I've pushed a fix

@bdukes bdukes merged commit d5f45ce into dnnsoftware:develop May 12, 2020
@donker donker deleted the settingsfix branch May 13, 2020 09:37
valadas added a commit to valadas/Dnn.Platform that referenced this pull request Jul 14, 2023
One may have a settings class that includes a mix of HostSettings, PortalSettings, ModuleSettings and TabModuleSettings.

The previous mechanism had different cache keys for PortalId or TabModuleId, but that brough 2 problems:

1. It is possible to have the same number for a portalId and TabModuleId which would invalidate the wrong cache.
2. When reading settings using the GetSettings method overload that takes moduleInfo, it would get stale settings for all PortalSettings if it was saved also using moduleInfo overload.

I am on the fence about this PR, but it caches now using always portalId.

PROS: It fixed the issue at hand.

CONS: It clears the portal settings cache to be clear, not the whole portal settings cache but only the specifiec settings class type being requested. This is maybe a tiny tiny bit of a performance hit, but it's not like saving settings is something that gets hammerd.

So I believe the benifits here outweigh the drawbacks.

Closes dnnsoftware#5739

Possibly a different fix for the workaround in dnnsoftware#3756 but I don't have any MVC custom module to test that part...
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.

MVC style Settings control doesn't work
3 participants