Establish a process for copying data from fields on Backdrop users to fields on CiviCRM contacts.

[jenlampton]

We'll eventually want to move some of the field data from user profiles into civi records instead. Once this is done, we'll want to delete the old user fields and expose the civi records on the user edit form at the same time so that users aren't presented with duplicate form fields.

[bugfolder]

We can categorize fields that appear on the user/register form as follows:

• Backdrop user account fields that will stay as user account fields;
• User account fields that should be moved into CiviCRM (as a built-in or custom data field, and then they will appear in a CiviCRM Profile on the user register form);
• Existing CiviCRM fields that we want to start collecting on the user register form;
• New CiviCRM custom fields that contain data we want to collect.

The last two items aren't technically part of this issue, but I think we should be addressing all of them together. I'm going to start by addressing these categories individually.

[bugfolder]

The list of Backdrop user account fields can be seen here: https://beta.backdropcms.org/admin/config/people/manage.

Right off the bat, I would say that MOST of them can stay user-account-only, with these exceptions:

• Full Name — should be moved into the CiviCRM "Last Name" existing field.
• Location — should be moved into the corresponding CiviCRM address fields. However, Civi requires addresses to be classified as "home", "work", etc. We'd need to make a choice or assumption to move this automatically.
• Receive BackdropCMS.org security announcements for core and contrib projects — should be moved to indicate membership in a CiviCRM mailing list group. (We should be using Civi mailing groups for all such mailings.)

Other possible user account fields to consider:

• Website(s) — this user account field accepts multiple website links. Civi has a built-in "Website" field that can accept multiple sites (which must be classified as "home", "work", etc.). Perhaps we should try to move this information over, though it doesn't seem like a high priority item.
• Gender — Civi only has 3 offerings OOTB, while the user account field provides 6 possibilities. We can add types to the Civi setting, but Civi presents as radio buttons, while we allow checkboxes (multiple selection).

We might want to consider still more fields to move, but I think we ought to identify how we would use that information before expending the effort to figure out how to move it.

[bugfolder]

For existing CiviCRM fields that we might want to start collecting, possible ones to consider:

• Employer
• Job Title
• Phone (can be classified as home, work, billing, etc., and also by type: "phone", "mobile", etc.
• Privacy settings (very important to collect!). Do not phone, email, mail, sms, trade, and the nuclear option, "NO BULK EMAILS". If a user has the last one selected, CiviCRM WILL NOT send mailings to them, even if you include them in a list.
• Date of birth
• IM Screen names — the built-in values are pretty old (Yahoo, AIM anyone?), but we could easily add Slack, Zulip, and other service providers.

For all these fields that we add to the user registration page, we should be very clear about which ones are and are not going to be exposed to other users (and in general, most should be private).

[bugfolder]

One of the CiviCRM fields we'll want to make use of is the "Groups" field. We can define mailing list groups willy-nilly, which people can choose to be a part of to receive mailings on a specific topic. (The groups are for centrally-sent mailings; they're not like Mailman lists or Google Groups, where a member can send in an email that gets reflected back out to everyone in the group.) So Groups can be used as an expression of interest in various topics (Volunteering, BDLive, etc.).

[bugfolder]

Gender: consider not using built-in CiviCRM gender, instead create custom gender field that exactly mirrors Backdrop's (allowing multiple selection).

[bugfolder]

Comments from the Civi meeting 3/14:

• Tim: we only want to track information we have use for; not sure we have a use for Employer field unless we've got a directory of Backdrop workplaces
• Tim: we have things about who's a contractor, etc, not sure we're using that data well, it's displayed on a view, quite possibly out of date. Will Civi help us keep that info up to date? Figuring out how we're using that data and whether it's part of Civi is interesting.
• Tim: groups we might need: Newsletter, Events (notification of events); how do groups fit in with volunteer roles? If someone's saying they can do design, is that a group or...?
• Eric: saw a discussion about CiviVolunteer, which operates on top of groups. Suggest thinking about groups for almost all of these things.
• Consensus: most of the Backdrop fields can stay in Backdrop unless we're planning to use that specific information. We can always import that data later into Civi if we need it. (We'll already need some custom importer code, maybe?).
• Spam: there are LOTS of spam accounts created on b.org. Those will create contacts? in Civi. What are we going to do about that? Probably a bigger issue of spam users on b.org, many of us doing it in different ways, would be helpful to have a set policy.
• Tim volunteered to help reactivate the SPAM issue in the Backdrop CMS github issue queue. Spam accounts on backdropcms.org #815

[bugfolder]

2022-08-16. CiviCRM on beta.b.org is updated to version 5.52.2 (the current version). I've spent some time exercising a local version of beta.b.org, discovered a few gotchas, but basically have identified most of the steps of a process for integrating Civi. Here's the high points, in preparation for the next Outreach meeting.

What fields to move from Backdrop user accounts

