I have created a very simple workflow in Sitecore 7.2 (rev. 140228) which follows the out-of-box sample workflow exactly the same except that saving a "Draft" item doesn't also automatically push the item into the review state for a certain role. I have applied this workflow to the standard values item on a base template via the Default workflow field.
Whenever a user (non-admin) creates an item derived from the inherited base template, that new item's initial state as defined by the workflow is appropriately set to "Draft". I can then run that item through the workflow to reach the "Done" state. Basically, the workflow seems to work as intended!
However, when the user hits edit to create a new version of the item, the item's history then shows that user's item history as having "Changed from ? to Draft".
I cannot determine how to set the initial state of a given item's version to something that will not result in a version's state intially being shown as "?" in the item history.
As an example: I can (wrongly, I believe) set the State field on the Standard Values item for my base template (which many other items inherit from) to the "Draft" state but, when I check the Standard Values for the item templates which inherit from that base template, they don't inherit that value in the State field.
I can set the State field in the Standard Values for an item template itself and new versions of that item still show "Changed from ? to Draft" when new versions are created.
Can anyone explain how to get new versions of items to indicate in history that they "Changed from Done to Draft"? Is there something here I am missing entirely?
I've tried the suggestion from Jay below and the result is the same:
I modified the workflow as suggested
I start an item through the workflow, and then just run it through to "Done"
Go to edit the item (which creates a new version) and I'm still getting "?"
Just to add to this from the permissions standpoint, the two roles I'm testing this workflow with literally have full access to the workflow across the board.
I've noted that workflow state names show "?" when a role's access to that state is restricted in various ways, but I'm at a loss when it comes to why things aren't showing up properly with permissions as they currently are.
I think jRobbins has the size of it. While it doesn't really make much sense from the standpoint of user understanding, I can see why the workflow state is showing up the way it is. I can only hope that Sitecore will look to provide a way of addressing this in a more simplistic manner in the future!
By design, the new version of your Item is created in the Initial State of its Template's Workflow, not the state of it's the previous version. Therefore you will not achieve your desired "Changed from Done to Draft" entry in the Item's history.
I agree that "Changed from ? to Draft" is not an accurate entry but I think you may have to live with it unless you want to write some custom code on the function that creates a new item version.
Additionally;
"As an example: I can (wrongly, I believe) set the State field on the Standard Values item for my base template."
You are correct, setting the State field of the Standard Value of the template actually enters that Standard Value Item into workflow itself. You should only be setting "Default workflow".
See this link for more info - http://sdn.sitecore.net/upload/sitecore6/workflow_cookbook_a4.pdf
In Sitecore's default workflow, the __OnSave command is in Draft state and __OnSave's next state is Draft again. In this case, item's version information is "? to Draft" because "Draft to Draft" doesn't make a sense.
I created a new workflow and make __OnSave command to reside in Approved (Done) state. This __OnSave command's next state is "Draft". So, you will see the item's version information as "Done to Draft"
Related
So, a project that I am working on requires the custom column/silo of 'ready' to indicate that the initial analysis has been done and it ready to be picked up as a development object. When I change the state of an user story to 'ready' it does not show in the appropriate column however when selecting another such as 'new' or 'active' it is displayed. Is there a word restriction on the use of 'ready' as a column (silo)?
Please make sure you have also configured the state mapping for your customized Ready column. Otherwise, if you change the state of work item it will not auto show in the appropriate column.
More detail about this you could take a look at our official tutorial Update Kanban column-to-State mappings
When we are doing the customization of a work item type in VSTS. Do we also have the ability to track the history of the customization itself?
For example, we are trying to find out when the start date field was added to our customized Bug work item type.
A field was not there in a previous Increment but we noticed it recently. Just want to find out if there is a date captured somewhere that tells us when it was added or who may have added it?
Unfortunately we cannot get the information from VSTS for now. No date or history included from the retrieved process information via REST API.
However there's already a user voice submitted here to suggest the feature to add Activity Log to VSTS to track user accesses, you can go and vote it up or submit a new one to suggest the feature again to achieve that is future release.
For now as a workaround we suggest that you can ask the team members to add corresponding comments in description area after completing the customization for the process... Thus you can track the history of the customization...
I'm trying to add a new state to the user story Work Item type in VSTS. To do this I follow the instructions outlined here:
https://www.visualstudio.com/en-gb/docs/work/process/customize-process-workflow
However, when I get the states page the "+ New state" option is greyed out and I cannot click on it. I am a member of the "Project Collection Administrators".
Can anyone tell me how to enable the "+ New state" button?
So VSO has this Hierarchy like there are Processes which can be considered as your SDLC ( Agile, CMMI and Scrum). These are System defined processes and we cannot edit them. And Each Process can have many number of Work Items associated with it. System level process cannot be edited meaning you cannot create, edit, create state for a system process. The work around is to create a Inherited Process with the Available System Processes, which will also inherit the Work Items. This inherited process can be edited (you can create, edit, create state for the work items available in this inherited process). So keep in mind while inheriting from any process, for which work work item you want to add state and create a inherited process from that parent process.
Please follow this link to create a inherited process : https://www.visualstudio.com/en-us/docs/work/process/manage-process
Also keep in mind that whatever project you create has to be based on the inherited process so that the changes that you make in the customization is available at the Work Item form level.
Hope this helps.
Thanks,
Bhadhri
This should be easy, but it looks like it isn't.
I should start by saying that while this is a 2013 workflow, I am doing a 2010 workflow instead, as it has things I need in it.
I set an initiation form parameter called Syndication. which is a simple Yes / No drop down list. As you know, as soon as the parameter is set, the workflow automatically creates a variable for that value.
So I created a field in my workflow tasks list also called Syndication, which is also a Yes / No choice field. Then I went into the workflow and set up an update item in this list, chose the workflow task list, choose the Syndication field, and then choose to update with the workflow variable Syndication.
Here it is:
image here
The issue is that when a user selects yes everything works fine, when a user selects no, however, the workflow simply gives am error occurred, and doesn't tell me what the error is.
Anything would be great.
I'm working on a project that's got a great JIRA setup and awesome buy-in of everyone for the agile development process. The issue I'm having is that tickets stack up in code review. I'd like to be able to see who code reviewed what, much like I can see who has closed out which tickets.
I know that metrics are there to be used for good and not evil, so I want to do this to ensure that people spending time code reviewing are properly credited instead of that time not being recognized at all.
Currently, everyone who does code review assigns themselves to the ticket (which is unassigned upon being placed into the "Ready for Review" workflow state), so at some point there is a record of them working on it. Is this a good way to track the reviewers and is there a way to get aggregate information this after the fact? If not, is there a better way of representing this information in JIRA?
Thanks!
A simple solution would be to add a custom field called 'Code Reviewer' of type select a user. You would be able to search on that and report on it.
You could workflow it so that when the issue is transitioned out of your 'Code Review' status a window pops up containing only the "Code Reviewer' custom field to be completed.
What you need to do:
Create a new custom field - this is done in the 'Issues' configuration menu. Ensure your custom field uses the 'select a user' type.
https://confluence.atlassian.com/display/JIRA/Adding+a+Custom+Field
Create a new Screen - this is also done in the 'Issues configuration menu. On your new screen you need to make sure that the only field that is visible is your new custom field.
https://confluence.atlassian.com/display/JIRA/Defining+a+Screen
Edit your workflow. Find the transition from out of 'Code Review' and associate it with your custom screen.
https://confluence.atlassian.com/display/JIRA/Configuring+Workflow
The result will be that when a user transitions out of 'Code Review' they will have the custom screen pop-up. They can then select the name of the person who did the code review and this will be populated in the custom field.