I am trying to make an organogram as show below.
Organogram example
On the basis of above organogram, I can configure users on each level, also I need this concept in Dashboards, reports and even in escalation alerts. I have to configure permissions as well. Low level user should not be transparent to above level user (i.e level 7 person can view details of level 6 but level 6 user can not view details for level 7 user). Same for escalation, if ticket SLA is not met by low level user (eg level 2 User) than his escalation should be triggered to his lead (eg level 3 user).
Note that I have multiple projects (Clients Onboarded) and users are from my organization not client. These hierarchy will be generic in all projects
I am using Jira Service Management Cloud Platform standard version
I am unable to find any workaround against this building customizable organogram and configure multiple actions on the basis of this. Also I have search for addons on Jira Market Place but unable to find one.
Related
I would like to have a user in Azure Devops that only has access to review the test plans sections in Azure Devops. I don't want the users to be able to go to the Board area and make modifications.
I've attempted to make users in the different types (Basic, Basic + test plan) but they always have access to edit items on the board. I tried creating them as a stakeholder and that didn't work either.
The last things I tried was creating a group and denying access to everything except project info and test plans, but this didn't work either.Picture of Project setting for test plan group
Is there any other approach I can use?
If a user has access level(stakeholder, basic or basic + test plan), the user will has access to view the Board.
You could refer to this doc about Access Level.
But you could set the permission for the users to prevent them from modifying the work item.
You could go to Project Settings -> Project configuration -> Select the Area -> Security.
You could deny the Edit work items in this node or View work items in this node .
As you know, in TFS 2013, from a permissions point of view, we have 3 licences available to us:
Stakeholder
Basic
Advanced
As far as I am aware, Advanced is the only way of accessing 'TEST' area (Test Case Management), however, is it possible to create 'custom' security licences as we would like to give access to certain users to the 'TEST' area but not have them access other areas where they can create other WITs or potentially modify open WITs - We just want them to be able to view and run Test Cases + create a BUG where required.
We are using TFS 2013 On Premise.
No, we cannot achieve that. We cannot custome the access levels to add/reduce the supported features for each level.
For TFS 2017 and earlier versions, you should assign the Advanced
level to those users for whom you've purchased the full Test feature
set.
Advanced access level include all Basic features. And TFS doesn't provide a more granular permissions settings. So we cannot restrict the users who in Advanced access level to only view and run Test Cases + create a BUG. That is contradictory. We can only set the user permissions based on the existing options.
Please see About access levels; Change access levels and Permissions and groups in VSTS and TFS for more information.
We are running TFS 2012. Our organization is currently creating new accounts for everyone as part of a migration.
What I know is that everyone will have two accounts listed in AD for a while:
OldDomain\DoeJ
NewDomain\DoeJ
This brings me to believe that SID will be different, among other things.
My question is, how would this affect our TFS environment? Will we lose any history associated with particular users? Will I have to go through each work item and reassign it to the new Windows account? Is there any way I can preserve this data?
Thanks
You could use Identities Command which lists or changes the security identifier (SID) of users and groups in your deployment of TFS. You might need to change or update the SID for users and groups in one of the following scenarios:
changing the domain of your deployment
changing from a workgroup to a domain or from a domain to a workgroup
migrating accounts across domains in Active Directory
Even though it's a powerful tool, but it has certain limitations. To help ensure a successful move, make sure that you understand the following requirements:
Once a user account is present in TFS, it cannot be removed or have another account mapped to it. For example, if you are moving
DomainA/UserA to DomainB/UserB, the Identities command would only
work to migrate the user if DomainB/UserB is not already present in
TFS.
Because the members of the local Administrators group are automatically added to TFS, make sure to remove any accounts that you
want migrated from that group before you change the domain or
environment.
Suggest you read up about this tutorial as part of planning your move. You could also take a look at this blog : Migrating TFS Server or Collection to another domain. Be careful do not add the user such as NewDomain\DoeJ to TFS first, after upgrade SID, the history will keep without any problem.
Moreover, TFS use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). You can force the job to run using any of these techniques.
How do I share artifacts (e.g diagram and docuement) across the entire project, not just at issue level at JIRA? Something like a common area for posting information.
A couple of possibilities spring to mind.
Firstly you could use the HipChat integration. Sending messages via comments to a team HipChat group.
Another option would be to create a generic JIRA user with an email address that is a mailing list for your team. That way you can use the Mentions functionality to inform everyone of something.
More about the mentions functionality here: Atlassian - Using Mentions
Use an Epic in the project
If you are using Jira Agile you can simply create an epic (called Documentation) and house all of your documents in the epic itself or group documentation by creating subtasks in the epic to essentially create "folders". To ensure the team is seeing any changes add them all to the "watchers" list.
Use a Confluence Space
If you have access to Jira Confluence, just create a project space and create or link your documents there. Another benefit of using confluence is you can make these documents available to external customers (no need of a Jira account). To ensure the team is seeing any changes add them all to the "watchers" list.
Creating a Space
https://confluence.atlassian.com/doc/create-a-space-139463.html
Use a Project Dashboard
Use a dashboard and ask that your team pay attention to this every day. Dashboards are a great way to propagate information to distributed teams.
Customizing the Dashboard
https://confluence.atlassian.com/jira/customizing-the-dashboard-185729498.html
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.