I have created a custom list with work flow associated with that. The workflow takes the item through different levels of approval.
My workflow scenario is like say an initiator add an item, which will go to manager for approval. When the manager approves, few columns in the current list will get updated. On manager approval it will be forwarded to head of department. Again when the Dept head takes an action, the column values of the list get updated. For all these users i have set Contribute permission. But the problem is that an item started by an initiator should not be editable or deleted by other users using the pull down menu that appears for each item. Only the owner of the item and manager should have permission to edit it using the pull down menu. When I tried changing the edit access for the item through Advance settings-->Item level permission --Edit access being set to "Only their own" while manager or dept head approving I get an access denied error message.
Can any one please suggest me what is the work around for this?
Welcome to the not-perfect world of Sharepoint Item level permissions...
You will not get far with Sharepoint 2007 standard stuff, because what you need is a Workflow with Impersonation - why do you need it?
You want to set item level permissions depending on the state your workflow is in. You can only change permissions when you have the right to do so - Workflows run as the user who started the workflow, so your user would need the right to change permissions -> You don't want every user to have that. So there is this thing called "impersonation" (which comes as an activity with Sharepoint 2010). Impersonation you can only achieve using a custom activity with SHarepoint 2007.
Once your Workflow is running under an elevated account, you can change permissions for the Current item easily, i.e. give contribute permission to someone and retract read permission from someone else.
There is a good article on how to implement item level permissions for Workflows and Sharepoint 2007 here:
Custom Activity Workflow for implementing Item Level Security in SharePoint Designer 2007 (sorry coding involved)
If you really don't want to code there are some useful projects on Codeplex:
Useful Sharepoint Designer Custom Workflow Activities (in particular "Grant Permission on Item " Activity)
Please be aware that item-level permissions and large lists dont mix very well. It can cause some performance issues on the list.
Please take a closer look at the
http://technet.microsoft.com/en-us/library/cc262787.aspx
under
Security scope
1,000 per list
Type: Threshold
The maximum number of unique security scopes set for a list should not exceed 1,000.
A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to SharePoint Server. The members of an ACL for a scope can include Windows users, user accounts other than Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.
Related
I was asked to separate access to a particular Jira project by component. e.g. user "a" can see issues created for component "a", but not component "b". conversely, user "b" can see issues created for component "b", but not component "a".
I know that I can limit access to a particular project to one or more users, but I was unaware of a way to filter access to one or more users by component within a Jira project.
Is there any way to limit access to one or more people to a subset (less than all components) of a project?
I did a search for a Jira plugin that might offer this functionality, but did not find what I was looking for.
N/A
N/A
I don't know if that's possible by using a component (I don't think so), but there is an alternative approach which might be sufficient as well:
You can adjust the Browse Projects permission like this:
You can grant permission to a group custom field value. Then you could choose a custom group field (create one if not available) which will be evaluated on each issue. Then, if you create an issue and add a group to this custom field in that issue, only users from that group have access to view the issue. Take care that you remove the any logged in user setting for "Browse Projects", otherwise the group custom field does not have any effect. There is also a KB article here in Jira's documentation.
The first question is what are you trying to do? Why do you want to restrict who can view issues?
Jira has Issue Security Schemes that can do this based on setting the security level according to the component, or other fields. I'd use a custom create post function
But what happens when the component is changed? Now you have to restrict editing too.
I have two users who have Full Control permissions to their department sub-site on SharePoint. They also have Full Control to the Pages document library. The Pages doc library has distinct permission from the site itself, but those two users have Full Control on both as mentioned.
When they try to create a New Page it gives them an "Access Denied" error. I can duplicate this problem with my non-admin account as well.
What am I missing to give these users the ability to create new pages on their site?
Assuming that the user has been granted enough rights to create pages at site level in the first place but is still unable to do so even with Full Control, then there is a high possibility that the user DOES NOT have READ access to the Master Pages and page layouts library. Check the library permissions at the root site collection and grant them the specified permission level accordingly.
Hope that helps.
This is a applicable to SP10 and SP13
Thanks
Ismail
It could also be TaxonomyHiddenList.
You must paste it into your browser - you cannot navigate to it and it is at the site collection level..
http://yoursite/yoursitecollection/Lists/TaxonomyHiddenList
List Menu -> List Settings -> Permissions for this list -> Grant Permissions
Maybe it is possibly to do with the Web Feature called "Content Organiser" which is enabled and not used. If it is activated, de-activate it and test again. This feature will affect document libraries, not lists.
I have a site at http://moss/sites/Electronics/Laptop
I have given users contribute permission on laptop site but still when they try to edit the page they are getting access denied, I have checked the permission level and all permissions are fine bt still users are not able to edit page.
I gave them read permissions on Electronics site and now they are able to edit the pages. My question is why we need to give them read permission on the top level site? What we don't want users to go to the top level site at all and want them to have an access on subsite only? Any idea?
Thanks,
Does the user have any access to the child site before you granted access on the parent? If not, this is likely because you're using some reference to list data from the parent in the child. If the user has no access to the parent and the child is trying to access that data, it will fail and the user will get access denied regardless of their permissions on child.
If they had access but just couldn't edit, this could be a completely different problem but it isn't typical out-of-box behavior. I would still be suspicious that something from parent is being used in child to cause this contention.
I've just discovered this in my 2010 installation. User has rights on a library, but Limited Access at the site level. Granting them Contribute at the site level resolved the issue, but this causes a long list of other issues relating to security. That's an end-user\training issue I need to work on.
Just my $.02
I'm in the process of implementing a workflow in Sitecore, and for that I have setup several different users with roles, where the security for the roles dictates the workflow process (nothing unusual).
One of these roles is a "CMS Publisher", and its job is to be last in the review process and to publish the item once it is accepted. The problem is that in the Publish tab, there is no "Publish" button. I know that it is possible to Auto-Publish items once they get into a final state, but I would like for this role to have access to that button as well. I figured it's a security setting on a content item somewhere, but I've searched the core/master database to no avail and the sdn provides zero information on this.
Thank you for your time.
Make your "CMS Publisher" role a 'member of' the built in "Sitecore Client Publishing" role and see if the button shows up.
There is a setting the web.config file that will require the Sitecore Client Publishing role to have both read and write access in order to publish an item. This setting is Publishing.CheckSecurity.
You can read a full explanation here.
I've been reading some feature request-style threads in Atlassian's own JIRA install on how to disable (not remove) users in JIRA, and their suggested solution involves a series of UI actions. For the number of users that our organization supports, this needs to be automated with the rest of our employee account provisioning logic.
I've been looking in the JIRA database and found the membershipbase table, but simply removing records from here WHERE USER_NAME="$username" doesn't seem to have a completely successful outcome. When I go to the User Browser in the Administration section and look up that user, groups still appear for the user.
Does anyone have any experience with this that could point me in the right direction on any other tables I need to modify?
Thanks in advance,
-aj
Maybe you should take a look at Atlassian's Crowd. Even if you don't use SSO, it may help you to integrate with your existing infrastructure for handling authentication and authorization (i.e. groups) centrally. It also provides an administrative frontend that is designed for the corresponding tasks.
You could have a look at the EditUserGroups.setGroupsToLeave() method. As far as I remember, users need to be in the jira-users group to log in. So, if you remove this group from the user, it may be effectively what you need (not delete but deactive user acount).
If this does not help, I'd look into the source code of JIRA (which is available for all types of licenses afaik) to see which tables are modified by the above method.