We are using the Tuleap 7.0 for Project management. We have a new requirement that we need to provide access permission to specific users other than administrator role to create field's value with dependencies. For eg: We are having a field called category. Categories are SUV, Sedan, etc., Now we want to add a new category name called Wagon. But I do not want the administrator to add this each and every time instead I need to give permission to either project manager or to some other user roles to add the same. Also we have to add subcategories to corresponding categories. So either we need to provide access permission to specific user or a external interface other than tuleap to add the category and subcategory with field dependencies.
If we have to create an external interface, we do not know in which table the data and dependencies will be available. So kindly let us know is it possible to provide access permission to specific users for creating field's values and dependencies or else let us know detail on table structure that where the insertion of field values happen and the dependencies between fields will be available. Table schema will be more easier. Please help
It is possible for a group to be Trackers administrators but not fully Project administrators, maybe it answers your need but not sure. If you want to go this way, you have to choice: either you set it in the Trackers > administration > manage permissions for each project or in the global administration of the platform in admin > permissions delegation.
If you only want people to only be able to add values to this particular field, I don't think it is really possible. What you can do is to put an openlist instead of a simple list or even modify your trackers structure to have a tracker that represents all the category and set category by doing an artifact link. So to add a category simply submit a new artifact in the category tracker.
For the table schema I'm sorry but I don't have such document.
Related
Can you please help me on how will I able to filter the items of my list in Sharepoint depending on the user logged. The items that need to be shown will also depend to the team where the user belongs.
Thanks in advance!
So the image below shown is my list.
For example, User 1 and User 2 both have Full Control permission on my list. But User 1 should only see entries for DETE team. And User 2 should only see entries for Service Control Team.
Showing which items to be shown based on the current user can be done using out of the box SharePoint permission features.
The simplest and short answer is to set unique permissions on each item in your list to specific users or groups by breaking permission inheritance for the SharePoint list. Once the inheritance is broken, you can then specify your unique custom permissions on each item in your list. Then SharePoint will only show what is available for the user to see. If you are not familiar with security inheritance in SharePoint, then I suggest reading up on this topic as this is a foundation of SharePoint security.
To do this, use the "Shared With" -> "Advanced" options from the ellipsis menu on that item, then you can break permission inheritance on that item. (If you don't see the tool ribbon, then change the "List Experience" setting to classic via list settings -> advance settings -> list experience)
Then break the permission inheritance on the item:
Then you can grant permission to specific users or groups:
This can work okay for a small list but is a management nightmare for a large list.
One alternative is to use "Folders" and set the appropriate permissions on there instead. Then you can add/remove items from the folder for easier management to control which users can see what. There are pros and cons with this approach but this method has worked for me. What is nice is that you can display the items with or without folders using the Folder display options when creating a custom view.
Another solution is to create a custom workflow that will apply the proper item security permissions for you when an item is created in the list. This is good to automatically set the permissions for you without doing any work but does add maintenance duties if permissions needs changing such as new users, remove users or modifying users.
Setting up the proper security groups and users should give you the flexibility needed for your security requirements. It is always good practice to use groups when possible.
I'm working on an entity called 'Give Feedback'. I want to give create permission for all users and give read permission for that entity where Feedback provider or Manager of the Feedback receiver is current user. I have created a dynamic view for this. But I want to hide that entity from Advanced Find because it allows the current user to see all the records for that particular entity.
Is there any way to do remove or hide an entity from Advanced Find without removing read permission from security roles?
Any help would be much appreciated!
You need to set the right privileges for your custom entity.
If you set the Read privilege as User, with Advanced Find they will be able to see only their own records.
You can also change the property Searchable to No in Entity cutomizations.
Here is a simplistic summary of my module in Sitecore:
Module Folder
Venue Item (multiple)
Complete Bookings
Booking Item (multiple)
Incomplete Bookings
Booking Item (multiple)
There are many venue item and each have two folders underneath for complete/incomplete bookings which in turn have many booking items underneath them.
I'm setting up workflow roles and need to craft three roles:
Venue Editing
Venue Approving
Booking Managing
These are all easy to setup and secure the correct create/write/delete rights but my issue is that I have, per requirement, disabled inherent read access to the Complete/Incomplete folders as most Sitecore users should not have access to that information. I need to give one specific role read access to these folders and I'm not 100% on how to utilise (is possible) standard values to implement the persmissions.
I can't go into security editor and give each specific complete/incomplete folder read access as the venues will be created/deleted on an ongoing basis. Standard values doesn't seem to copy over its security settings to items instantiated from it. Am I correct in believing this?
Is my only option to set security settings via an event handler or is there a simpler way?
Thanks to jammykam for his helpful comment.
I was going in that direction at first but had forgotten that the permissions aren't retroactively applied to existing items so my test items indicated it wasn't working properly at first.
All sorted now.
I want to extend the security role entity to include some custom permissions relating to my business.
For instance, I might want to add things like 'Can approve an order of up to X $' or 'can update leads whose name begins with Y' (just some examples, of course).
I will then use these permissions in workflows, plugins and iframes which I will develop.
I haven't found a good way to do it- as far as I can tell, the security role entity is not customizable, so I can't add any fields to it.
I thought about creating a custom entity Role exstension which will hold this data for me and will have a 1:1 relationship with security role. However, I haven't been able to find a way to create a relationship with the role entity.
Anyone has any thoughts?
You are right you cannot extend the security role entity. I would recommend setting up a new entity called “Role Extension” (as you mentioned) and relating it to either a user directly or a team with a N:N relationship type. You could then use the built in CRM subgrids or a small Silverlight part to manage the roles
I think you can implement this kind of functionality quite nicely with plugins. Using plugins embeds the rules into the pipeline and ensures if you are using the SDK, they will be implemented.
e.g. enforce rule that only users with Role 'My Custom Sales Role' can approve order of more than 5 products
Create plugin that runs on order status change
Detect if quantity is > 5
If not, carryon
If so, get executing user guid
Retrieve user roles
Check for 'My Custom Sales Role'
Allow action if exists, if not throw exception 'You do not have permissions blah blah'
This keeps your rules in one place (a single library can encapsulate all rules). It does depend a bit on how many you have, but keeping them in the pipeline sounds like a reasonable approach to me.
Is there a way to limit the "edit item" permission in WSS 3.0 to only allow a user to edit his own documents or list items? We need the ability for a user to edit only documents/list items he creates - NOT items that someone else created. So, essentially we need a sub-set of the EDIT permission as well as ADD.
Is this possible in Windows Sharepoint Services 3.0? Is there a way to create custom permissions in code or a feature?
WSS has a basic UI for setting item-level permission on list items, but they hide that from the UI for document libraries. If you go into Settings->List Settings->Avanced settings for a list, you'll see the options to do pretty much what you're asking for. However, on document libraries, that UI is not available. The settings it drives, though are avaiable via the object model.
You could set those same properties for a document library like this:
SPDocumentLibrary onlyOwnLib = theWeb.Lists["DocLibName"]
onlyOwnLib.WriteSecurity = 2;
onlyOwnLib.Update();
And that should about do it. However, apparently that doesn't really set permissions; it just controls what the user can do via the UI. If they had another interface to the library (like via WebDAV) or list (like via the web services), it wouldn't prevent them from editing items they didn't create. If you want true item-level permissions, I think you need to go the event handler route.
This post from Matt Morse explains it in more detail, and he even wrote a command line tool to set the property (plus the .ReadSecurity property) for lists and libraries.
If you added an event handler to the document list you should be able to limit edit rights on that item to the user that created the item.
I often have to copy documents from another system into a list in SharePoint, and in that case the edit rights will be assigned to the system user that transfered the document, unless you use the approach suggested by Kirk Liemohn here
Note that item level permissions on large numbers of documents increase the load on your SQL server quite a lot.
here is the solution for your request.
go to the list -> list settings -> Advanced Settings
you will see the section of
Read access: Specify which items users can read
All items
Only their own
Edit access: Specify which items users can edit
All items
Only their own
None
select the options based on requirement. that's it done..
wanna more click on http:// mastermoss.wordpress.com
This is an old question, however the problem still exists.
A way that has worked well for me in the past is to use a workflow to configure the permissions when the library item is added.
See http://www.sharepointusecases.com/index.php/2010/03/configure-item-level-permissions-for-document-libraries-part-2/ for details.
I believe that permissions like that can be created through the user interface. It depends on the scale and number of list items you have, but you could do one of two things. First (without having to create scripts) you could give everyone a custom "Read" permission access which would not allow them to do everything you can in in the Read permission but allow them to Add Items. Then on an item-by-item basis, click the item -> manage permissions -> (Give the specific user Contribute permissions on their document).
If you're creating a SharePoint list that this will not be practical, you can create a script to traverse through all items, and will verify the user has contribute permissions (otherwise it will set the contribute permission to that user).
Additionally, you could just give each person their own folder.
Give everyone read permissions on the SharePoint list/document library, but give each person full control privileges over their own folder. This will allow everyone to read everything in a list, but create/edit their own documents.
If you want the 'Only their own' permission on a document library, it isn't there out of the box. But I've created a solution at CodePlex that adds this for Document Libraries - check it out at http://moresharepoint.codeplex.com.