How to create a rule to skip transitions or choose other ones by specific field volume?
I've created a custom workflow for Item and there are a lot of States \ Fields inside. Some States have to be skipped by Fields volumes but i can't create another Item because of general restriction.
You could not change a state based on filed rules. You could also not able to skip transitions by specific field volume.
For System fields, there is some restriction for them. Refer to this link for details:
System fields have System.Name reference names, for example
System.Title and System.State. TFS restricts customization of
these fields, except for these instances:
Transitions define the valid progressions and regressions between states. Users can specify only those states that are valid based on the transitions that you define for the current state.
In the other word, Transitions tell the TFS which state can be followed by the current one.
A transition always has a from and to state. You could not ignore or skip the transition and select a totally different state. It's not available at present.
For more details of this related concept, you could take a look at our official tutorial here-- Workflow design guidelines
Related
Is there is a possibility in TFS 2013 where a particular work item like Bug an d Change Request has to be created and closed by Testing team and task by developers.
No, we cannot achieve that as the requirements conflict each other.
You can set the permission Edit work items in this node for a
specific user group on an specific Area. But it applies to all the
work item types.
You can customize work tracking experience for restricting access to
work items:
For example, you can prevent the majority of project contributors
from creating the work items by adding WITs to the Hidden Categories
group. You can create a hyperlink to a template that opens
the work item form and share that link with those team members who
you do want to create them. But you cannot prevent other team members
closing the work items.
You can restrict access to work tracking objects in one of two ways:
By adding WITs to the Hidden Categories group, you can prevent the majority of project contributors from creating them. You can create a hyperlink to a template that opens the work item form and share that link with those team members who you do want to create them.
Set a condition field rule, a condition-based field rule or a combination of the two that applies to a group. You can restrict changes from being made to a field by specifying a qualifying rule and making it apply for a specific group.
Conditional rules can include CANNOTLOSEVALUE, EMPTY,
FROZEN, NOTSAMEAS, READONLY, and REQUIRED elements.
For more information about how to customize WITs, see Modify or add a
custom work item type (WIT).
We use TFS2013 on premise. A request came up that when using Web Access, some members with Stakeholder access should only have limited rights when opening work items.
They should be able to edit Description, Acceptance Criteria, etc fields, but others should be read-only, such as Iteration, State, etc.
The only option I saw was about tags Create tag definition option under
Security >> Permissions, but that's not enough for me.
One idea was Customizing a process template, but this seems to be thin ice as our team doesn't have any experience with it and the things to avoid list is quite long.
The best workaround approach so far is to reference the TFS ClientLibrary from Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\ and create a custom website which implements only the required features (for example when opening a work item, State would be a Label instead of a DropDownList).
The drawback of this solution is that it would keep the whole WebAccess portal hidden, including its nice features.
So my question in short: is there a way to make certain fields read-only on the work item form for stakeholder members?
UPDATE
Eventually I went towards Template Customization using TFS Power Tools 2013. Now I have to following problem:
Applying rules for certain fields work just fine, but in case the field type is TreePath, saving the template gives the following error
TF26062: Rule '< READONLY for="[Global]\Stakeholders" />' is not
supported for the field 'System.AreaPath'.
There were validation errors. Continuing to save may cause the file to
become unloadable, do you want to continue?
According to this answer from 2009: "there are some particular fields which can't be applied rules for"
Any suggestions how to go on?
You can choose the work item types to make some fields read only.
You will never need to be careful to not mark field read only that are needed for adding items. That would include area and iteration. Use witadmin.exe to export the desired work item and add read only clauses only for those in the stakeholder group.
You would be better with a permissive model. Allow everything and tell them what bout to change. Then have an alert for changes to those fields by stakeholders.
I would like to customize a Work Item Type in TFS to automatically set the Assignee to a particular role. For example (to compare to another Issue Tracker), in JIRA the default Assignee is the Project Lead (so that any ticket not otherwise assigned, gets automatically assigned to whatever person is designated in the role of Project Lead). Can I do something similar in TFS?
So, I realize that one difference between JIRA and TFS is that TFS doesn't (to my knowledge) have the concept of "Roles". The closest thing to that is "Groups", but unlike Roles, Groups can have multiple people (which may be the restricting factor in this problem). I know how to configure a TFS Work Item so that only a certain Group gets listed in the "Assign To" field, but I would like to go a step farther, if possible, and create a custom Group with just one member (e.g., "Issue Guru") and then set up the work item to get automatically assigned to that person.
I'm trying to replicate the Jira functionality here, and maybe there is just no good way to do it in the TFS framework. Any suggestions?
There's a Step by Step Guide on Ivan Fioravanti's Blog for enabling it.
If you are unfamiliar with customising Work Item Types, have a look at the following links (stolen from Grant Holliday's blog).
I never tried this in production but here is something I tried quickly and it seems like it could work.
You can set the default value to a Group by editing work item template in template editor.
Just select Assigned to field and add a DEFAULT rule like shown in the image below.
This will also require you to create one or more groups (one global or maybe one per project). Once you set this up you won’t have to make any updates in the future but only manage people who are in the groups.
I am new to JIRA.
Can somebody explain to me the meaning of the different schemes in JIRA; like issue security scheme, notification scheme and so on?
Helpful online resources are also highly appreciated.
A notification scheme maps email notifications to various events. For example: "When a defect is assigned, send an email to the assignee."
A Field Configuration Scheme maps Field Configurations to issue types.
A Screen Scheme allows you to choose which Screen will be shown to a JIRA user when they perform a particular issue operation.
An Issue Type Screen Scheme associates a Screen Scheme with issue types,
An Issue Security Scheme determines who can and cannot see issues.
A Field Layout Scheme allows you to configure which fields are visible and/or required fields for a given issue type on a per project basis.
For more details, check the Jira documentation.
I really appreciate the detailed explanations available at "The Grey Blog":
http://thegreyblog.blogspot.com/2010/11/atlassian-jira-configuration-tutorial.html
Most parts of JIRA configuration can be set up differently for different projects. Some things, like custom fields, can be also set up differently for any pair of (project, issue type).
The schemes are the means to configure these per-project/per-type configuration pieces, with probably reuse of one configuration among different projects.
For example, issue security feature allows you to set up options for Security Level field and limit issue visibility to certain users based on the value of that field. Issue Security Scheme contains definitions of those options and how they limit issue visibility.
So you first configure Issue Security Scheme (may be more than one) to define that piece of configuration, and then you can assign each project one of the available Issue Security Schemes (or neither one), thus applying those pieces of config to the issues in that projects.
Jira enables flexibility to customize issue types, fields, workflows, screens, permissions, security and notifications through schemes. You can create, assign and reuse these schemes to your projects based on your needs. These schemes are assigned to project's related schemes like plug and play.
Notification scheme -- You can configure notifications like email for the issues you create or issues assigned to you and any change in status
Field Configuration scheme -- Scheme used to configure fields.. You can set based on project. You can add more fields and add to particular scheme. You can even set restrictions (lets say if it is mandatory field or not)
Permissions scheme -- Used to set permissions for the project. You can name like Admin or general user and give what they can do
Screen scheme -- Used to add fields for a particular screen.
While others answered most of the points, I would like to throw some light on Issue Security Scheme.
This is the most versatile scheme where you can restrict accessing certain issues by the security level user has.
With combination of the permission groups and issue security features, you can do almost anything in Jira from a workflow point of view.
Well schemes are sort of mapping entities.
They contain the units, like workflows,screens,issue types.
Schemes will define how a project decides which unit to use for which issue/operation.
This is of course a high level explanation.
Best bet is to start experimenting with 1 scheme, let's say screen scheme. Once you get the hang of the scheme entity, every other scheme will become understandable.
I have a Comment model in my app but am encountering a lot of problematic postings that I have to remove manually.
What I want to do is add a "flag for moderator attention" feature so that users of the app have the ability to remove a comment from view without my need to review all content in the app.
I'm thinking that after a comment has been flagged three times, I will remove it from view automatically and then when I have a chance to review these postings I will decide whether to allow them or permanently remove them from view.
What I'm having trouble with is how to implement this.
Should I have a separate table that records all items that have been flagged?
Or should I have a "flag count" field as part of the Comment table that keeps track of how many times a comment has been flagged?
A separate table would allow me to keep track of detailed information about the flagging actions - who is flagging, which IP they are flagging from, etc. This is what I'm leaning towards.
But perhaps a gem or plugin already exists that does this type of thing?
I don't know of any plugin. I like the solution you are leaning towards.
If you want to hide the comment after three flaggings have been created for it, you need to keep track of who created them, so people can flag just once.
I'd create a flag resource (which can hold any kind of flags your users can assign to particular comment), then a flagging resource which connects flags with comments and holds information about the entity which is responsible for flagging (which could be a user or a user represented by IP).
Every comment will then have many flaggings.
You can use state machine to change the status of a comment to "to_be_revised" or something similar after three flaggings have been added. State machine (aasm_state_machine or the one which is now incorporated directly into Rails) will also provide you with named_scopes for groups of comments with the same state.
After revision, you can set the state to "published" again and delete all the flaggings or to "unpublishable" and so hide it forever.
Perhaps the acts-as-flaggable plugin would work.