Comments
Thanks, sydd, that works (and is considerably more elegant than my workaround of hand-coding the table in HTML when I absolutely need proper formatting).
Hidden fields are, well, hidden--you're correct that they're not visible in the "standard" filters, or for list/grid views.
However, hidden fields ARE available from MQL. You can filter on a hidden property if you use the advanced MQL filters. Also, you can pull hidden fields into MQL queries, so if you add a table query to a wiki page, it has no problem getting the hidden fields for you. Not sure if a table query would be sufficient for what you're trying to do.
I can't answer for the Mingle team, but I suspect the rationale for hidden fields working this way is that hidden fields were designed primarily to support reporting--you can set "hidden" date/iteration fields on cards with transitions, and then use those fields to put together graphs/charts/tables showing the state of the project over time in MQL, without risking users accidentally modifying the data or seeing a huge number of reporting fields on cards.
I'm curious what kind of data you're looking at here. I'd sort of expect that if this is information that's valuable to add to views/favorites it wouldn't be a bad thing to have it visible to users on cards. Or maybe this is information that's only valuable to a subset of users (e.g. the project manager needs to report on it, but most users don't need to see it?)
Thanks, Susie. This might work, though isn't ideal. In my example, I care deeply about cards for next iteration that are in a "Not Started" state (since we should be picking them up for analysis), but don't care about "Not Started" cards for iterations further out (since I don't expect anything from them). I could potentially create an "Awaiting Analysis" status and once an iteration move next iteration's cards to that status. Will noodle on this.
Thinking a little more deeply, what it feels like I'd really like is less ordering child notes and more the ability to get at parent node attribues from the children. In other words, set a "start date" and "end date" on iterations, and be able to do something in MQL like: "type = story and 'Iteration>Start Date' is less than (NextIterationStartDate)" i.e. get at the Start Date of the Iteration card as if it were a property of the Stories linked to that iteration. This feels like a generally useful feature for trees--it would allow information to be recorded once at the proper level and be able to propagate down to the lower-level cards (the logical opposite of Aggregates).
Any status update on this feature? It's apparently been a "candidate" for over a year, and this continues to be an annoyance...
Agree with Fred this is annoying.
You may already know this, but you can avoid at least some of the pain by using "Search" instead of "Filter" from the "Select Card" view, and using "#<known card number>" as your search. This will always return exactly one item, which is the card you're looking for (note you need #<card number>, not just <card number> or it will search for any card containing the number)
Still too many click IMO, but at least avoids the need to hunt through a list or think about what filters to set.
Another option that may have some side benefits for you is to set up an aggregate property on your stories that is the count of the number of tests associated to that story. You can then filter on that aggregate property using MQL or other means.
To set up an aggregate, go to the tree view, click "Configure" and select "Edit Aggregate Properties." You want to set aggregates on type "Story." Define an aggregate called something like "Number of Tests" aggregated as "Count" on scope "Story." This will act like just another numeric property on your stories, so you can write a filter where "Number of Tests = 0"
The nice thing about using the aggregate is that you can also do stuff like find the average number of tests for stories, find stories with only one test, or find stories with a crazy number of tests, etc.
Thanks, Susie.
I figured this was "as expected," which is why I posted in Feature Requests and not Bug Reports for this. I'm just questioning whether this is the most sensible default behavior.
I feel like the guiding principle should be that the behavior should be what a user is likely to expect when they do a sorting operation, and the current defualt seems counter to that (at least to me). I'm comparing this to how other applications where I'm familiar with sorting a lot of data (e.g. MS Excel) handle nulls in sorted data.
Not a big deal--just a mild usability annoyance for me when a quick shortcut to accomplish a task that I expected to work...didn't.
Hi, Suzie,
Thanks for the quick reply, but I'm not 100% parsing your response. What is the fix you're considering making here?
To be clear, my concern is that we should always show "Add/Remove Lanes" whenever "Add/Remove Lanes" is set as a filter. My problem case is not really a case where there are no results, it's a case where all the results are in removed lanes, and so they don't show.
Mike
Exactly what I wanted--thanks!
Have you read the Mingle documentation on "Creating Charts and Tables"? There's a section on building pie charts, and it seems to map very well to what you're looking for. I believe aggregate properties work just fine in MQL syntax.
http://studios.thoughtworks.com/mingle/2.3.1/help/creating_charts_and_tables_in_wiki_pages.html
If you've tried this and are having problems, can you be a little more specific on what you've tried and what you're seeing?
Hmm...may be something they removed from IE7. Read the link I posted earlier (or gooogle)--there are a number of browsers that don't follow file:// links for security reasons. This appears to be something you can fix with configuration (the wikipedia article contains a link for fixing in Mozilla browsers like FireFox)
I'm not aware of a general method in Mingle for linking to a file on a filer server somewhere other than embedding file:// links to links, but maybe someone else has an idea. Obviously, this would be easier to link in Mingle if the files were somewhere accessible via HTTP, rather than just on a shared drive (for example, in a subversion repository)
Ah, right. It only really works for me in IE (probably because only IE really is integrated with Windows to browse directories/open files, etc.) This seems consistent with other wiki products that use file:/// links (Wikipedia's Mediawiki behaves similarly).
[edit] This appears to be a known issue/security restriction with Mozilla-based browsers. See http://en.wikipedia.org/wiki/File_URI_scheme [/edit]
If you're not using IE, the "IE Tab" extension to FireFox allows spawning a link in an Internet Explorer tab, which is how I use this--I right-click on the file, use "Open link in IE tab," and it downloads the file (and opens a blank tab, which I have to close). I'm sure there are more elegant solutions.
I believe you need 3 "/" after "file:"
Links like "file:///<server_name>/shared/Project Info/UsefulDoc.doc" work for me on Mingle 2.3.1.
The other way to see this is to set up a Property of "Created By" of type "Team", and then set up the "Card Defaults" to set the Created By property to (Current User) for all new cards.
I'm not wild about having to maintain a property for something Mingle already knows, but it's straightforward and works today (for new cards, anyways.)
Just for reference, if you're attaching the image you don't have to specify the full image URL, and you shouldn't have to save twice.
If you're attaching an image called myimage.jpg, go to attach and browse to the file and click attach. You can immediately add an image link of !myimage.jpg!, and it will "just work" when you save. If there's no path, Mingle assumes the image is attached to the card.
One drawback here is that you can't preview with your image (because the attachment isn't uploaded until you save), but it saves some time.
Obviously, doesn't help with any of your other concerns. I did start a feature request thread on card printing--you might consider adding "print attached images" to that. http://community.thoughtworks.com/posts/8bca400f08