Push account updates to Recurly contact information

The account page could offer a way for users to edit/update the information associated with their Recurly account, maybe even set their preferred language. The other option is to use hook_user_update.

I think the ability to edit/update account information is essentially the same as update billing information, is it not? Users can already update their information through #1627930: Introduce RecurlyJS module for updating billing information/subscribing, but of course they also have to update their credit card at the same time. I'm not sure updating contact information independently is really a necessary option, or if we did, we should use hook_user_update() like you suggest.

Setting preferred language seems like it should definitely just be pulled from Locale module.

Just that the email address needs to be taken into account. If a user changes their email in Drupal, I think we have to change it at Recurly due to the dunning process.

Good thinking, I hadn't thought of that.

One other thing to note is the idea of tokens that we can use to customize the Recurly emails that go out as described in the Recurly docs, especially when it comes to providing links to their account.

I also hadn't thought of that; glad you're around! :D

This makes me think that my approach of setting the "account_code" to be something like "user-1" could cause problems generating links to Drupal user accounts. In order to work we'd need to provide some redirect URL on the Drupal side (which honestly would probably be a good idea anyway). Something like http://example.com/subscription/account/[account-code], which would load the record from the recurly_account table and redirect to the proper Drupal user URL, http://example.com/user/1/subscription. Then we wouldn't be dependent upon our account codes lining up at all between Recurly and Drupal.

To handle the syncing of data over to Recurly, I think the best approach would be to pull out text values of fields and send them over to Recurly. I suggest handling this configuration through tokens, with each Recurly field mapping to a particular token. This approach is both more flexible and more likely to fit with most configurations of user accounts than a straight "Recurly field to Drupal field" mapping. The reason being a lot of fields in Drupal potentially contain multiple pieces, such as an addressfield, which would need to be split into address1, address2, city, state/province, zip, etc. Using tokens these could be pulled out easily such as [user:address_field:address1]. Additionally tokens would give an extra power to situations where the "account holder" on Recurly is not the same as the Drupal user account. For example you could have a subscription bound to a node, and then have the author of that node be the source of contact information in Recurly by using a token like [node:author:mail].

I'll look into this syncing business later today and see what this looks like in code.

Also do you see any sense in doing a module_invoke_all on the creation of the account code or does that break everything? My original thinking as you may have noticed was to have an admin setting for a prefix for cases where several different sites are using the same Recurly account and you need to distinguish between them. So setting the prefix you may end up with for example site1-subscription-1 and site2-subscription-1.

How about we simply make a settings.php "hidden variable" for setting the "recurly_prefix", similar to a database table prefix? I wouldn't want to make it a UI option, considering if you ever changed your recurly prefix, it'd have far-reaching effects (you'd need to update all your newly created Recurly accounts for example). As with any setting, you could define it in settings.php as such:

$conf['recurly_prefix'] = 'sitename';

I think having a hook for the creation of the account code would be fine, since it doesn't really matter what the account code is, just as long as Drupal can map the account code to a user/entity. Alternatively you could insert the row into the recurly_account table directly to provide the mapping manually, that might actually be a cleaner approach than some kind of hook.

I'm not quite sure what you mean by account code not being unique (because users can have more than one subscription). That seems confusing to me because users can already have more than one subscription per account (but not two of the same one).

One other non-issue for me but I thought about is what if users who already have Recurly subscriptions (and their own account codes) want to migrate to Drupal use this module. It's kind of a far-reaching task to provide this but something that may come up.

I think the convention of using "$entity_type-$entity_id" as the account code is really only relevant for the creation of new Recurly accounts, and really only applies to using the "managed_pages" module, since that's the only situation where you don't have any idea what Drupal user account was associated with the Recurly account_code. Once the record is made in the "recurly_account" database table, the format or contents of the account_code become largely irrelevant. So a user moving to this module after having used Recurly beforehand could simply query Recurly for all accounts, and do whatever mapping made sense to get them into the Drupal "recurly_account" database table. There's no need to update the account_code in Recurly, the only thing we need is the mapping.

This patch adds the basics of account management through tokens. So far it only concerns itself with Contact information on the account and not with billing information. I couldn't rationalize pushing billing information to Recurly, since the billing information is likely bound to the credit card information.

In any case it's a good start and solves the basics of the problem in an easy way. Patch contains a little cleanup to RecurlyJS module that I encountered while updating recurlyjs_menu().

In order to work we'd need to provide some redirect URL on the Drupal side (which honestly would probably be a good idea anyway). Something like http://example.com/subscription/account/[account-code], which would load the record from the recurly_account table and redirect to the proper Drupal user URL, http://example.com/user/1/subscription. Then we wouldn't be dependent upon our account codes lining up at all between Recurly and Drupal.

I opened an issue for this: #1643720: Provide an account_code to Entity redirect URL