Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Looking back (is a good thing sometimes)Looking back (is a good thing sometimes)
Previous
 
Next
New Post
6/5/2006 8:17 AM
 
trouble2 wrote
  • For each role you define in DNN you can set specific rights. Since a host is a role, I think you should have the option to give role specific rights.

sorry, but you are wrong, hosts are determined by a specific flag and do not belog to roles.

trouble2 wrote

  • I do not think that multiportal scenarios should mean that some modules should be part of the core. I know modules which worl in multiportal environments but are still modules. So I don't think this is a very good reason to keep them a part of the core. I think you must have a clear definition of what is part of the core functionality and what is/should be considered a seperate function and should be in a seperate module. 

Please notice, that being part of the core is a question of responsibility for that module and depends on integration with the framework.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
6/5/2006 10:12 AM
 

I know hosts are determined by a flag, but how something works technically is not the issue. I'm sure you must agree that a host is a different role then an administrator. A host has different rights, a different scope of possibilities, etc. How would you define a role?!?!

I don't understand your second point. A module can have a certain level of integration with the framework. It doesn't really matter if it is a seperate (core) desktopmodule like text/html, announcements, links, etc. or if they are part of the core like lists, vendors, newsletter, etc. All I am saying is that I think it would be better to make a better seperation between the two. This will have benefits I think; what if I do not want a search engine on my website, and I don't want to have a newletter, and I don't use lists, etc. If they were modules, I could simply get rid of them. this would give users more control, it would give you a smaller core. And by seperating it, would allow for easier management of source code, upgrades, etc.

 
New Post
6/5/2006 10:15 AM
 

>Since DNN is opensource I do not think this will work. I think help should be managed on a local scale but with >support of (downloadable) resource files.

the online help system as it is now is workable for the 'community' type user. For those that value add or run on an intranet it does not work - what is needed and this must apply across the core modules and 3rd party modules is a system that allows the designer/administrator to change the url of the help server ie I run a help site for clients -each module in the DNN site (and I still use DNN2 - highly customised)  has its help url set in the host settings - the module help function simply calls that url with the friendly name of the module - if the help page is not found for that module then the default help is called - this may be the 3rd party url or the DNN help site.

This then gives the best of both worlds my customised help ( and the help url can be different for differing types of clients) or the off the shelf help.

systems such as this can only work if you can obtain the source of the 3rd party modules or a standard is set for PAs as far as help functions go.

The other area that I think is important is to allow sub administrator roles - ie content only administrators that do not have access to say the admin menu the delete tab/pages the recycle bin but can add/edit tabs and modules. As far as I can see this cannot be done using the existing roles ie if you can get access to the managetabs function then you can delete the tab - this also applies to modulesettings.

Probably what I am trying to state is that a lot of skill and knowledge is being put into the newer versions( and of course the older versions) and some whiz bang code is being used but maybe a little bit of thought into the real world day to day use of the package is needed now.

 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Looking back (is a good thing sometimes)Looking back (is a good thing sometimes)


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out