This is weird. Please let me know if this is expected behavior or if I should create a bug report. If it's expected, can someone explain why?
I am building a website for a non-profit and hoping to use RedHen. I'm trying to integrate Drupal user registration with RedHen so as to capture some RH contact info during the sign-up process. My user registration page captures fields for RH including First Name, Middle Name and Last Name and also the Drupal username.
A test user signed up. As administrator, I approved them and the system sent the usual message:
Your account at XYZ Organization has been activated.
You may now log in by clicking this link or copying and pasting it into your browser:
http://example.com/user/reset/38/1392409268/tHtjUifyslc8oaTyk8DvCcD_cxum...
This link can only be used once to log in and will lead you to a page where you must set your own password.
After setting your password, you will be able to log in at
http://example.com/user in the future using your username: Joe Schmoe and the password you choose.
The problem is, Joe Schmoe is the RH Contact Name, not the Drupal username. The token used by the system in the email for this value is [user:name]. Consequently, the test user could not login following those instruction because his Drupal username was something else.
Additionally, when I go to "People" to see a list of Drupal users, the name in the first column, labeled Username, is Joe Schmoe, which is not his username.
Any ideas?
Comments
Okay, Sorry, Solved
I see that I had set "Display username as contact label" in RedHen config without realizing what it really did. I unset that. Next question: Why would anybody want to do this?
This is what I'm trying to do too!
I am trying to understand how to do the task that is the basis of your question.
HOW do you integrate Drupal user registration with RedHen to capture RH info during signup?
Should/Can the RH contact types have many custom fields of different types?
Does RedHen replace something like Profile2 or work in conjunction with it?
I also want to connect signing up for a membership on the site with making a payment for that membership, and this resulting in user role assignment.
I've seen more than one thread like this one:
https://www.drupal.org/node/1693182
that asks about using RedHen for paid online memberships. The answers to these and other threads seems to eventually be "You can do it but you'd have to hand code it."
go to
go to /admin/structure/redhen/contact_types
and add a contact type. once you create your default contact types you can add required fields and RedHen will automatically add those fields to user sign up form.
To sell memberships and integrate with RedHen you need
Drupal Commerce
Commerce License
RedHen
RedHen Memberships
RedHen Memberships integrates with Drupal Commerce and Commerce License nicely to sell memberships. I have it running pretty smoothly on my site now with no hand coding required.
Once all modules are installed
You configure the settings for RedHen and memberships at /admin/commerce/config/redhen
I have two profile types configured using Profile 2 (student member and licensed instructor). I found that RedHen fields replaced my need for one of my profiles types (student member) but not both (at this point anyway).
I'm actually curious if I can replace both using RedHen fields.
I'm stuck on getting users to be required to complete the RedHen fields as part of the checkout process...
discipline, concentration & wisdom
-----------------------
Twitter - @luoyegongfu
Facebook - /svn7svn
This is very helpful, but...
Thank you for your help with this.
You said:
So I added a bunch of fields to a new "Full Member" Contact Type.
Most of the fields I added are simply text fields, though I did add a "Postal Address" field.
But when I go to Create New Account (/user/register)
I get the following:
Warning: array_key_exists() [function.array-key-exists]: The first argument should be either a string or an integer in redhen_contact_form_user_register_form_alter() (line 1021 of .../sites/all/modules/redhen/modules/redhen_contact/redhen_contact.module).and
Invalid RedHen contact type parameter.And the User Account creation is the standard "Username" and "E-mail address" form.
So the new account appears to be trying to use my RedHen Contact type but is hitting an error. Any ideas why or how I can track it down?
The line(s) referenced in the error:
if (array_key_exists($contact_type, redhen_contact_get_types())) {
$contact_object = redhen_contact_create(array('type' => $contact_type));
module_load_include('inc', 'redhen_contact', 'includes/redhen_contact.forms');
// Get contact type form.
$form['redhen_contact'] = array(
'#type' => 'fieldset',
'#title' => t('%type Contact information', array('%type' => ucfirst($contact_type))),
'form' => redhen_contact_contact_form(array(), $form_state, $contact_object),
);
Also, what is the difference between a RedHen Membership type and a Contact type?
Now it's working
After a couple days of this not working, it is now working as expected: The fields I created for the RedHen Contact Type are part of the new user registration form.
The only thing that is different is that I just now added and enabled the Profile2 module. Is this a requirement for RedHen to work like this?
there's no dependency on
there's no dependency on Profile 2 with RedHen.
maybe you just forgot to run the update after installing a module or needed to let cron run for some reason?
discipline, concentration & wisdom
-----------------------
Twitter - @luoyegongfu
Facebook - /svn7svn
RedHen contact is just that,
RedHen contact is just that, similar to the contacts in your phone for example. Basically an address book entry.
RedHen membership type is the entity for the different kinds of memberships you might use on your site.
So for instance in my case, our site creates a RedHen contact entry for all registered site users. EVERYBODY goes into the address book, but not everybody belongs to the membership groups, of which there are two;
student members
licensed instructors
only after paying the membership fee (in this example) is a "membership" of the appropriate "membership type" created for the contact, along with the start and expiration dates, etc.
Hope this helps.
discipline, concentration & wisdom
-----------------------
Twitter - @luoyegongfu
Facebook - /svn7svn
So your contact type holds all info
Thank you for the continued help, svn7svn. This is very helpful!
But I'm still trying to sort out what fields go where and how to have them filled out by the members.
The site I'm building is to have three different types of memberships for a professional organization.
Associate Members
Full Members
Student Members
I need to collect the same basic data from all three (phones, physical address, reason for applying for membership). So I'm using the Contact type for this data/fields.
But each type of membership will also require me to capture additional info for that type of membership. And the idea is that every person creating a new account is actually requesting either the Associate or the Student Membership.
Later on they can apply for a Full Membership, if they have paid dues and are in good standing.
So, I'm curious how to collect the distinct membership info. And how to offer two types of memberships to new users (Student or Associate).
Is a Membership Type in RedHen something for which you can have the user fill out the fields? I see that you can administratively add different memberships to existing contacts and administratively add the Membership Type content at that time, but what if you want the applying member to fill those fields out? How do you give them access to those fields?
When I create a test new user, they can edit the "RedHen Contact" fields, but there's no where for them to add a membership.
I've got it set up like this:
RedHen Contact Type (currently used for Drupal Registration)
First Name
Middle Name
Last Name
Mailing Address (several fields)
Telephone
Cell Phone
Special ID # (all prospective members will have this)
Organization
Title
and the "Create New Account" page now collects all this info and creates a new RedHen Contact/Drupal user. This is great!
But I think I really want the new account tool to be the "Associate Member" or "Student Member" application. And also have those several additional fields unique to the Associate/Student Members (including a statement of intent as to why they want to become a Member).
And then later they will be able to apply for Full Membership...
And I'm afraid I don't see how to connect all this to the Drupal Commerce payment for memberships.
I followed the link you offered (/admin/commerce/config/redhen) for setting up the RedHen memberships in Drupal Commerce but there wasn't anything there that connected to the RedHen membership types. Do I need to make a product in Commerce that matches the membership types?
I found "admin/commerce/licenses" but it is looking for input of users, as if it requires you to grant users a license administratively.
Can you use rules to switch on memberships for Users/Contacts once their payment has been processed?
Using different RedHen Contact Types for registration
If I'm understanding your question about replacing Profile2 with RedHen, I think I may have found the answer. You can use multiple RedHen Contact Types for user registration.
On the RedHen CRM Settings page (admin/config/redhen/crm), under "User Registration" there are several settings:
__ Create a contact during user registration
Default Contact Type (with drop down select menu)
and below that the help text says:
Select the default contact type to create during registration. This can be overriden by appending the contact type machine name in the registration url.
So I tried
user/register/associate_member
and
user/register/full_member
and, sure enough, the new user registration forms were based on the Contact Type in the URL.
I hope this is helpful to you, as you have been a great help to me.
I'm not sure how you would
I'm not sure how you would use that in a functional way though, particularly since I most need to collect the information as part of the checkout process.
discipline, concentration & wisdom
-----------------------
Twitter - @luoyegongfu
Facebook - /svn7svn
Yes you need to create the
Yes you need to create the product, then you can select which product types the membership is attached to.
Commerce License should have already provided two rules that activate a license once the checkout process completes.
I'm in contact with Thinkshout now to see what it will take to develop the RedHen membership module to integrate more deeply with Commerce so you can collect specific membership information as part of the checkout process (and leave it exposed to users to update)..
You can create a custom checkout screen and add fields to it, but the entered data doesn't get mapped to the coresponding fields in RedHen. My assumption right now is you should be able to do it with Rules, but I'm not that good with Rules right now. Getting the right data selector can be a royal PITA.
When I hear back from Jaden I will let you know. RIght now it seems like my individual project is going to be too small to interest them, but if I get a specific price point, maybe we can combine resources to get it done.
Personally I'm thinking this is a no brainer as far as RedHen development is concerned. This is definitely functionality other users will want / need moving forward.
discipline, concentration & wisdom
-----------------------
Twitter - @luoyegongfu
Facebook - /svn7svn
RedHen membership / payment / commerce integration
I think there is plenty of interest in an official implementation of what you and I are looking for.
My ideal would look like this:
Then at a later time the Associate Member may decide to upgrade the membership to "Full Member" and that would look like this:
Please do let me know what you hear back from Jaden about this as I may be interested.
Thank you.
it looks like we may need to
it looks like we may need to organize some kind of crowd funding campaign to fund development...
discipline, concentration & wisdom
-----------------------
Twitter - @luoyegongfu
Facebook - /svn7svn
Do you mean that you heard
Do you mean that you heard back from the developer(s) and they have given you a high price tag for implementing this? If so, what is that price tag?
I know RedHen was developed as a Drupal integrated alternative to tools like CiviCRM, but I'm not seeing enough support for RedHen to make me feel comfortable fully committing to it.
My queries to the developers of Open Outreach about RedHen tools is to point me to RedHen issue queues.
There are old posts (2 years ago) by RedHen developers promising imminent work on more robust membership tools, but I can find no updates on this work.
https://www.drupal.org/node/1693182
https://www.drupal.org/node/1687848
(Both of the original posters in those links mention CiviCRM as problematic, but I think it can manage the things you and I are trying to do.)
Furthermore, the RedHen site itself links to Thinkshout for case studies, but it's a dead link:
http://redhencrm.com/#case-studies has a "Read the Full Story" link for the Mission Investors Exchange, but it goes to a 404 error page.
There are a number of articles about RedHen on Thinkshout's website, but most are from two or more years ago, when it was introduced.
And this page that promises a video tutorial of setting up RedHen has a dead video link:
http://thinkshout.com/blog/2013/05/gabe/zen-and-art-farmyard-maintenance/
All of this leaves me concerned that RedHen was a project at ThinkShout a couple of years ago but interest and support for it have waned as people moved on to other projects. Or perhaps it was simply meant as a tool for more sophisticated Drupal developers than I, since there are suggestions in some of the comments that the OP should build something themselves that solves their question.
RedHen is an active project
Hi Christopher,
I am one of the maintainers of the RedHen project.
The project is active, as evidenced by its commit log:
https://www.drupal.org/node/1068848/commits
14 developers have contributed to the project in the last year, less than half of which work at ThinkShout.
The project's issue queue, as well as this thread and the community support provided by svn7svn therein, also reflect that this is a very active project.
But it is also an admittedly complex piece of open source software. Keeping up with support requests and community documentation on a project of this scale, with a large user base (900 reported installs), is challenging. We use RedHen on 90% of our projects, which financially supports the commits that you see, as well as exciting innovation such as:
https://www.drupal.org/project/redhen_donation
as well as our forthcoming release of an open source crowd fundraising platform built on top of RedHen.
But unfortunately, as a business, we don't always get to spend as much time as we would like volunteering time to help community members leverage these tools on their own projects. Our intention is not for RedHen to be a developer-centric solution. We've worked hard to build it such that Drupal site admins can configure it to meet sophisticated requirements without writing code. But our focus here at ThinkShout is on those underlying engineering efforts.
We are very grateful to folks like svn7svn who help people work with these tools. We will continue to do our best to help folks via the issue queues and forums as well. But it's sometimes hard to keep up!
Good luck moving forward. The membership tools in RedHen are really powerful, powering small sites as well as large enterprise "association management solutions."
Cheers,
Sean
Thank you
Thank you for your reply, Sean!
I am glad to hear that RedHen is still being actively maintained, (which I realize I could have figured out if I'd gone to the commits myself...Sorry.).
And I fully understand and appreciate that the work of maintaining a Drupal project is volunteer time and I appreciate the generosity of all the people who work on Drupal projects and RedHen in particular.
My comment was born out of frustration at finding so many dead ends as I tried to figure out how to do things with RedHen.
For one, it seems many of the discussions on RedHen issues seem to end with a RedHen developer saying "Just write your own custom module to fix that." or stuff about "glue code."
And others have had concerns about the documentation for RedHen (https://groups.drupal.org/node/419813, for example). And that post has a link to the Vimeo video that I noted was missing in my comment above.
And yes, I greatly appreciate svn7svn's help in this thread. He has provided some of the instruction I could not find in the RedHen documentation. But I think he and I have both hit the same wall. He says he's trying to "collect specific membership information as part of the checkout process..." but that, as far as he can tell there's currently no way to do that and no time to develop something like this by the maintainers.
Again, to be clear, I greatly appreciate and value the work you and others do, and understand that you cannot address specific needs as they arise. But if the needs I have can not be addressed, then obviously I need to use something else. Or if the answer is "Write your own custom module to do that. It shouldn't be too hard." then I have to use something else since I don't have comfort writing my own module for a production site.
I really hope I'm not coming across as whining that you aren't fixing my personal problem. I don't mean it that way at all. I know I've asked other questions in other threads about how to proceed, but have tried to ask respectfully and after trying to work it out myself.
What I'm trying to say here is that, practically, if I can't do what I need to do and I can't find help to figure it out, then I need to find another solution (CRM Core? CiviCRM?)
And my point was to say it seems there are apparently others like me who want to use RedHen but have run into problems with missing or incomplete documentation or missing functionality.
I learn better with tutorials and examples, and it seems most of the current RedHen documentation is lists of the settings in a given RedHen feature and what they do. So, while that may be enough for some people to get up and running, it's not always clear to me how to combine the various features together from that info.
I did install and play with the demo (Pet Shelter), but it's still not clear to me if users can enter fields for their own membership info or if an admin has to do that. Or if it's possible for a user to be switched from one contact type to another (e.g. if a volunteer becomes a staff person).
Once again, thank you for your work on RedHen.
Christopher
Thanks, Christopher!
RedHen has been designed to be a good citizen of the Drupal ecosystem. It leverages the Entity API and makes affordances to ensure that it plays nicely with tools such as Features, Views, and Rules, so that non-developers can build robust CRM solutions on top of it.
Our focus in on the development of the underlying infrastructure that can make that happen. As a team, we prefer to write small "glue modules" to address use cases such as those you reference from the issue queue. This is because we feel that 20-50 lines of well documented custom code is more maintainable for our clients than solutions that are based upon complex configuration of modules like Rules and Views. As you've probably encountered, it's difficult to document such configuration when building a site. Features exports, for example, are large and monolithic and don't lend themselves to inline documentation.
So, in recommending custom code, we're recommending the approach that we know. While we're confident that you could do much, if not most, of what we do in code with tools like Rules, we would need to work out those solutions from scratch ourselves to provide recommendations beyond writing code.
We feel that RedHen has been designed to balance the interests/needs of grassroots organizations and site builders with those of enterprise teams and software engineers. Our clients are more the latter. We build very large, complex solutions that use RedHen as a "social CRM" front-end to enterprise CRMs such as Salesforce. While it's not the only option, it works well for both use cases.
Please consider contributing your own documentation to make RedHen better for the community at large. And good luck in your work!
CRM Core Membership?
CRM Core Membership is still in sandbox, but under active development:
https://www.drupal.org/sandbox/pingers/2340901
From the linked page:
BUT...
I was just looking for more information about CRM Core and came across this video:
https://vimeo.com/38915693
Which ends with "In upcoming videos, we'll show you some of the practical applications built with CRM core as well as show how to extend CRM Core's basic functionality to create useful features."
That was two years ago and no videos have been posted to that account since.
But there are some vimeo videos under another user about CRM Core Petition:
https://vimeo.com/user14457607