Site Settings not working after setup "PRIVACY" section on multi language (fa-ir , ar-sa)
Errors are listed in the screenshots section.
List the steps to reproduce the behavior:
Explain what the current result is.
Provide a clear and concise description of what you expected to happen.
Main error :
root/API/PersonaBar/SiteSettings/GetDefaultPagesSettings?portalId=0&cultureCode=fa-IR
error :
<Error>
<Message>An error has occurred.</Message>
<ExceptionMessage>String was not recognized as a valid DateTime.</ExceptionMessage>
<ExceptionType>System.FormatException</ExceptionType>
<StackTrace>
at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles) at DotNetNuke.Entities.Portals.PortalSettingsController.LoadPortalSettings(PortalSettings portalSettings) at DotNetNuke.Entities.Portals.PortalSettings.BuildPortalSettings(Int32 tabId, PortalInfo portal) at Dnn.PersonaBar.SiteSettings.Services.SiteSettingsController.GetDefaultPagesSettings(Nullable`1 portalId, String cultureCode)
</StackTrace>
</Error>
Add any other context about the bug that may be helpful for resolution.
Tested it out.
Totally break the admin area when I enable those settings.
I think this issue should be fixed in 9.4.1 milestone because it's a critical bug.
I did not have time to test this but assigning to 9.4.1 for now
A fix has been merged into the 9.4.1 release. This should fix the issue. If you see any more issues try resetting the consents using the button on the Site Settings screen while logged in with a locale that has access.
The core of the issue is the way the date is stored in SQL in the PortalSettings table (key = "DataConsentTermsLastChange"). This was done using a generic universal format. It will now be stored in a so-called round-trip format (more robust to storage and retrieval).
It impacted (as far as I can tell) only non-"Western" sites (i.e. ones with divergent calendars from the Gregorian that we use) under that locale.
It would really help @soheilkheiri and @Cloze if you could verify resolution of this issue in this RC:
https://github.com/dnnsoftware/Dnn.Platform/releases/tag/v9.4.1-rc1
@donker
I believe the errors is gone and the fix is working.
Thank you.
Most helpful comment
A fix has been merged into the 9.4.1 release. This should fix the issue. If you see any more issues try resetting the consents using the button on the Site Settings screen while logged in with a locale that has access.
The core of the issue is the way the date is stored in SQL in the PortalSettings table (key = "DataConsentTermsLastChange"). This was done using a generic universal format. It will now be stored in a so-called round-trip format (more robust to storage and retrieval).
It impacted (as far as I can tell) only non-"Western" sites (i.e. ones with divergent calendars from the Gregorian that we use) under that locale.