Allow to attach a points field to any entity and migrate the current hardcoded assignement to users

Yeah, I never said that this is going to be easy. :)

I'm not sure if having generic EntityPointsTransaction class helps because SQL doesn't support something like that and we'd need multiple tables.

So yes, we will need to change uid in the transaction to something like entity_type/id. The thing is that this already exists, so we either need a new name or rename the old one. Entity Reference doesn't work, because that's limited to a single entity type per field. Relation technically would, but then we have yet another entity and table inbetween.

Additionally, this is already related to the "replace tid with bundles" issues, because we then have two different ways of separating transactions: a) multiple transaction bundles, and b) multiple fields to which they are assigned.

So, my suggestion at this point is the following, let's split this issue up into two separate tasks:

1. Use a field to store the points total.
2. (Later on) Make it possible to assign such a field to another entity than user.

The first point has already enough conflict potentation, especially with #1258026: Implement userpoint bundles. We might want to split that one up as well and first remove the current categorization (and replace with a taxonomy term reference field if it's currently used), then implement 1. here and then look into making it entity type agnostic and add bundles.

The advantage of that is that we currently have two tables to store userpoints totals, one is the overall total and one is per category. The per-category one would be removed, which would make it easier to replace the other one with a field.

Not sure yet if it should be userpoints + userpoints_user or uerpoints_field + userpoints. It can't be in the same module due to dependencies, is that correct?

Given that, I think having userpoints_field and depending on it makes more sense. Enabling Userpoints should get you the default experience and if you want something more advanced, then using the default field UI sounds fine to me. That will, for the moment, also allow us to directly set the values for it in the userpoints transaction storage controller.

Nice start, but there are some interesting problems ahead, like the whole categorization thing, as discussed before, it might make sense to remove that first.

+++ b/userpoints.transaction.incundefined
@@ -1430,3 +1431,22 @@ class UserpointsTransactionMetadataController extends EntityDefaultMetadataContr
+  public function views_data() {
+    $data = parent::views_data();
+
+    $data['userpoints_txn']['uid']['relationship'] = array(
+      'title' => t('User'),
+      'help' => t('Relate the userpoints transaction to the user.'),

That relation should be created by default if uid is set to type user?

+++ b/userpoints_user/userpoints_user.moduleundefined
@@ -0,0 +1,63 @@
+  foreach ($result as $record) {
+    $item['points'] += $record->points;
+    $item['max_points'] += ($record->points > 0) ? $record->points : 0;
+  }

That is not correct* and doesn't scale. Have a look at the update total logic in the storage controller to see what needs to be done here.

* It makes the same mistake as the earlier max points implementation. Once you have negative points, the max is a "sum of all positive transactions" and not "highest point amount the user ever had" anymore.

Looks interesting, some thoughts below.

+++ b/userpoints.installundefined
@@ -273,6 +273,28 @@ function userpoints_install() {
+    'label' => st('Points'),

Points branding is going to be an interesting challenge, we might need to implement some alter hooks so that the field label is changed to whatever is configured in the backend (later even field settings).

+++ b/userpoints.moduleundefined
@@ -608,6 +608,101 @@ function userpoints_token_info() {
+  if (isset($account->field_userpoints['und'])) {
+    foreach ($account->field_userpoints['und'] as $num => $values) {

should use the LANGUAGE_NONE constant. Wondering if we can prevent this from being made translatable, that's going to result in an interesting mess.

+++ b/userpoints.moduleundefined
@@ -608,6 +608,101 @@ function userpoints_token_info() {
+  user_save($account);
+  $account->field_userpoints['und'][$delta]['points'] = userpoints_transaction_get_points($account->uid, $entity->type);
+  $account->field_userpoints['und'][$delta]['bundle'] = $entity->type;
+  $account = user_save($account);

Not sure what you're doing with user_save() here exactly :) A user is usually saved like this: user_save($account, (array)$account). entity_save('user', $account) should take care of that weirdness?

Also, I still don't understand why this is separate from the existing logic to calculate the total that happens in in UserpointsTransactionController::updateTotals(). That's IMHO the right place for this.

+++ b/userpoints.moduleundefined
@@ -608,6 +608,101 @@ function userpoints_token_info() {
+function userpoints_transaction_get_points($uid = NULL, $type = NULL) {

Then you don't need this anymore, as we already have (quite complicated) points and max points calculation there.

+++ b/userpoints_field/userpoints_field.installundefined
@@ -0,0 +1,31 @@
+ * @file
+ *   Userpoints field schema and installation.

There shouldn't be additional spaces before the @file description

+++ b/userpoints_field/userpoints_field.moduleundefined
@@ -0,0 +1,181 @@
+      if (!isset($item['max_points']) || $item['points'] > $item['max_points']) {
+        // Set maximum points only if current points is greater.
+        $items[$delta]['max_points'] = $item['points'];

Again, we already calculate this in updateTotals(). The calculation is currently more complicated due to the special 'all' category, can probably be simplified once we remove it.

+++ b/userpoints_field/userpoints_field.moduleundefined
@@ -0,0 +1,181 @@
+      '#prefix' => '<span>' . check_plain($types[$item['bundle']]->label) . ': </span>',

Hm. Not yet 100% sure how points label branding/field label/bundle label will play together.

Using the bundle label as branding might probably make the most sense but what can we do if there is none available (for generic descriptions and so on).

Also, translations, this will need to be translatable somehow. Either i18n_string or entity/field translation.

+++ b/userpoints_field/userpoints_field.moduleundefined
@@ -0,0 +1,181 @@
+    'bundle' => array(
+      'type' => 'token',

Hm, this could actually use the entity type as type?