Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: 4.1.1
-
Fix Version/s: Unscheduled
-
Component/s: CiviCRM API
-
Labels:
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
An API 'get' on Membership returns:
- 'relationship_name' which is set to 'Child of' - this has nothing to do with the membership
- 'membership_name' with the name for the membership type. Should this attribute be named 'membership_type' instead since this is a pseudoconstant for 'membership_type_id'?
An API 'update' on Membership returns:
- 'is_override' and 'reminder_date' attributes set to "null" (the string "null", not NULL)
Attachments
Activity
Quite a bit involved here - pushing it out
You might have thoughts on this - not sure how to fix given it's working with legacy cruft
Hi,
Do you think they are people that rely on this api (and the weird relationship/"null"...?
Might be better to brake compatibility and use the normal basic api? The way Nicolas describe it sounds like we should have had more questions in the forums about it... if someone actually did try to use it
My vote for braking compatibility and go "basic" and sane. But I'm not using the membership api, so ...
I personally do rely on this API as part of an import script, but have coded my way around these peculiarities. But I would gladly change my code if the API was to go "basic and sane" and this would be by far my preferred outcome - the way it is today is ugly, totally non-standard, and makes no sense whatsoever.
@Nicolas: could you try giving it a go?
api/v3/Email.php is a good example of how to use generic basic api.
X+
Hi,
the api seems to use the basic already for most of the needs. for get, there is a "legacy" mode when contact_id is set, a basic get for the rest, and still a bunch of custom code.
Does it behaves better now? Would you want to try to make it do it better?
About 'relationship name': I think that if the membership type has an associated relationship type, the field 'relationship_name' of a membership returns the name of that relationship type. If there isn't an associated relationship type (when relationship_type_id of the membership type is null), the API just returns the first relationship type in the table, in this case 'Child of', which has ID 1. Which is a bug 
Closing due to age & neglct - open a new ticket against the current version if you wish to commit resources to fixing.
hmm - I think we should get rid of the relationship stuff off membership get if it doesn't work. It's legacy from API v2 , not tested , not standard & likely as not never worked.
Membership name = membership type - your recommendation makes sense to me
The update is a tricky one - we need to figure out what to do about that update function since it shouldn't exist but obviously does - somehow we need to let people know not to use it. We could set it such that it ONLY gets/ sets the id - that would be somewhat useful - ie you are going to have to do a get & create anyway.