I am looking for a way to change workitem's reason field without changing work item state.
Reason field acts something like a "sub-state" field. I am adding some new values to this list but it is field recognized by TFS itself and it will not allow me to change the value of the reason field without changing state.
Naturally switching to another state and switching back just for changing the reason field is not cool.
Is there a way to do this?
Reason is set up in the work item definition to be a documentation for "why" the state changed. That's why you can't edit it without changing state. If you really wanted to change this, you could edit the work item definition to remove the state-change logic, but I wouldn't recommend this unless you are totally sure what you're doing.
If you find yourself needing to change this value without a state change on a regular basis, you may be trying to use the field incorrectly. You might want to consider setting up a different field with appropriate "reason" codes so that you can change them as necessary without worrying about state.
Related
I have a custom field in Jira and I want to set the value on the field to match the current user.
This seems as though it should be fairly easy, but it has stumped me. I have trawled for information and have been led to using post functions.
Post functions don't seem to actually pre-set the value of fields on the create issue screen unfortunately? I am able to set a value which appears on the issue once it is created using a post function but I cant seem to find a way to set the value on the form itself.
Is this possible?
There is Default Values for 'Create Issue' screen plugin which seems to be doing exactly what you want.
My program flow requires that I first set the value of a select option in the Viewmodel and then I load the available options into the Viewmodel. This causes problems, typically the first available option will be seen in the selection list after this, while the selected option value stays at the specified value.
I was hoping that setting the new "valueAllowUnset" would help, but instead my page becomes unresponsive when using it.
Therefore I currently set the original value again after loading the options. Strangely, this only works when I set the value, set a different value and then set the value again, e.g.
self.data()[field](orgValue);
self.data()[field]({});
self.data()[field](orgValue);
(I store values for multiple selection lists in the self.data observable and access them with the property index "field".)
I tried to strip this down to a simple JSFiddle (http://jsfiddle.net/timvdh/HN6DE/), but the behavior does not show there, although the example pretty much resembles my actual application. However, I am using about 30 select lists there.
So I was hoping, that someone can make an educated guess about what goes wrong in my application, I am hoping that the fact that I have to set the original value three times maybe gives a clue.
EDIT: This fiddle demonstrates, that setting the selected option before and after filling the options list does work with "valueAllowUnset": http://jsfiddle.net/timvdh/HT5Tp/
I am using JQuery Mobile with knockout.js and that caused the problem (sorry I did not even think about JQM being the problem in the first place). I am now setting the option before filling the list and after filling the list I call
$("#selectmenuID").selectmenu("refresh");
to display the option.
The hanging browser was not caused by knockout, there are additional subscriptions to the selectmenus in my app. "valueAllowUnset" changed the behavior of the selectmenus and triggered loops caused by problems in my code.
I have a custom list. Each item in the list has 39 fields/columns that need to be filled out and a 40th field that gets filled out by a separate workflow.
I have another workflow that I need to trigger if any of the fields change EXCEPT for one.
Why? Because that field has a custom ID# in it and that field gets populated AFTER the form is submitted. Therefore, there will ALWAYS be a change in the list item. Thus, I need a workflow to trigger when any fields change EXCEPT the one w/ the custom ID#.
Any ideas? Thank you.
No one has been able to answer this but I figured it out myself.
I'm including the answer here in case anyone else ever comes across this and finds it helpful:
Create a new field that you will hide from the your SP list and from NewForm.aspx, EditForm.aspx, and DispForm.aspx.
Using jQuery, populate that hidden field as such: $(":input[Title='fieldName']").val("1");
The using an SPD workflow, check to see if that field = 1. If so, run the workflow. AND at the end of that workflow set the field to 0 - that's important.
We have a few bugs and change requests which have a complicated iteration path. This results in people coming over the team to ask 'Where do we raise items' a lot.
As you can't set a default value for the iteration path in TFS 2010 we think the best solution would be to add a string of text under the field which we can manually update every 7 weeks with the correct area to raise items in.
However TFS doesn't seem to allow just a line of text on its work items as a control. Is there a way to add a line of display text i.e. Not a field you edit, but just to inform those writing the items?
Please note that it needs to be visible at all times, using the tooltip 'help text' field on a control is not enough in this case.
You can use the LabelControl for this purpose.
You can not have a default in the work item for the iteration path, but what you can do is making use or the template url in web access or the work item templates in the power tools to create a work item that is prepopulated with values.
What about a custom field with a display control in read-only? You can give a default value to the field and the "read-only" control prevent other to change it.
Once work items in a particular workflow reach a "tested/resolved" end state, I don't want them to be editable. I could enter Field restrictions on the end state for every field that exists, but that's a pain and doesn't easily support the addition of future fields. Is there an easier way?
Thanks!
Alas, I don't think there is an "out of the box" way to do this except for using the "when" clause on each of the fields or adding it to the state transitions to "tested/resolved" (as you have indicated).