I have a dnn site that allows users to have child portals. The child portals are either basic or advanced. The advanced portals is basically unrestricted. However the basic portals should be restricted to only being able to change the content provided to them but not being able to add any pages or modules. Is that possible? Is there a security module that will aid in that?
Your description of basic portal security is possible to implement in DNN's role based access control.
The role assigned to the users:
should not have page-level edit
permissions
should have edit
permissions to selected modules
The problem is how to conveniently assign these permissions to new pages.
I recommend creating template pages first with the correct permissions, and then copying new pages from these templates. It is also possible to make a helper application for this copying. DNN API and the IPortable interface help here, but my experience is that with 3rd party modules you'll often need to implement the copy functionality yourself.
You can hide the control panel (ribbon bar) from Module Editors who are not Page Editors. This can be done from the Admin - Site Settings:
Related
I'm currently working on migrating a big company's data from DropBox to SharePoint and i can't quite decide on how to structure the whole SharePoint environment.
So as you may know DropBox has an admin section where you add your members, groups and content to share and it is pretty straightforward on how to implement simple things and by that, i mean that you get your members on some groups and then you share specific folders (from your content) to that group directly.
As of SharePoint now, i found out that it has more or less the same functionality but it really gets pretty inconvenient on how to implement this. I created a new site, then i created my groups and added some users to them, then i created as many document libraries as my shared folders were on DropBox, i stopped inheritance from the site and added groups directly to the document libraries. All that, took me quite a while, more than 8 hours, for 30 document libraries and 20 groups mostly due to the back and forth i had to go through settings, permissions, libraries etc.
Would it be, let's say, more practical or rather make more sense to create a new site for every shared folder i have on DropBox and add members directly from the site's homepage?
What would you do for such a case?
Thanks in advance
PS. The migration tool that SharePoint admin center provides it comes pretty handy and it works good, but transfers data quite slowly.
TLDR: Use sites, not libraries, for different user groups.
SharePoint makes the following things easy:
Sharing a whole site (by inviting people as members (edit) or visiors (read))
Sharing a single file (with a person that you don't want to have access to the other stuff on the site)
SharePoint makes the following very hard:
sharing specific libraries with distinct groups of people. This requires a lot of setup work and is a maintenance nightmare. You also need to be an administrator of the each site and know where in the depth of the SharePoint settings you can find the switch to break permissions and invite other people to a library.
It is not recommended practice to share libraries like that.
In your scenario, you would be served better with individual team sites using O365 groups. Then add members via the home page sharing button. The site should be the permission boundaries and these permissions should not be broken for any site content.
If the need arises to break permissions for certain content, it's time to move that content to a separate site with its own membership groups.
Using O365 groups, any site membership can then be viewed, managed and audited in the SharePoint admin portal and the M365 admin portal. No SharePoint knowledge or SharPoint site access is required for admins to manage membership. Membership assignment can also be automated with various tools like PowerShell or Power Automate.
Users can see only the sites they have access to, and will not suffer the bad user experience of clicking a library, only to get an error message for "You do not have access".
I have created a separate module for creating and assigning users for site admin/owners. So I don't want to show the "Site Membership" option under Users tab for both Site admin and owner.
How can I hide the Site Membership option?
Is there any way that the permission or configuration will do the
required change? Or do I need to create the hook?
Any suggestions please?
Rather than changing the semantics of Liferay's built-in roles, rather introduce your own custom roles and define the permissions that you want them to have. Create a "site role", choose "Define Permissions" and add what you need.
From your comment I understand that you want to use Site Admin, just not with everything this role comes with. It sounds strange to me that you're demanding a certain solution and favor one that doesn't work, but so be it.
You can check if it's possible to remove some permissions from the "Site Admin" role, but I'd expect a very hard-to-maintain-system resulting from this. Liferay has no means of "maintaining only the users that a certain Administrator has created". What you can do is: An Organization Administrator can administer all users in the organizations they're administering. This might be another solution for you.
Or alternatively, implement your own UI and do your custom (non-Liferay-based) permission checks in it. This UI will then enable your custom admins to administer the users that the UI provides for them.
But if you're stuck to a certain solution, you might be out of luck. Give us more details of your problem and we might come up with a solution unless you insist that your solution is the way to go.
With Permissions, no you can't. You can't change the permissions of the LR default role by UI at least.
You might have to go with hook or ext. One other way around is to do it with the theme. You might have to hook into Liferay's control panel theme.
What are the minimum SharePoint 2010 permissions required to allow a user to personalize a web part page, allowing updates and adding web parts to the page but completely restrict the user modifying the shared version?
I initially copied the built-in “Read” permission level and added the “Manage Personal Views”, “Add/Remove Personal Web Parts” and “Update Personal Web Parts” permissions from the Personal Permissions group. This custom permission level was then applied to a user who then viewed a web part page created by the Administrator, which contained only a very simple prototype SharePoint web part. This web part contained a modifiable label which was edited using the “Miscellaneous” section from the Edit Web Part from the standard SharePoint chrome.
With the custom permission level applied the “Miscellaneous” option it is not available to the user upon personalizing the page and selecting Edit Web Part. The “Miscellaneous” option only becomes available to the user when the permission level is further modified to have the “Edit Items” from the List Permissions group. This has the undesired effect of allowing the user to be able to modify the shared version of the page.
Is what I’m trying to achieve even possible?
Many thanks
Check this out: http://akifkamalsyed.wordpress.com/2011/01/17/personalizable-web-part-custom-property-not-shown-for-users-with-contribute-permission-level/
It's probably because you don't have a safecontrol for the webpart with the attribute SafeAgainstScript
I am developing a sharepoint 2010 visual webpart that will show some sort of ajax content.
I have a property on the webpart for the refresh rate, but I want this property to be set only by an Administrator (or any specific group).
What is the best way to achieve this?
Thank you.
In our organization, everyone by default is granted "Read" permission to our SharePoint sites through an "All Employees" Active Directory group. This allows users to browse the pages, but not edit them; and if you can't edit a page, you can't edit any web parts on the page.
Those who should have elevated privileges are added to other AD groups (you could use SharePoint groups too), and those groups are granted appropriate permissions.
You could create a custom Toolpart. Take a look at this example for a tutorial on how to create one.
Overall, your general steps will be:
Create your custom Toolpart class inheriting from Microsoft.SharePoint.WebPartPages.ToolPart
In your custom Toolpart, override CreateChildControls, write the code to display your textbox as long as the current user has permission (based on whatever rules you choose, ex: SharePoint group).
In your webpart, override GetToolParts and add your custom ToolPart so that it shows up in the right hand side
Can i program custom base permission level? There are many available in SPBasePermissions like
UseRemoteAPIs Use SOAP, WebDAV, or Microsoft Office SharePoint Designer 2007 interfaces to access the Web site.
ViewFormPages View forms, views, and application pages, and enumerate lists.
ViewListItems View items in lists, documents in document libraries, and view Web discussion comments.
However i want to make a custom one, something like:
EditItemsAssignedToMe + ViewItemsAssignedToMe + view/edit items i created.
Still finding my way out to allow users view and edit items created by them or assigned to them.
OOTB you don't have the fine-grained control and can only assign a certain set of permissions as defined on technet and this blog article.
However programmatically you can create a new SPRoleDefinition and assign it the appropriate permissions based on the SPBasePermissions enumeration as per this blog article. You might also want to read this short guide on the basics of SPBasePermissions.
If you want to go even further though and emulate the OOTB behaviour with your own custom permission set try Implementing Custom Security Rights in SharePoint.