One issue with the grid view is that the title of the card gets cut off and there's no way to "expand" the card to show the entire title.

We're wanting to use Mingle as the sole task board, instead of having a physical wall AND update Mingle.  Not being able to see the full story title is a barrier to moving from a physical space to a virtual wall.

Has anyone successed in adjusting the size or even customizing the fields show (I believe there is another thread on this, but no solution yet)?

One major weakness of Mingle (IMO) is that it doesn't understand history natively, so if I want to track "when was this card analysis complete?," "when was this card development complete?" etc, I have to set up a bunch of hidden fields, make sure Status is "transition only," and set up a bunch of transitions to capture the right metadata. 

The "hidden fields + transitions" approach works pretty well, but has a major hole that keeps biting me--project admins aren't actually blocked by "transition only" restrictions. 

I find myself almost once an iteration looking at my MQL-generated charts, seeing something odd (e.g. more stories are dev complete than analysis complete), and having to find the card and fix the metadata.  Invariably, someone with project admin privileges forgot to use the transition, and just walked the story status forward by hand.  Which means my hidden fields didn't get set. 

Mingle makes this kind of bug easy, because someone with "Project Admin" is always active with admin priviliges, and so is never bound by restrictions like "transition only." This feels wrong to me.

I realize I could bypass this by "locking down" project admin to only a very small number of users, but that seems like a heavy handed fix.  What I'd prefer is for admins to be warned in some way "Hey, you're doing something that I am only allowing you to do because you're an admin."  This would be a useful reminder to admins "Oh, yeah--there's a better/different way to do this." 

Request the ability to be able to directly type-in a card number for the tree relationship property.  Right now we are forced to select from a drop-down list.  If the list is too long, then one needs to set filters so that their card-of-interest is displayed so that it can merrely be selected.  It would be a whole lot easier just to enter the number of the card - that is typically already known.

When using History to View/Subscribe to Cards, I can set positive parameters (ex. "Status IS _____") but not negative parameters (ex. "Status IS NOT _____").  We would like History to use the same parameters as Filters (IS, IS NOT, GREATER THAN, LESS THAN).

As far as I can tell, transitions are required to be tied to a single status value in the originating state (If a card has these properties:).  I'd like to associate a transition to multiple beginning states, so that for instance:

A card is in status analysis complete, ready for development, or development in progress and each of those states shows a transition for "more analysis required".

Currently, I have to create multiple transitions, each containing essentially the same 'actions' on the right side, but with a different starting value on the left.  'Rejected' is another example of a transition I'd like to be able to call from multiple states, as sometimes the BA will reject a change early on, or may defer and let the development team reject it after some analysis has been performed.  The end results are the same.

I think this is just as much a Bug as a Feature Request.

With the new hard-coded [Created By] and [Modified By] selections in the

List View drop-down, I'm curious why I can't use those anywhere else.

For example, we currently have a Field called [Author].  It would be nice to use the [Created By]  field instead, and just remove the [Author] field we currently use (as the inability to  manually change it doesn't matter at all).

I can't add these properties as viewable Fields on a Card.

I can't use [Created By] as a Filter.

I can however choose [Author] and [Created By] as Columns in List View, which is repetitive & confusing.

If we're getting [Created By] as a hard-coded parameter (that I can't get rid of) - I think it would be nice to at least be able to use it, right?

Using Mingle 3.0

It took me awhile to figure out how to make subscriptions work for us to notify via email of card changes / updates (we have several people not well versed in the use of feeds).  Once I did, it works beautifully, but I'm wondering if some enhancements aren't in order perhaps?:

1) Ability to create default subscriptions that all members of a project would inherit. 

2) Ability to create default list of subscriptions that members could choose to use or not.

3) Ability to edit subscriptions as opposed to recreating them entirely (administrator, user, or both).

4) Ability for administrators to create subscriptions for users.

The key to all of these features would be that they need to be relative to the user currently logged in, not necessarily the administrator who sets them up.

This is a great new feature to copy from one project to another but misses the ability to copy to host project.

The good thing about the 'copy to' feature is the fact that it copies any attachments and all card settings to a new card but this is not available to use within the current project.

I can copy out to another dummy project and back again but seems a bit long winded.

Can we have 'Copy To' current project?

So, ran into a usability issue that's bitten me in the past that got me again today.

When I'm working with a canned view that's on a tab, and I make some changes to the filters/view/etc, there's a button to the right of the view name in the tab that looks like an arrow pointing in a circle, which does "Reset the View to the tab default," i.e. it reverts to the "canned" look.

There's a similar looking but very different thing when I'm working with a favorite instead of a tab.  If I open a favorite and make some changes, there's a button the right of the name that looks like TWO arrows going in circles, which does "Update the favorite to match whatever I'm currently looking at."

So, with a tab, the button does "Throw away my changes--give me the default," but for favorites does "Throw away the old defaults--save my changes."  And since neither has a confirm, it's very easy to do the wrong thing.  The worse impact is with favorites, where I can unrecoverably save over my default, and exactly at the wrong time (when I realize I've messed up the view and want a do over).

Please consider rethinking this.

Hello

I'm working on a distributed team. We don't have a physical card wall and just use Mingle.

The biggest thing I miss not having a physical wall with actual cards (apart from arguing over who owns a sharpie, splitting a piece of bluetack into increasingly tiny chunks and having a cleaner tidy the whole thing away) is being able to annotate cards.

Cards on walls end up with notes of their size, little red dots to show that there are bugs outstanding, different colours for stories/bugs/tech debt, post-its showing who's working on them, other post-its to show they're blocked.

In Mingle most of this is lost. You get one shot: pick a colour.

It would make we weep with joy if there was some way to configure properties to appear as little coloured dots on cards in the grid view. Or a little tiny 'L' for a large story; just imagine that, a little tiny 'L'. Ahhhhhh.

Ben

Example Card # 123  Type=Story

Adjust Name by adding  Clone1 .. 2 .. 3 .. 4     set a Clone property .T.

set all NEW properties other than NAME  to OLD Values

allow user to make changes - - and set CLONE property to  .F.

Usage: New Card #999 added this Date all values Like Card #333 with Name changed to

        card name +"clone of#333"   and Clone prop set to .T.