Using Import to update existing Memberships

[reynog]

Here I go again with Import issues.  This is in CiviMember, however, and I think it's a bug... at least I can't resolve how this could possibly be correct.

If you do NOT select the Update radio button, the mapping page gives you the following "match to contact" options: Contact ID, External ID, First Name, Last Name.  This is all well and good and seems to work just fine to import non-existing memberships.

However, when you select the Update radio, you then get External ID as an option to "match to contact" and Membership ID to "match to membership".

Shouldn't the update option also have Contact ID as a "match to contact" option?  And, better yet, shouldn't it not even be necessary to match the contact, since you have to match to the membership record?

I exported my existing memberships, which gave me Contact ID and Membership ID.  Seems weird (and unnecessary) for me to have to merge this export with my contacts' external IDs (and besides, what if all my contacts don't even have external IDs?)

Continuing on to what is probably a related, but slightly different bug.

In the mapping screen, if I only map the Membership ID field, and my extra fields I want imported/updated, it returns the following errors:

Please correct the following errors in the form fields below:

    * Missing required contact matching field: Contact ID.
    * Missing required field: Membership Type

Now, I find it kind of funny that it's yelling at me for not matching to Contact ID, when it doesn't even give me Contact ID in the list of fields I am allowed to map to.

Also, why would it require Membership Type if I'm mapping to the Membership ID... the type would have already been defined on create, since it's required then.

Basically it seems like Membership update is broken, unless you merge your external IDs with your membership export.

-----------------

OK... I just tried putting my external ID as a column in the file, and it STILL returns the same two errors.

So, it only gives you one possible field to match to contact, but it won't even accept that one!  Based on that, it seems like it's impossible to  update existing memberships.

Has anyone actually done this successfully?

[xavier]

Hi,

For the sake of the discussion, let's assume for a moment that the guys that developed that import functions are not complete morons that are randomly throwing buggy html pages here and there with no purpose beside annoying the users to death.

I've experienced the pain, and bugs in the import are extremely annoying indeed, and it takes forever to run a single test, and you quite don't know if it's a bug, a misunderstanding on how you're supposed to use the thing, or if you pressed the wrong button at the wrong place. Before dropping to the conclusion that's a bug and that no one has ever used the software, I would start by considering that it might simply be a misunderstanding on how to use it, and try to clarify how you're supposed to do what you're trying to achieve.

What I've experienced as well is that the devs are amazingly willing to try helping and if you can provide a good use case, they will look at it quickly. I'd suggest you to read esr http://www.catb.org/~esr/faqs/smart-questions.html if you haven't already, that will probably let you get quicker responses.

I might misunderstood your post, but it sounds more aggressive than necessary, and as a user, I've appreciated so far a very constructive discussion on the forum, I'd certainly appreciate if it could stay that way. Could you clarify what you're trying to do and the version of civi you're using ?

Good luck!

X+

[reynog]

I apologize if the tone of my post came off as aggresive... that was not at all my intent.  I am fairly frustrated as I've been dealing with import over the last couple weeks and have run into roadblock after roadblock.  But, I feel that I explained everything I had tried and seen, and my observations about where the problems are.

So, I feel that I did outline my use case well in the post above.  I'm not sure how else to explain it in a better way.

And my final question was not meant as a rhetorical.  I am sincerely asking if anyone has been able to update existing memberships via CiviMember import, because based on the error messages and available matching fields, it doesn't seem as though it would be possible.

I tried to provide plenty of information about what I did and what I saw, so that if I am misunderstanding the process somehow, other users would be able to identify that.

If there's something else I can provide that would make this more helpful, let me know.  (I did omit the version, sorry about that:  I'm using Civi 2.0.5 on Drupal 5.7)

[geilhufe]

I think that it might be better to parse your question into bite sized chunks so it can be dealt with:
Make contact ID matching available on CiviMember update import.

I just ran through the user experience on the sandbox and I think that is probably worth filing an issue (issue tracker link in the header)

The rest of your post can also be divided up and dealt with one by one. There may be a good technical reason why the contact ID is not an option.

[reynog]

Ok... some follow-up information...

I tested further, and added Membership Type to my import.  This actually allowed the import to complete successfully (using External ID as the contact matching field).

So, two things...

1) When Update is chosen, and Membership Type is missing from the import file, it returns two errors, when in actuality there is only one.

2) When Update is chosen, there is only one contact matching field available (External ID) - versus when Update isn't selected, there are 5 fields to choose from (Contact ID, External ID, First, Last, Email).  I don't know if this is a bug or not... but I would love to hear from anyone that knows why there is only one contact matching field when you're updating.

I will file either/both of these as issues if that's appropriate.

[Dave Greenberg]

Expected behavior for 2.1 is that you should be able to use either Contact ID (civicrm_contact.id), External Identifier OR the configured "strict" duplicate matching fields. The behavior you're reporting sounds like a bug. I just tried to see what's currently happening on the 2.1 sandbox and the upload / parse function is broken at the moment :-( I've filed a request to get that working again so we can then see if we're getting expected behavior.

The issue which is supposed to address this is: http://issues.civicrm.org/jira/browse/CRM-3038