stop changing cardtype on creation



Broadly, the issue is that if there is a cardtype X whose cardname is identical to the classname of cardtype Y, then whenever you try to create a Y you get an X instead.  The problem apparently comes in using the `class_for(given_type)` card method, which does lookups first based on cardname, then on classname.


Gerry created three support tickets - and and - and Wagn changed them to Reports. He was unable to see the cards after creation (Reports are GC Staff only).


(They've all been changed to Support Tickets now.)


I (efm) did some work on this and got it mostly working.  I think the only tests that are still breaking are breaking because they use an api that we don't want to support.


The way I've got it working now is that you still call class_for but you tell it whether you're giving it a cardname or a codename, and it only looks up that one -- no falling back on a second option.  It might be cleaner to have two methods: class_for_codename and class_for_cardname.  In fact, I can imagine better names still.


A level further out, I have it that if you call #new via Card::Type, it expects Type to be a codename.  but if you do :type=>Type, it's expecting a cardname.  There were some cases where we were doing it differently in code, so I made an option to call :typecode=>Type as a codename, but I'm not completely sold on that api yet either.


So we may still want to tweak the api, but it looks to me like the separation is effectively achieved!




any really clean answer will involve never mixing the two names.  This probably means that changing the method without changing the pattern of method calls will break stuff.  If we have a cardname and not a cardname, we should know that and lookup the classname before proceeding.


It may be wise to wait for refactoring that would put the classname (potentially renamed to "codename") in the cards table.


Note: we fixed the specific Support Ticket issue by changing the name of "Report" to "Team Report".


Happened for me when i created this ticket! --John


try it


I doubt any more will be done here for 1.2.  We did address the local problem, but since it was via data, I'm removing the 1.2 tag.

I did some work on this last week. nothing pushed yet...

  --Ethan McCutchen.....Tue May 11 13:57:29 -0700 2010

I was able to reproduce this in automated tests and have since fixed it. I don't think we knew of any other place where this was happening (if so we would have fixed it manually), so I'm going to close this.

  --Ethan McCutchen.....Mon Nov 01 21:34:05 -0700 2010