Is it possible to open up all possible states for a work item - essentially removing the state transitions?
I am hoping to use a tool outside of TFS for managing work items and would like to know if it's possible to simply allow all states at any time?
If you want to remove the transitions between work item, you need to customize the work flow.
You change the workflow to accomplish the following objectives:
Add or remove a state, reason, or transition.
Specify a value for field to be applied during a change in state,
reason, or transition..
Specify a custom ACTION to automate field assignments based on a
change in state, reason, or transition.
Detail steps to customize the workflow and more info about it, please refer this Modify or add a custom work item type (WIT) from MSDN.
Moreover, here is a 3rd party extension called TFS Work Item Manager which is an innovative team workload coordination platform that helps you manage your TFS work items in a much more efficient and intuitive way. You can also take a look at it.
Related
I am trying to build a UI with left side bar having filters and right side having actual filtered data.
For loading data into the dynamic part of the UI(right side), which approach is considered better in terms of code quality and app performance ?
Use sub routes (for dynamic part of the UI)
Use separate components that load their own data (for dynamic part of
the UI)
There is not a direct correct answer for that; you can use both ways but here is a few things to consider and in the end I generally prefer to use sub-routes due to the following:
Waiting for UI to load: In case you are using separate components to load their own data; then you need to handle the loading state of the components. What I mean is; if you simply use sub-routes; then model hooks (model, beforeModel, etc.) will wait for the promises to be solved before displaying the data. If you simply provide a loading template (see the guide for details) it will be displayed by default. In case you use components, you might need to deal with displaying an overlay/spinner to give a better UX.
Error Handling: Similarly like loading state management; Ember has already built in support for error handling during route hook methods. You will need to deal with that on your own if you prefer components to make the remote calls. (See guide for details)
Application State: Ember is SPA framework; it is common practice to synchronize application state with the URL. If you use sub-routes; you can simply make use of the query parameters (see the guide for details) and you will be able to share the URL with others and the application will load with the same state. It is a little bit trickier to do the same with components; you still need to use query parameters within the routes and pass the parameters to the components to do that.
Use of component hook methods: If you intend to use the components then you will most likely need to use component hook methods to open the application with default filter values. This means you will need to make some remote call to the server within one or more of init, willRender, didReceiveAttrs component hook methods. I personally do not like remote calling within those methods; because I feel like this should better be done within routes and data should be passed to the components; but this is my personal taste of coding that you should approach the case differently and this is perfectly fine.
Data down, actions up keeps components flexible
In your specific example, I'll propose a third option: separate components that emit actions, have their data loaded by the route's controller, and never manipulate their passed parameters directly in alignment with DDAU.
I would have one component, search-filter searchParams=searchParams onFilterChange=(action 'filterChanged'), for the search filter and another component that is search-results data=searchResults to display the data.
Let's look at the search filter first. Using actions provides you with maximum flexibility since the search filter simply emits some sort of search object on change. Your controller action would look like:
actions: {
filterChanged(searchParams){
this.set('searchParams', searchParams);
//make the search and then update `searchResults`
}
}
which means your search-filter component would aggregate all of the search filter fields into a single search object that's used as the lone parameter of the onFilterChange.
You may think now, "well, why not just do the searching from within the component?" You can, but doing so in a DRY way would mean that on load, you first pass params to the component, a default search is made on didInsertElement which emits a result in an action, which updates the searchResults value. I find this control flow to not be the most obvious. Furthermore, you'd probably need to emit an onSearchError callback, and then potentially other actions / helper options if the act of searching / what search filter params can be applied together ever becomes conditionally dependent on the page in the app.
A component that takes in a search object and emits an action every time a search filter field changes is dead simple to reason about. Since the searchParams are one-way bound, any route that uses this component in it's template can control whether a field field updates (by optionally preventing the updating of searchParams in an invalid case) or whether the search ever fires based of validation rules that may differ between routes. Plus, theres no mocking of dependencies during unit testing.
Think twice before using subroutes
For the subroutes part of your question, I've found deeply nested routes to almost always be an antipattern. By deeply, I mean beyond app->first-child->second child where the first child is a sort of menu like structure that controls the changing between the different displays at the second child level by simple {{link-to}} helpers. If I have to share state between parents and children, I create a first-child-routes-shared-state service rather than doing the modelFor or controllerFor song and dance.
You must also consider when debating using children route vs handlebars {{if}} {{else}} sections whether the back button behavior should return to the previous step or return to the route before you entered the whole section. In a Wire transfer wizard that goes from create -> review -> complete, should I really be able to press the back button from complete to review after already having made the payment?
In the searchFilter + displayData case, they're always in the same route for me. If the search values need to be persistent on URL refresh, I opt for query params.
Lastly, note well that just because /users/:id/profile implies nesting, you can also just use this.route('user-profile', { 'path' : 'users/:id/profile' }) and avoid the nesting altogether.
I intend to use Camunda for my product. While all camunda abilities match with my needs, i have a concern about camunda modeler controlled usage. Following are my needs in modeller
Is it possible to create custom domain specific tasks which i can simply drag-drop during modeling. It should be possible to define custom properties needed by this custom state
Can I somehow control/prevent use of custom java code/scripts by person modeling process. I want to restrict use of only my custom tasks, so that we don't end up with lot of scattered code across processes.
Can experts share views to achieve these targets?
Recently Camunda Modeler (I am using release 1.4.0, published on October 2016) has been extended to allow json template installation, which can meets all of your needs (if I understand them correctly), or at least the most of them.
You may find documentation for templates build here. The documentation is in progress, but what is already published I think it is quite clear. Briefly you have to
list all the elements you want to customise (user tasks, general tasks, service tasks, listeners, links and so on)
find out the json representation (explained in the short documentation) of each element
insert all the jsoned elements in a file (for example: myElements.json)
put the file in a specific modeler folder (see below)
close and restart the modeler
For example if you have installed the modeler in C:\Tools\camunda-modeler\, the folder to publish the file into will be C:\Tools\camunda-modeler\resources\element-templates (note that resources will be already present, but element-templates will not; it will have to be created).
If all will be right the modeler will start without any error and you will find a new dropdown list selector on the right panel (as stated in the documentation) for all the elements for which a template has been defined. Generally you have to classify each templates as either a user task, or a service task, or generic task and so on, so that when you want to use it you have to start from the generic element. For example, if you prepare in the json file 2 templates of kind of user task, say userTask1 and userTask2, if you want to insert in your new process userTask1 you have to
pick up an empty userTask
and choose from the element template selector on the right the voice userTask1, so that the empty user task becomes quickly the userTask1 (with all my custom properties with my default values)
that's it
To sum up, you may build templates with custom id and name (editable), with custom properties (editable or not, or even hidden), with eventual input/output parameters. So you may have default values properties and also tasks with simplified selections or without any selections at all.
You may find good starting examples to build your own templates at this GIT repository.
Hope that is enough to understand.
I am Using Sitecore 6.6
I believe item:setdefaultworkflow and item:resetdefaultworkflow commands are used to reset the workflow fields on an Item with values set on Standard values.
If not please correct me.
Here is the Path in Core:
/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Workflow/Set Default Workflow
commands are not shown on the Ribbon. How do I use these commands? what is their purpose. Any Help is greatly appreciated.
I am aware of Version >> Fields(Reset)>> then choose the fields to reset with multiple clicks.
I am trying to use these commands if they solve my purpose to reset the Workflow Fields to standard values with a command on Review Tab >> Workflow section with one Click.
As far as I'm aware, these buttons are only visible on __Standard Values items. They are used to assign the workflow that will be used for new versions of that template going forward, or to clear the workflow that has been set (note that items which are already part way through a workflow will still need to finish it before they are no longer associated with a workflow).
The idea is that you assign the workflow to the standard values of templates (or base templates) in your solution, and those settings then get carried through to your content items.
Although you are able to, I'd advise against fiddling with the workflow fields on individual items before you fully understand the purpose of the fields.
For more information, I'd suggest looking at the Sitecore workflow reference document: https://sdn.sitecore.net/upload/sitecore6/60/workflow_reference_sc60orlater-a4.pdf
I'm wondering about documentation to create a simple custom ribbon control for sitecore shell.
The problem i'm trying to address is that Admins should be able to force all subitems recursively to be approved to a certain workflow state (rather than approve each one manually), but we currently don't know any way to achieve that.
To solve this, we want to force items throught the workflow state (triggering the corresponding commands) programmatically, but we need a sane way for admins to interact with this, the sensible option would be a custom thingie in sitecore shell, but we aren't sure how easy is to achieve that.
any recommended readings for this problem?
Though this article claims to be written for Sitecore 5.3, the same steps apply for 6.x as well. Note: it requires access to the SDN: How to create a ribbon button in Sitecore v5.3
The high-level points from the article are:
Create a new class that inherits from Sitecore.Shell.Framework.Commands.Command
Mark the class as [Serializable]. It might not be necessary for simple commands, but add it now so you don't get problems later! Otherwise the button might not work correctly (this is related to pipelines - and the fact that pipelines might be stopped and resumed)
Override Execute() and possibly also GetIcon(), GetHeader(), QueryState(), GetClick(), GetSubmenuItems()
Add a new <command name="…" type="..."> tag to /App_Config/Commands.config file
Log into Sitecore and switch to the core database
Navigate to /sitecore/content/Applications/Content Editor/Ribbons and create (or copy) a command in the desired chunk
Enter your command name (the one from step 4) in the "Click" field (and supply a Header, Icon, Tooltip, etc)
I have read what I can on cloning and it seems like a partial solution for our client. I read http://www.sitecore.net/Community/Technical-Blogs/Getting-to-Know-Sitecore/Posts/2010/10/Cloning-What-Ifs.aspx but the commenters didn't finish out the answer.
Sitecore clones give notification on changes which is nice and supports the idea of workflow for all items, but the clone parent does not give information on what is cloned from it. So when a change is made on our (mainly) master site, finding each cloned item in the 5 sister sites is going to become much too tedious too fast.
I believe that proxy items would have once been the true solution, but considering that they are deprecated, I don't think it's a solution we are looking to implement.
Besides modifying our workflow and messing around with the clones, is there a built-in or easier way to maintain clones?
Desired Behavior:
When parent of clones becomes approved into a final workflow state => Accept the changes on the clones as well.
Or
Less Desired:
Give a list of all child clones of an item in the Content Editor with links to edit.
For your desired behavior: you'd have to implement either an event handler or pipeline processor that when an item is approved, you use the Links Database to find all clones of it and programmatically approve those. I believe this is certainly do-able from a code perspective.
For your less desired behavior: you can use the Navigate tab > Links drop-down to find clones. Just look at the Referrers that have the _source field displayed, meaning they refer to that item via the "_source" field which means they're a clone of it.
UPDATE
To modify the workflow of an item via C#, refer to Changing the Workflow State on an Item.