Dnn.platform: Some host settings missing

[trouble2]

Description of problem

Tried to look up some values that I used to have in DNN 8, however they do not seem to have a place in DNN 9.

Description of solution

Add the missing (editable) fields back:

• HostTitle
• HostUrl
• HostEmail (See issue #2050)

• HostPortalId (used to be a dropdown with all the portals to set the 'default' portal)

• [x] 9.2.2

• [x] 9.2.1
• [x] 9.2
• [x] 9.1.1

[sleupold]

AFAIK they have been left out on purpose.
What are you using it for?

[valadas]

As you mention, the host email should be back in 9.3 for the rest, I must admit I never knew a use case for them, they should not be too hard to implement but I am also curious on where they would be used...

[jeremy-farrance]

I could be mistaken, but I do believe there are a few core notifications that do, or used to use, that HostEmail. At the very least, the Test SMTP send button did (send both to/from that address). I also believe there are situations where the HOST/instance level would need to communicate/notify someone other than the assigned Site Administrator.

[sleupold]

I am only aware of smtp test using it and maybe after creating a ite with a non-host admin.

[valadas]

For the host email , that is resolved.it will be in 9.3 I was mainly curious on a use case for the other items in this issue...

[sleupold]

AFAIR host name was used in admin notifications about site created, updated or deleted.

[sleupold]

host portal might have been used for hosting billing (deprecated in DNN 6)

[bdukes]

References to HostPortalID in this repo include:

• UrlRewriteBase.AutoAddAlias
• AdvancedUrlRewriter.Handle404OrException
• AdvancedUrlRewriter.IdentifyPortalAlias
• Globals.GetHostPortalSettings (this is only called as a fallback from Globals.GetPortalSettings())
• DotNetNuke.Providers.RadEditorProvider.UpgradeController.UpdateFileNameWithRoleId

[trouble2]

Well, as far as I can see it kind of fits in the DNN structure, with all the fallbacks, like:

• if you have a page skin, then use page skin
• else, if there is a portal skin, then use the portal skin
• else, if there is a host skin, then use host skin
  etc.

btw. if I look into the host settings table of DNN 9.2.1 I can still see the entries (HostEmail, HostTitle, HostURL, HostPortalId), so I thought....
If there is/are entries, and there used to be editable fields for them, then perhaps we should use them.
Or perhaps some people count on them for some use case....
We're working with multiple DNN installations, so it is kind of a nice feauture that you can actually name them...

[sleupold]

There is still a "HostPortal" -1, i.e. old Host menu pages get this ID.
HostPortalID was used for DNN site hosting in a single DNN installation, to specify the one site used to administrate client sites (including payment). It should not be used for URL rewriting or as fallback for site settings, neither in any provider.

[sleupold]

@trouble2 you may still name a site your hosting site, but this was just a label, AFAIR, like Host URL to be used as token in messages.

[trouble2]

Right, that might still be something...Aren't they used in some system messages?
[Host:Name].. etc. I'm not sure, but they still might be in there?

[sleupold]

@trouble2
Most of the system messages do not support TokenReplace, because they are older. Instead they are using [custom1], [custom2] etc. for up to 5 values supported. Without having a look into the source code,I am not sure, whether TokenReplace supports any of it.

[valadas]

@dnnsoftware/tag do we have agreement to bring the other settings (host email is already done) into the UI?

[marietteknap]

Pls also consider https://github.com/dnnsoftware/Dnn.Platform/issues/2753

[ohine]

I'd rather see us finish removing these settings and adjust the notifications to use the portal name vs the host title description.

[mitchelsellers]

I think the requirement and usage of a host title and email for distribution is a key feature to remove it we would need to follow the deprecation process as there is information disclosure risk if we just change it.

So I believe for now, adding the host title back makes sense

[ohine]

As a prompt command, yes I'd agree. But in the admin experience the were removed for a reason and the initial plan was to phase them out completely. If we continue adding in every feature that a small handful of people use, we're going to be quickly back into a settings nightmare.

[mitchelsellers]

This is a fundamental feature, the removal was not done with any thought.

The data aspects of this make a cutoff of this feature a risk. We can take this offline if needed but there are security implications of removing.

I don’t want cluttered settings. But we need to make sure the environment can be used with the features inside.

[ohine]

If you think it's needed to take the conversation offline, ping me anytime. I disagree however that their removal was done without any thought, everything in the personabar had quite a bit of design and planning. I recall multiple MVP meetings years ago with the research into various settings and layouts.

I think we need to just take a step back and really plan out where these settings should go, if anywhere, or if they should be fully removed in an upcoming version. They've been out of the platform for many releases and there is documentation on what features map where and which features were removed.

As @ashishpd mentioned around the page icons and recent suggested changes to the user management module. Maybe an advanced settings view would make more sense to handle these edge cases vs re-cluttering the basic interface where a large portion of the users do not require these additional settings.

[mitchelsellers]

There is a much bigger issue as well with settings being in the wrong location.

I’ll try to start a dialogue on thisbb

[ohine]

That is very true as well. I'm not a fan of mixing site and instance/host settings in the same tab/view.

[trouble2]

If you would need an appropriate place, there is a part in the persona bar called "Servers" which I think is an option for more 'host'-like settings.

[valadas]

There are many settings that where removed from the UI, kept in the database and their apis still exists and not deprecated, so yes, those where removed without much thinking. I say either we bring them back somewhere in the UI or if they are officially to be removed, we need to mark the apis obsolete, respect our deprecation policy and give at least some way to edit them without advanced knowledge until they are actually removed.

If those host settings do need to go away, maybe we could add a single setting to select the host portal, if set it uses the settings from that portal, if not, it returns empty strings or some default value that is appropriate.

[valadas]

We need to outline the plan for all host settings and maybe make this an RFC, but we are pushing this to Dnn 10 for now.

[stale[bot]]

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!

[sleupold]

can anyone please review and specify the really missing settings, thank you

[david-poindexter]

Can this issue be closed in favor of smaller, more specific, and actionable issues?

[stale[bot]]

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!

[jeremy-farrance]

Seems like this is a lot of words with not much left to do. The Host Email has a place in PB now. Maybe close this and IF there are items still needed, put in 1 issue per item. A good example might be, "Hey, bring back the Enable Popups setting" or something.

[david-poindexter]

Thank you all for the dialog. We are now closing this in favor of smaller more actionable issues.