Author Topic: Membership Status Rules - Name vs Label fields (Read 1934 times)

mdlueck · October 03, 2010, 01:13:47 pm

Greetings:

We notice in Civi 3.2.3 that the Name of the Membership Status Rule is not editable.

In configuring Civi, we slightly changed the meanings of some of our status rules.

We ran: SELECT `name`, `label` FROM `civicrm_membership_status`

Is it all right to "hand edit" the Name fields to match the Label fields values or is something now dependent on that Name string within Civi?

Dave Greenberg · October 03, 2010, 02:29:32 pm

The 'name' column in civicrm_membership_status is meant to be a non-translatable "key" for programmatic operations. Mostly this applies to the two "reserved" statuses - Pending and Deceased. However there are methods in the code which look for 'Expired', 'Cancelled' and possibly others. For an example of this check CRM/Member/Form/Membership postProcess():

Code: [Select]

       require_once 'CRM/Member/PseudoConstant.php';
       $membershipStatues = CRM_Member_PseudoConstant::membershipStatus( );
       if ( !in_array( $membership->status_id, array( array_search('Cancelled',$membershipStatues),
                                                                           array_search('Expired',$membershipStatues) ) ) ) {   
            $cancelled = false;
       }

CRM_Member_Pseudoconstant::membershipStatus() grabs the 'name' column values by default.

mdlueck · October 03, 2010, 03:17:26 pm

So how many other tables (which ones) do I need to check to be sure that the 'name' field values do not get orphaned?

Dave Greenberg · October 04, 2010, 09:31:33 am

I don't understand your question / what you mean by "name being orphaned".

Most tables which store 'enum' type values were initially designed w/ both a 'name' (internal key) and 'label' (display value) column. Membership status did not have both prior to 3.2 - it only had a 'name' column - and this caused problems particularly for non-English sites since the 'name' values where translated.

mdlueck · October 04, 2010, 01:19:09 pm

From my earlier post:

We ran: SELECT `name`, `label` FROM `civicrm_membership_status`

I would like to correct some of the `name` column entries. What other tables within the Civi 3.2.3 DB do I need to check and update there if I find records with the "old" value of `name`?

I am assuming that `name` column is used as a key for that table, and other tables in the DB might have matching values that are intended to match. Correct? If so, what other tables should I check before I do the `name` fix-up task?

Dave Greenberg · October 04, 2010, 02:37:13 pm

The issue is not 'name' matching 'label' - but 'name' being a reliable key for programmatic operations. Membership status is the only one I can think of where label was added "late" (at least in the last year or so). Might want to continue this on IRC if you still have questions.

mdlueck · October 04, 2010, 06:15:55 pm

I understand the need for `name` to be consistent for referential integrity sorts of things.

We ended up changing the meaning via changing the `label` and for our sanity sake would like to hand edit the `name` fields.

The `name` field shows up in the UI at some spots, which will lead to confusion.

What other tables shall I verify the contents of to make sure no records are orphaned?

xavier · October 05, 2010, 12:56:37 am

Quote from: mdlueck on October 04, 2010, 06:15:55 pm

The `name` field shows up in the UI at some spots, which will lead to confusion.

Could you fill an issue with these spots, ideally with a patch? Only the labels should be visible in the UI.

mdlueck · October 06, 2010, 06:32:40 pm

Quote from: xavier on October 05, 2010, 12:56:37 am

Could you fill an issue with these spots, ideally with a patch? Only the labels should be visible in the UI.

CiviCRM \ Membership Dashboard \ Recent Memberships \ both "view" and "edit" links for a particular member, on the resulting screens 'Status' is the `name` rather than the `label` is one of the spots it is showing up glaringly.

Where would I log an issue as opposed to a mere forum message? I guess I could hunt (grep) through the code to find where this is coming from in the PHP code and patch it.

xavier · October 07, 2010, 01:03:19 am

http://issues.civicrm.org/jira/browse/CRM?report=com.atlassian.jira.plugin.system.project:roadmap-panel

Quote from: mdlueck on October 06, 2010, 06:32:40 pm

Where would I log an issue as opposed to a mere forum message? I guess I could hunt (grep) through the code to find where this is coming from in the PHP code and patch it.

That's be cool if you can get the patch with the issue... and almost guaranty a faster resolution too, not to mention the eternal gratitude and fame

Might want to come on IRC if you get stuck, and a couple of resource if you want to understand how civi works:

http://en.flossmanuals.net/CiviCRM/DevelopIntro
http://civicrm.org/architecture?page=6
X+

mdlueck · October 16, 2010, 11:29:30 am

Back on this discussion... I guess a bit of assistance is needed in locating where in the source tree this UI behavior comes from. "grep for the usual suspects" aka from my Drupal background did not produce the smoking gun.

Part B, it looks like the `id` field of that `civicrm_membership_status` table is being used to key off of, not the `name` field. So just now I hand (PHPMyAdmin) edited the records where `name` and `label` were not the same so that the application people would not be confused. I hope that will not cause errors at some point down the road. I am quite confident it will not. I searched for the former `name` strings and the only place that string showed up in a mysqldump was in that table/record I hand edited, so I highly doubt it was being used in a foreign key situation, which is what I was concerned about originally.

Dave Greenberg · November 03, 2010, 05:22:39 pm

FYI - just tested this in latest 3.3, and as of 3.3 alpha we are definitely loading the civicrm_membership_status.label values in the Membership dashboard, membership view and edit forms. Not sure if there was an issue filed, but things are working as they should in the upcoming release.

mdlueck · November 22, 2010, 11:35:49 am

Thanks Dave for double checking this in the up-coming version.

(I guess there will be further major version compatible with D6 then!

)

CiviCRM Community Forums (archive)

News:

Author Topic: Membership Status Rules - Name vs Label fields (Read 1934 times)

mdlueck

Membership Status Rules - Name vs Label fields

Dave Greenberg

Re: Membership Status Rules - Name vs Label fields

mdlueck

Re: Membership Status Rules - Name vs Label fields

Dave Greenberg

Re: Membership Status Rules - Name vs Label fields

mdlueck

Re: Membership Status Rules - Name vs Label fields

Dave Greenberg

Re: Membership Status Rules - Name vs Label fields

mdlueck

Re: Membership Status Rules - Name vs Label fields

xavier

Re: Membership Status Rules - Name vs Label fields

mdlueck

Re: Membership Status Rules - Name vs Label fields

xavier

Re: Membership Status Rules - Name vs Label fields

mdlueck

Re: Membership Status Rules - Name vs Label fields

Dave Greenberg

Re: Membership Status Rules - Name vs Label fields

mdlueck

Re: Membership Status Rules - Name vs Label fields