Comments
Hi Lisa --
I think that this is possible by having an additional 'ideal velocity' property on your iteration cards, and then building the graph using this. There was some previous discussion along these lines: http://community.thoughtworks.com/posts/0aef8f6817
hope that helps
-- Andy
As an alternative, you can just use standard <img> tags instead of the wiki markup. When doing this, you need to refer to the full URL of the uploaded image, which you can find by hovering over the link. The downside with this is that the URLs aren't as 'portable' as the wiki markup, so if you export the project, or use it as a template, you'll have to fix all the broken image tags.
-- Andy
ps. It seems that the other textile control characters (eg. !>image.png! ) don't work as expected without using the full URL to the image, as the picture names shorthand isn't really a relative URL.
Hi Fred --
Have you looked at the enhanced table macro: http://community.thoughtworks.com/posts/3d8a31247f ?
I believe this allowed mathematical operations on columns, and the colouring of cells - perhaps it could be further extended to match your requirements?
(I note that there is a comment suggesting the macro may need tweaking to work with Mingle 3.0 too - so it may take a bit of effort to get up and running)
cheers!
-- Andy
@gyngve
I think you can do that by ensuring that the properties you want to control are 'transition only', creating a transition for updating them, and making sure that only the appropriate people have permission to execute that transition ...
It's probably worth noting that this transition doesn't necessarily need to be a step in your existing workflow - although you could make it so, if you wished. You could also take advantage of the new '(set)' transition pre-requisite, to further control the way your team is able to modify previously chosen priority/severity values.
hope that helps,
-- Andy
Hi Chris --
The issue with the URL that you are using is that (this card) is MQL, and the wiki pages don't pick it up and interpret it as such automatically.
The ability to add child cards for the current card is already present in Mingle - I mentioned it my comments to in an earlier thread:http://community.thoughtworks.com/posts/3cbac1e6fb/comments#comment3077
hope that helps
-- Andy
I can't think of a way to hide it - and given this, instead I think I'd probably call it something like Testing Scope, and then use the aggregates feature to roll up some high level stats about my Test Cases ...
Hi there,
You can change the order that the properties display - there is a drag-and-drop re-ordering in 'Project Admin > Card Types > Edit ...' - which allows you to at least make sure that your related properties are next to each other. You can also hide properties, and then only change them using transitions (even where user input is required) - this works well for properties that only need to be updated at a certain time - and keeps the cards looking neat and tidy.
Even though the Story type is part of your tree definition, when you create a new story it is not added to the tree by default - you need to do that explicitly. When the type is the top level for your tree, this can't be done directly when you create a card - it has to be done in the tree view (there is a tab titled 'add cards to tree' on the right).
One way to simplify things is to have a dummy top level card type and a single instance of this, above 'Story' - and add all Stories to this instance by default (set it up in the card defaults) -- this ensures that all Stories are part of the tree on creation, and allows you to add Test Cases as appropriate ...
Hi there --
You could define a tree 'Iteration>Story>Defect>Task' - this would allow you to create and view both structures (you can add Defects to Iterations without intermediate Stories, and similarly, you can add Tasks to Stories without having a Defect in the middle) ... In this scenario, the team would need to understand that this tree isn't the way to link Defects to Stories - I'd recommend a separate tree or property for that - as otherwise this can get confusing as Defects are played in a different Iteration to the Story that spawned them ...
hope that helps
-- Andy
I think that part of what you are looking to do is available already - you can both view and create children from the card view. In the tree properties section of a card, there is a little (+) icon - clicking on this pops up the same dialog as in the tree view - and this allows you to create cards directly. I've attached a screenshot.
Whilst it is not currently possible to prevent someone from creating 'orphaned' children, I tend to find that a combination of reports (I prefer pivot tables) and creating a rss/email watch on the history will pick up the exceptions as they occur.
For the history, you can set it up so that it watches for 'where they have been ... type='Test Case' and 'Story' = (not set)'
hope that helps
-- Andy
Create Children.png (64KB)Hi Adrian --
You mention that linking to favorites is also an option - in which case, you should be able to do so with a URL that looks like:
<hostname>/projects/<projectname>/cards?view=My+Favorite+Cards
(substituting as appropriate)
cheers!
-- Andy
Do you see a little * next to the count? I believe that the updates are run in a background thread, and, if you give it a little while, they should update just fine.
The related post linked above is now at: http://community.thoughtworks.com/posts/5d56fa8b5a
The related post linked above is now at: http://community.thoughtworks.com/posts/fc2c4f96df
Hi Jean --
If I understand you correctly, you are looking to identify all of the 'Test Case' cards that don't have any children 'Test Results'.
I just set up a sample project to do this - I configured an aggregate property in the tree, called 'Runs', that is a count of the number of children of each 'Test Case' - and then I created a table that selects using this property - I've attached it for you to take a look at.
Hope this helps
-- Andy
testing_project.mingle (7KB)