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

SiteSettings of type "RedirectAfter" are not saved correctly in a multi-lingual environment #4232

Closed
robsiera opened this issue Oct 21, 2020 · 21 comments · Fixed by #4851
Closed

Comments

@robsiera
Copy link
Contributor

robsiera commented Oct 21, 2020

Description of bug

Changing the Settings>Site Settings>RedirectAfterLogout in the default language works as expected. But fails in any other language of the portal.

Steps to reproduce

List the precise steps to reproduce the bug:
0. Make sure you have at least 2 languages active in your site, and you are in the default language part of the site

  1. Go to Settings>Site Settings>RedirectAfterLogout
  2. Select any page from the dropdown
  3. Scroll down and click 'Save'
  4. The TabId of the selected page is saved correctly in table PortalSettings with SettingName='Redirect_AfterLogin', with the correct CultureCode
  5. Now scroll to the top of the Settings>Site Settings page and click on another language in the language selector (top-right corner)
  6. repeat step 1,2 and 3

Current behavior

The TabId of the selected page is NOT saved correctly in table PortalSettings with SettingName='Redirect_AfterLogin'. CultureCode in not take into account.

The applies to all settings of this type:
RedirectAfterLoginTabId
RedirectAfterLoginTabName
RedirectAfterLogoutTabId
RedirectAfterLogoutTabName
RedirectAfterRegistrationTabId
RedirectAfterRegistrationTabName

Expected behavior

A new record should have been created in the PortalSettings, with the correct value and the correct Culture.

Additional context

Initial code analysis shows that to problem starts in GetDefaultPagesSettings() on lines 312/313
var portal = PortalController.Instance.GetPortal(pid, cultureCode);
var portalSettings = new PortalSettings(portal);
Here the PortalInfo variable 'portal' is correctly created (with the cultureInfo) and passed through to PortalSettings() constructor.
But clearly, down the line, the cultureInfo is not take into account when needed.

Affected version

  • [ X] 09.08.00 release candidate
  • [ X] 09.07.02 latest supported release
@Tychodewaard
Copy link
Contributor

Looks like related to #4261

@valadas
Copy link
Contributor

valadas commented Nov 10, 2020

There where some localization issues resolved in the last few days, can you try if you can reproduce using this custom build to check if those fixes maybe resolved this:

https://dev.azure.com/dotnet/DNN/_build/results?buildId=41521&view=artifacts&type=publishedArtifacts

@Tychodewaard
Copy link
Contributor

Tychodewaard commented Nov 10, 2020 via email

@valadas
Copy link
Contributor

valadas commented Nov 10, 2020

I am not sure what you mean, those aliases got added magically ?

@sleupold
Copy link
Contributor

@valadas: by design, DNN does add aliases for currently used alias (or primary alias) for all active languages, when a second language is added.

@valadas
Copy link
Contributor

valadas commented Nov 10, 2020

@sleupold I know, but what I don't understand is that in the setup @Tychodewaard mentions tjeps.com and then in the bug report it has handsondnn.nl the whole root domain is different.

@Tychodewaard Can you rewrite the steps to reproduce more clearly.

@Tychodewaard
Copy link
Contributor

@valadas I recorded my scenario (3,5 minutes) on https://www.youtube.com/watch?v=M5IyS1HQP58
@sleupold if I do something the wrong way, please feel free to elaborate :-)

@valadas
Copy link
Contributor

valadas commented Nov 11, 2020

Ok, I see, well, from the looks of it, your primary domain does not resolve and that's the main issue here.

@Tychodewaard
Copy link
Contributor

Nope, I don't think that's it.
If you create a new website, it is quite common to use a temp domain. Of course, I could change the primary for now but as soon as I go live, the whole thing stops working. I can not recall having these issues at this level before....
@Timo-Breumelhof I know we have had issues with certain setups in the past regarding multi language. That was not this scenario, right?

@Timo-Breumelhof
Copy link
Contributor

@Tychodewaard no, this was not it, but there are definitely redirect issues.
Unrelated I guess but for some client sites I had to use redirects web.config because the dnn redirect to the default portal alias did not work.
Anyway, I'm not sure that has anything to do with this issue logged by @robsiera

@robsiera
Copy link
Contributor Author

robsiera commented Nov 13, 2020

Idd @Timo-Breumelhof, imo none of the above is related to the issue I logged. Well, except for the fact that multi-lingual still does not seem to be a real priority.
My bug report was clear and simple. So why didn't I fix it myself? Well, I tried, but PortalSettings() has become a real rabbit hole. I do not want to hack a fix in there. There are serious conceptual problems with the current PortalSettings. Someone should take the lead in tackling these. I'm willing to share my experiences/views in a meeting, not in writing (because too inefficient).
Anyway, this bug report is a great little starter to follow the rabbit hole.

-- edited --
Notes to self in case of a meeting

  1. no distinction is made between PortalSettings to handle the current request and PortalSettings as a container of SettingsOfAPortal that we want to manage
  2. the Portalsettings is created in the (friendly/advanced) UrlProvider and then cached. If handling the url fails, that cache does not exist and then hacks are all over the place to 'fix' that.
  3. PortalSettings should be immutable. But instead it is sometimes modified to hack in a fix.

PortalSettings an Alias handling are closely related. That is why multi-lingual issues are often related to the PortalSettings rabbit hole.

@valadas
Copy link
Contributor

valadas commented Nov 15, 2020

Well before digging too deep into this, is it not an expected behavior (by design) that it actually uses the primary alias ?

@Tychodewaard
Copy link
Contributor

AFAIK, design is to listen to the aliasses that are in the alias settings. I can not recall encountering this issue before.

@Timo-Breumelhof
Copy link
Contributor

@valadas @Tychodewaard This issue is about Redirect_AfterLogin, not the portalalias... :-)

@stale
Copy link

stale bot commented Feb 14, 2021

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

@stale stale bot added the stale label Feb 14, 2021
@sachatrauwaen
Copy link
Contributor

I have seen the same issue on dnn 9.8.0

@stale stale bot removed the stale label Feb 15, 2021
@robsiera
Copy link
Contributor Author

@valadas This issue is easy to reproduce. You only need a multi-lingual site with two languages.

@stale
Copy link

stale bot commented Jun 2, 2021

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

@stale stale bot added the stale label Jun 2, 2021
@Tychodewaard
Copy link
Contributor

Tychodewaard commented Jun 2, 2021 via email

@stale stale bot removed the stale label Jun 2, 2021
@stale
Copy link

stale bot commented Sep 3, 2021

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

@valadas
Copy link
Contributor

valadas commented Sep 6, 2021

Cool, unstaled...

valadas added a commit to valadas/Dnn.Platform that referenced this issue Oct 3, 2021
…r localized sites.

The settings for the current portal alias local where returned to the UI instead of the requested language picked in the Page Settings editor. This caused an issue where you would get let's say the english tabs for a french site settings if the last page you happend to visit was english instead of french. The user would then save any setting and all the RedirectAfters would save the wrong thing for that locale.

Closes dnnsoftware#4232
Closes dnnsoftware#4260
@valadas valadas added this to the Future: Patch milestone Oct 4, 2021
bdukes pushed a commit that referenced this issue Oct 4, 2021
…r localized sites.

The settings for the current portal alias local where returned to the UI instead of the requested language picked in the Page Settings editor. This caused an issue where you would get let's say the english tabs for a french site settings if the last page you happend to visit was english instead of french. The user would then save any setting and all the RedirectAfters would save the wrong thing for that locale.

Closes #4232
Closes #4260
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants