Comments
Right... the export/import approach is definitely the best way to move from one database to another.
To add some additional info for anyone else reading this...
Arun is spot on with his reply. The other way to migrate a project is to move the entire database. This means all of your projects would be migrated in bulk. You also must move your attachments manually, since those are not stored in the database. One advantage to this approach is that the passwords remain intact.
This is not documented or supported and it could very possibly break in the next release.
That being said, this works in Mingle 3.3:
{{table
query: SELECT Number, Name WHERE Type = Story ORDER BY Project_Card_Rank}}
This is not documented or supported and it could very possibly break in the next release.
I don't have an answer for #2, but there is a way to implement #1. (BTW... in the future it's best to split these into two posts.)
You can't put that formula (TODAY - 7) into a MQL query. But you can put a formula property onto a card. Suppose you have Task cards that have a "Due Date" property. Let's you want to generate a report showing all tasks due within the next seven day. Here's how
Create a new Formula property on the Task card called "Due Soon". Set the formula to "Due Date - 7". Make this a hidden property.
Create a table on a wiki page with this query:
SELECT Name, Number WHERE TYPE = TASK AND "Due Soon" <= TODAY AND "Due Date" >= TODAY
This will show you all of the Tasks that are due soon, but not the ones that are overdue.
The idea is that after development an analyst reviews the story as implements and signs off on it delivers that it meets the intended business value.
If you skip this test, you run the risk of developing and testing something, only to discover at the signoff stage that there was a mis-communication between the analyst(s) and the developer(s).
All that being said, if you want to remove this column you can do so via these steps:
- Make sure that no stories are currently in the "BA Review" column
- Modify/delete transitions as needed to skip this step
- Hide this column on the Sprint Backlog cardwall.
- Re-save the tab definition by clicking "Add current view to team favorites" and entering "Sprint Backlog". This will updates the tab definition.
- Go into Admin - Card Properties. Edit the Status property and delete the value for "In BA Review"
It takes several steps to completely remove that swim lane, but no other product on the market let's you completely remove a step from the middle of the workflow like that.
In 3.2, you should use the "Add to Current Sprint" or "Add to Next Sprint" transitions. These transtions move the story to the current or next sprint and change the status from New to Ready for Analysis. Of course, you need to set the project variable for Current Sprint and Next Sprint in order for these transitions to have the desired effect.
In 3.3 we simplified the Scrum template. The "New" status is gone, as are the "Add to Current Sprint" or "Add to Next Sprint" transitions. The goal here was to simply things. In 3.3 you can add Stories to a spring using the Sprint Planning team favorite.
Using Mingle 3.1, use this to display any card property within that card's description:
{{value query: SELECT <property name> WHERE Number = THIS CARD.Number}
BTW... you can also now show info from a parent card on a child card. So on a task card you can show the status of the parent Story"
Story Status {{value query: SELECT 'Story Status' WHERE NUMBER IN (THIS CARD.Story)}}
Hmmm... so how does one install/run this on Windows?
I've had no trouble running it on the Mac, but less success on Windows. I have Adobe AIR installed on Windows... any suggestions?
Thanks!
Matt Quagliana
One workaround is to subscribe to notifications via email and then let your email client filter the messages based on content. When a user adds a comment the email includes the text "Comment added:". You could write a mail filter that colors those messages, places them in a special folder, etc.
--
Matt
Hmmm... interesting idea. How does the "comment added" property get reset? The history filter looks for a state changes so "comment added" must get reset at some point or you will only be notified of the first comment.
Mike's suggestion works very well... create a hidden property that moves from 0 to 1 via a transition.
BTW... I often use this to calculate velocity via an aggregate. I have a "Story State" property that is initially set to 0 and is set to 1 (via a transition) when the story is completed. Then I create a formula called "Completed Points" which is Points * 'Story State'. An aggregate called Velocity sums up all of the Completed Points in an Iteration.
You need to get this data into a card property into order to filter or report on it. For now (Mingle 2.3.1) you need to get the "Created by" data into card property that you create.
The "Created by" value does not get included when you export to Excel, but there is a (somewhat manual) way to get this data into a card property.
- Create a new property of type "team", call it "Creator" (or whatever) and set its default value to "Current User". Also set it to "Transition Only" so it can't be easily changed.
- Go to the All tab and filter it to show the cards in question
- Show the "Created by" column and sort by it.
- Using the checkboxes on the left side of the table to select all of the cards created by a single user
- Tag all of the selected card en masse with the Mingle login name of the card creator (use the "Tag" widget above the list)
- Repeat step 6 for each person who has created cards
- Export the card data to Excel and use the tags data to populate the "Creator" property. The simplest method is to just change the title of the "Tags" column to "Creator". Be sure to delete any "non-Creator" tags, if you have any.
- Import the updated data. You only need to import the Number column and the Creator column... feel free to drop the other columns in the spreadsheet before you do the import.
- Delete the tags.
If you set up the default value for Creator (Step 1) you won't have to repeat this process in the future.My understanding is that this is the expected behavior. (At least it's what I've come to expect.)
Number is the only property that is guaranteed to be unique. Not sure how Mingle could provide a link to the underlying data without the card number.
I would like to help... a screenshot showing the problem would be handy.
Matt Quagliana
The "Card" property is useful in other ways. I have it on every Iteration card, which makes it possible to automatically show Iteration Start Date and End Date on the overview as such:
Current Iteration is: {{project-variable name: (Current Iteration)}}
Start Date: {{value query: SELECT 'Start Date' WHERE Type = Iteration AND Card = (Current Iteration)}}
End Date: {{value query: SELECT 'End Date' WHERE Type = Iteration AND Card = (Current Iteration)}} <br>
Once this is in place you never need to update the dates on your Overview. Would also work for passing dates into charts. (Correction: charts require literal dates, not queries that return dates.)