I am using DNN 7.4.1 Community Edition and I would like to have a specific security role ("Editors") to have the ability to edit the content of every module, but not be able to edit the settings of every module. I know this SO question addresses this, but the answers are quite outdated and I would like to see if there is any more recent knowledge related to this issue.
I believe DotNetNuke Professional edition is now called, EVOQ Content, and due to the specificity of my issue, I would rather not upgrade for one little piece of additional functionality (also might not be an option financially). However, upgrading would seem to allow me to have more freedom over permissions.
As far as Oliver Hine's Enhanced Permission Provider for DotNetNuke, it hasn't been updated for several years. I have installed this extension, however it seems to add more headaches. As soon as it is installed, entire pages are no longer visible for any users other than the administrator role. Even after adjusting page permissions to allow "All Users" to "View Page", all of the modules are still not visible. After fumbling around with individual module permissions, certain modules were visible for certain users only after ALL permissions were granted to that role. This extension would be perfect if it worked as described (and without setting tons of individual module permissions).
So, is there any method other than the ones mentioned above that allow me to prevent the "Editors" role from accessing module settings, but still allowing them to edit the module content?
Thank you kindly
There is a slightly newer version on github which you might have better luck with. I haven't had the time to fully test it but it's an improvement over what's on codeplex.
https://github.com/ohine/Dnn.Enhanced-Permissions-Provider
If you still run into issues, contact me on my website and I'll get things fixed up.
Unfortunately my answer on that other post still stands as the current solution. Though Oliver might show up here and provide some insight.
This can be achieved with DotNetNuke Professional (EVOQ) edition using the
extended granular permissions.
Related
We have a DNN site and I noticed on our home page that the dev tools show an error with an events.js file that is trying to call "analytics.tiktok.com". It is being blocked. I don't know if this is purposeful and I've searched our DNN modules code but haven't found an such reference.
The other devs can confirm they haven't added such code. I've searched the code folders for a file named events.js but haven't found one. I'm aware that DNN has large portions of it that are data driven but I don't know what tables to query to see if there's code that has that URL.
Is anyone aware if DNN or kendo controls has an references to tiktok?
It is definitely not part of DNN.
Another place to look for these calls are the skin (theme) controls in use, or the default.aspx. Anyway, if no one is aware of this stuff, I would check if you have a security hole (old Telerik libraries, unsafe passwords in FTP accounts...)
I would start by looking at the location in which that is embedded into the source of your webpage. Depending on where it is, that might help you track down "where" it is coming from.
It could be coming from inside source for a module, in the content of a module, in module settings, in a container, in a skin/theme, etc.
I am Currently working on DNN based website. I want to add new table for my custom module to keep record of login and registration info of profile. For that does anyone knows which fields are required for any table in DNN? I want to use database which I assigned at DNN installation. And how to retrieve data from table which I have created?
You should really go through the Module Development wiki for DNN, the Task Manager series will do you wonders for understanding DNN (ignore that it says it is for DNN5, it will work just fine for DNN7 as well)
http://www.dnnsoftware.com/wiki/page/module-development
There are no "fields" required by DNN when you add a table, as a developer you can choose what you want included.
Chris handled the table requirements, here is a little about accessing the database...
Using DAL2 to access your database in DNN is really easy. It helps you connect to the database and preform the CRUD operations. Follow the MyObject.cs and MyObjectRepository.cs model and you should be good to go.
for older dnn versions http://www.codeproject.com/Articles/12853/Creating-a-DotNetNuke-Module-For-Absolute-Beginner
Please check http://christoctemplate.codeplex.com/ for dnn 7+ module development
Besides Chris Hammond's tutorials and module template (IMHO, some of the best contributions ever to the DNN developer community), there are a couple of other extremely good tools to add to your DNN developer toolbox.
Mitchel Sellers' Professional DotNetNuke Module Programming book (http://www.amazon.com/Professional-DotNetNuke-Programming-Mitchel-Sellers/dp/0470171162)
Scott Wilkinson's series of tutorials on DNN Module Development DNN Hero. (www.dnnhero.com)
Note that neither of these are free, but are well worth having!
Agree with all above but for a quick example of how to use PetaPoco for your DAL, see this answer: https://stackoverflow.com/a/35749594/4574668
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Our organization is looking to put up a site utilizing DotNetNuke, and according to our consultant (who is less a .Net fan and more of a Joomla fan), there is 'anecotal evidence' that the Community version is crippled in a way that pretty much forces you to get Pro if you wish to have a reliable site.
I have serious doubts as to the validity of this claim, but just in case I would be very interested to hear if this is or is not the case, based on use of the product and it's community and professional versions.
Specifically, if there are bugs/issues/etc in the community version that are resolved only by upgrading to pro.
I apoligize in advance if I posted this on the wrong stack exchange, but figured this was the best bet ;)
I would definitely disagree with that assessment.
The only Pro feature that I can think of that might affect reliability is a different caching provider (which we've had more problems with than the standard caching provider). I believe it's the suggested provider for a web farm scenario, but in most typical scenarios it won't be a big issue.
The community edition is the same community edition that's been used in real sites for years, there's been no crippling to it since the introduction of the Pro version. The Pro version is just a number of custom extensions on top of the community edition, most of which are quite optional for everyday use a website.
The Edition Comparison on DotNetNuke.com shows the following inequalities:
Advanced Content Approval Workflows
Content approvals ensure any of your users impacted by a content change can approve updates before they go live. Workflow approvals can be configured in a top down hierarchy at the site, page, and module level. A business rules engine enables workflows with an unlimited number of states and reviewers
Granular Permissions
Page, module and folder level extended permissions provide granular security rights which allow you to precisely define which content contributors can edit which modules on each page.
Advanced Site Search
The search engine includes rich query syntax with support for Boolean searches, phrase searches, relevance searches, wild cards, fuzzy searches, and groupings. Includes a true web spider that is capable of indexing any site which removes the requirement to implement the ISearchable interface within modules.
Configuration Manager
A host user can manage the various configuration files that control run-time operation. Upload a Configuration Merge script which can be used to automate many of the more repetitive and complex configuration operations.
Content Staging
Content contributors and software engineers make all changes to your web site on a physically separate staging server. You push the staging site to production when all changes have been reviewed, tested and approved.
My Editable Pages
Links to all of the pages and modules in the site which a user has permission to Edit are displayed, allowing efficient page editing
Document Management
A complete document management solution which allows your organization to store, control and view documents online
Module Caching
A database caching provider for module content which stores module content in a centralized database for faster page loading without requiring web server processing.
Page Caching
Allows your site to save an entire page of rendered content to one of three different caching locations: memory, database or disk. Improves page delivery speed for site visitors.
Distributed Caching Provider
More efficient resource usage in large web farms
File Integrity Checking
Checks files in the installation and reports any inconsistencies which may impact website reliability
Health Monitoring
Pings your web site periodically to identify failures and will notify you of any problems. Also ensures the site stays in web server memory for faster visitor accessibility
Security Center
A host-level feature which dynamically loads a list of known security vulnerabilities affecting your version of DotNetNuke and provides you with navigational guidance to acquire the latest upgrade
Comprehensive Product Documentation
Includes more than 2,800 pages divided into User and Superuser Manuals
Online Knowledge Base
Provides guidance for DotNetNuke administrative tasks and answers to common technical questions
Impersonate User
A host-level feature that allows you to impersonate another user who is a member of your web site. Search for a user by name and then click an icon to assume their identity to view the site using the user’s permissions while keeping their password confidential.
Outside of the three caching items, I don't see anything in there that's more than icing on the cake. Also, having used many of those features, they aren't quite as impressive as they all sound, and the DNN community core isn't completely devoid of any similar features. Module caching, in particular, is available in the community edition, there's just another provider. Also, page caching is possible in the community edition, it just doesn't come with any page caching providers built-in.
Quite the opposite.
Disclosure: Scott Willhite, Director of Community Relations for DotNetNuke
There is absolutely NO limiting code in the DotNetNuke Community Edition, and I am quite proud of that fact. We have made a purposeful and, frankly, very challenging business decision to keep our Community Edition the base of all of our software. We engage in enhancement of the base Community Edition to produce Professional and Enterprise editions using the same extension points that are available to all developers. And we constantly add features and capability to the Community Edition which benefit all users of the platform. Any suggestion to the contrary is unfounded and misleading.
Some companies choose to limit their free editions (by number of users, number of content items, number of pages, etc). Some require branding that can't be removed in free editions. Others specifically use their free editions as "hooks", knowing that a customer of any size will be forced to upgrade if they want to continue using the product. None of these approaches is acceptable in a truly open source environment and none of them are in practice with DotNetNuke.
It is fair to say that we have resources working on proprietary extensions to distinguish our Professional and Enterprise edition offerings. But this is the same privilege we enable hundreds of thousands of others to enjoy who develop for or implement proprietary solutions using DotNetNuke. We are also customers of those extension points and so are constantly improving them for everyone's benefit because we don't just use them as marketing points, we base our companies products on them. Every release of DotNetNuke contains both substantial Community Edition as well as commercial edition enhancements.
To specifically answer your question... while there are no constraints within the Community Edition of DotNetNuke, and it is a highly functional application out of the box, it cannot address every need (no product can, all projects have unique requirements). This is why it is constructed with well defined extensions points and why there is such a vibrant open source and commercial ecosystem supporting it. So it is fair to say that the solution, out of the box, may not address all of your needs specifically? But between Professional & Enterprise options, 000's of commercial extensions on Snowcovered, 00's of open source options in the DotNetNuke Forge and myriad developers and integrators in the ecosystem (in addition to your own skills), I am confident that any need can be met in the way that makes the most sense for your or any application.
I too would disagree strongly. I've been working with DNN for years, well since version 3 and there is no great conspiracy to force CE users to upgrade to Pro. I've rolled out 100+ Community Edition sites (seriously, no exaggeration) and the ONLY PE sites I've worked on were usually government or educational institutions where they needed content staging or the benefits of the OpenDocument Library module. To me, it sounds much like you say - your consultant is letting his opinion of .Net vs. PHP flavor his recommendations.
I am working on my first DotNetNuke website and there is a requirement for all the custom module functionality I am developing to be available with JavaScript disabled.
However, when I create a module that contains a simple submit button, i.e.<input type="submit" />, DotNetNuke displays a critical error with JavaScript turned off but works as expected with JavaScript turned on.
When I attach to the running process using Visual Studio, the unhandled exception is thrown from admin/Skins/Nav.ascx.vb line 177. The inner exception message is "Invalid JSON primitive: ."
My research online only managed to turn up this forum post (Postbacks are not working when Javascript is disabled in the browser) that appears to be the same problem as mine, but no solution is provided.
Can anyone shed any light on this issue? Is it viable to be attempting to write non-JavaScript functionality in this version of DotNetNuke?
Update: it turns out that another website designed recently with Dot Net Nuke by the company I am working for is having the same problem with non-javascript postbacks when using DNN version 5.1.4 but it does not have the problem (i.e. it can postback without javascript) in DNN version 5.0.1.
So perhaps a hard dependency on javascript has been introduced at some point after version 5.0.1. We are investigating this possibility further and I will keep this question updated as we go. Obviously I still welcome anyone's input on the subject.
Update: i've started a thread on the Dot Net Nuke forums to see if I can get any help there. If any solutions come up I'll post them here. Trying to find official DNN stance on support for javascript disabled functionality
One of the developers in the office found a workaround to get postbacks working with javascript disabled. Unfortunately since he does not have a Stack Overflow account, I will try to translate his solution as best I can for those who are interested. Bottom line is postbacks with Javascript disabled is possible once you make a few changes to the Dot Net Nuke environment.
Step 1 - Change the menu module. In our case we used the Telerik RadMenu.
<dnn:NAV runat="server" id="dnnNAV" ProviderName="DNNMenuNavigationProvider" IndicateChildren="false" ControlOrientation="Horizontal" CSSControl="mainMenu" />
becomes
<dnn:RADMENU runat="server" id="dnnRADMENU" MaxLevel="2" EnablePageIcons="False" PagesToExclude="" ShowPath="True" />
Step 2 - Remove the actions and visibility modules.
<dnn:ACTIONS runat="server" id="dnnACTIONS" ProviderName="DNNMenuNavigationProvider" ExpandDepth="1" PopulateNodesFromClient="True" />
<dnn:VISIBILITY runat="server" id="dnnVISIBILITY" minicon="images/DNN-minus.gif" maxicon="images/DNN-plus.gif" />
Step 3 - Download the DNN source and make two changes in the LibraryUI\Utilities\ClientAPI.vb file.
Line 155:
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
becomes
If Not objButton.Page.IsPostBack Then
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
End If
Line 355:
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
becomes
If Not objPage.IsPostBack Then
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
End If
Step 4 - compile the Dot Net Nuke library.
Note: Also make sure you are not logged in as an admin or host, as the admin/host panel at the top of the page will also break if you attempt to postback with javascript disabled.
Hope this helps someone else. If you feel like I'm missing some important details, let me know and I'll try and fill in what's needed.
DotNetNuke relies heavily on JavaScript and I doubt there is a real easy way around it - at least considering you need to support all functionality. Perhaps you can clarify that?
The the bottom line here is that you're going to need to modify DotNetNuke to meet your needs. It certainly isn't impossible to get it working, but I would venture a guess that it just plain isn't worth it for most people.
If, as you said, you need to retain ALL functionality without using JavaScript, you're going to have a pretty substantial amount of work to do.
I'd suggest, to get started, you download the source package, set up a development environment on your local machine, turn off JavaScript in your browser and start taking notes. This will help to determine the level of effort involved.
I'm guessing you won't get a lot of responses out of this one (as the poster in the forum thread you linked to didn't) as very few people have sat down in front of DotNetNuke with this as a requirement.
Also, keep in mind that any time you're making substantial changes to the DotNetNuke framework, you're interfering with your ability to easily perform upgrades in the future. Just another thing to think about.
I believe that I've seen the leadership in DNN say that they've taken a hard dependency on JavaScript, and have no intention at this time of considering a non-JavaScript compatible scenario.
That being said, being able to do a simple postback shouldn't be too difficult to support. I would look around in the Client API area for the error that you're describing. A lot of the Client API code is in the DotNetNuke.WebUtility assembly, which is a separate download from CodePlex to get the source.
I'm fairly new to DNN. I need to spin up dozens of similarly skinned sites, all of which have to eventually call a web service that will allow users to submit information.
I want to find a module that will let me point it at said web service, then let me define the workflow (e.g. fill it out over multiple pages?) and select the controls (textbox, checkbox) to fill out a message to post to that web service.
I've seen things like Dynamic Forms and Enterprise Forms, but I cannot find any information as to whether this is possible.
Anyone know of a module or optional idea that will allow me to do this? Am I making something like this up? An absence of answers makes me think "I'll just build it..."
My experience with DNN modules is that they're rarely an exact fit for a particular technical issue. So I'd try the following
1) Email the people behind the tools you mention
2) Buy them anyway, with source, and learn the architecture of a well structured DNN addin - the time saved with more than repay the cost
3) Make your decision based on that knowledge.
Joshua,
I am not aware of any forms modules out there at this time that integrate to a web service.
However, you might want to look at potentially extending an existing module, and simply changing the persistance mechanism for it, rather than a whole custom solution.