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.
Related
I have been converting access to Team projects using Active Directory groups.
I am a project collection admin and we host around 40 odd team projects.
On all the other proects everything is fine, I have been able to add all the AD groups I needed to the Various TFS groups that exist in a Team Project (Contributors, Readers etc).
When I come to the problem project I can see the add button, and I am able to search for and select the AD group I want, but when I click save, I see a red banner message with the text:
Unable to add members to this group.
Failed to resolve the specified groups to join.
You do not have sufficient permissions to add members to the following groups:
[Team Project]\Build Administrators
I have looked at the oi and all I can see around the time of the issue are activities reporting a 200 response.
I am looking at the api and the database to see what I can do but not sure where to start. I thought I might be able to see something about security but it is asking for a guid that I am not sure how to get hold of.
Looking at the database I thought there might be a security table, but not sure where to start.
I'm going to keep looking at what to do, so I am going to keep this updated
update 2019-03-27
We have a support call open with Microsoft, I still have issues managing the teams, but I have been able to update the team via the Apis, I even found a useful little CLI tool to help with the tasks I needed to do.
In my case, I was trying to add someone to a group that I was in - which I don't need since I'm a Project Administrator. Once I took myself out of the group, I was able to add others again.
Got the answer and the fix worked.
After a lot of back and forth, sending files and running some tfssecurity queries, they were able to determine the problem.
What I had done was add the domain User AD containing our project collection admin account in as a project reader, as the security on tfs works on a least level principle it was then applying a deny permision on my Project collection admin account, by simply removing the AD group from the reader level, which I was able to do, the ablity to manage the securities came back.
I havent been able to find the specific group that I belonged to that then set the deny, but there is no denying that removing the AD group from the reader level fixed the issue.
I am using Role Based Security in Jenkins.
All my jobs are private, require login for every permission, which is good. However, I'm adding a couple of jobs that I would like to expose to the public. I would like anyone to be able to discover and read one specific Jenkins "view" or "job".
So far, I'm unable to get this to work with Role Based Security, as it seems it doesn't have a concept of Anonymous access.
Is what I am trying to achieve possible with Role Based Security? If not, is there an alternative that I can explore that still allows me to keep certain jobs completely private (including read and discovery access), but others public?
I figured it out, but it wasn't intuitive, so I will leave the question up and list the steps to take here:
Navigate to the "Manage and Assign Roles" view
Add a new global role, "Public" for example
Add only the "Overall" "Read" permission, nothing else
Add a new Project Role with a relevant name and pattern that matches the job you want to filter for
Add the "Job" "Read" permission to the new Project Role
Navigate to the "Assign Roles" view
Add user/group "Anonymous" to global roles
Add Anonymous to the project role you created
I am using Jira in my company. I want to give permission for a user where he can log only bugs but couldn't see all the other communication. How can I do it?
You can create a project for bugs only, for example.
Then create a role, like "buglogger", and on permission schemas of each project, set permissions depending on a role.
On your new bug project, your new buglogger users, should have almost all permissions, and on the other projects none.
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.
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.