• The bare minimum would be the "Full Name" field, which we would map to the CiviCRM "Last Name" field (leaving "First Name" and "Middle Name" blank).
• We could also move the "Location" fields, which have logical mappings to CiviCRM address fields. If we did that, then a summary of the fields to move would be:

1. Full name (which will become Last Name in CiviCRM; First Name will be blank.)
2. Email address
3. Street
4. City
5. State
6. ZIP code
7. Country

Synchronize Backdrop user accounts to CiviCRM contacts

See here in the User Guide.

Go to CiviCRM > Administer > Users and Permissions > Sychronize users to contacts. This will create contacts for all user accounts, but that doesn't include the user account fields from the user accounts; we'll have to import that information in a second step.

We have >5000 accounts (the vast majority of which were created by spammers over the years). This command is not executed as a batch process, so running this command from the UI ran into max_execution_time errors. A workaround on my local was to do this:

• Set max_execution_time = 5000 in php.ini
• Run drush civicrm-sync-users-contacts

Export user account data from Backdrop

To get the rest of the Backdrop user account fields into CiviCRM, we start by exporting that information via a View.

• Install Views Data Export module.
• Create a View, Users to CiviCRM to export a CSV table consisting of these account rows:
  • Email
  • First name (use Global Text, leave blank)
  • Full name (label = Last Name)
  • Street address
  • City
  • State
  • Postal code (label = Postal code)
  • Country
  • Uid (label = External identifier)

Save the resulting page as a CSV file.

Import user account data into CiviCRM

Import from the file into CiviCRM at CiviCRM > Contacts > Import Contacts, with:
* For Duplicate Contacts: Update
* Dedupe Rule: Email (reserved) - Unsupervised

This will put the User account fields into the right corresponding contact records.

There are 229 import errors (which will be skipped) when we include full location information. By far the majority of them are spam accounts from Vietnam (and many also have problematic names). A very small number might be "real", though. Nevertheless, skipping these records will just leave their CiviCRM information blank (beyond their names). So no harm in skipping them (even if there are a few non-spammers tucked away in the group). If they belong to a real person, that person can fill in their data fields if they ever edit their user account again.

This is done using the batch processing, so it should in principle go through in a single run without timeouts, but some of the individual steps still issue timeout errors after 30 seconds on my local site.

But we can reduce the batch size. In file civicrm/CRM/Parser.php, function CRM_Parser_Import::queue(), set $batch_size = 20 instead of the current value of 50 and re-start the import from scratch.

Permissions

There is a new role, "Civi Admin". Need to give that role all CiviCRM permissions.

Question: currently "Developer" role has many Civi admin permissions. Should these be removed from this role?

Need to give "Authenticated" the "View my contact" and "Edit my contact" permissions.

New registration page

CiviCRM automatically creates a Profile for the user registration page, containing:

• Email (primary)
• Full Name (Individual)
• Street Address (Home)
• City (Home)
• Postal Code (Home)
• Country (Home)
• State (Home)
• Group(s)

We can/should remove the corresponding User account fields (Location group) after copying the data into CiviCRM so that we're only collecting this information once.

This profile information is displayed by default on the user page. It is visible to the user, but not to other authenticated or anonymous people (per the permissions above).

A somewhat user-unfriendly aspect is that this profile information is on its own edit page, which will be at http://beta.backdropcms.org/user/%/edit/name_and_address, accessible via a "Edit Name and Address" link on the view page, but not via the Edit tab (which is where I would expect it). And it has the admin theme (Seven), rather than the public theme, like the regular user edit page. It would be nice if the profile edit page were a sub-tab of the user edit page, so implementation of that is still TBD.

What's next

If everything as described above is acceptable, I will make these changes on beta.b.org so that people can kick the tires of the user registration, profile, and profile edit pages.

[bugfolder]

I've made these changes now on beta.backdropcms.org:

• Created CiviCRM contacts from Backdrop user accounts
• Exported Full Name and Location fields from user accounts and imported them into their corresponding CiviCRM contacts
• Removed the Full Name and Location fields from the user account (since they're now in CiviCRM)
• Edited the View block that shows up in the sidebar of the user account page to remove the Location text (since the corresponding field is now gone).
• Gave "CiviCRM Admin" and "Developer" roles full permissions to do anything on CiviCRM
• Gave "Authenticated" role the permission to view and edit their own contact information

There is a CiviCRM profile for the name and address information, which shows up on the new user registraition form at https://beta.backdropcms.org/user/register. It needs some CSS for visual compatility.

The "Name and Address" profile from CiviCRM shows up on the user account page at user/N. There is also a link to "Edit Name and Address", which leads to an edit page for that profile, which is at user/N/edit/name_and_address. Note that this page is rendered in Seven theme, while the main user edit page at user/N/edit is rendered in the frontend theme.

Please poke around, kick the tires, etc.

[bugfolder]

This is now done on b.org.