Port User Points to Drupal 8

Subscribing

If this is ported to Drupal 8, then probably it can be used to gamify Drupalladder.org as part of this project: Migrate DrupalLadder.org to Drupal 8 @ GSoC 2014

Created a git repo here:
https://github.com/badri/userpoints

Thanks for starting, but please start based on the official repository instead of creating a new one. Just do a git checkout, create an 8.x-1.x branch and then push to github. Probably re-create the repository there first.

subcribing

Is this D8 port still ongoing? Where is it on github?

Some major changes were discussed here #1258032: Allow to attach a points field to any entity and migrate the current hardcoded assignement to users

Perhaps the module for D8 should sit at drupal.org/project/points and provide a migrate path from the D7 module.

I worked with two other people to re-write the Points module from scratch on D8, with the direction that Points can be attached to any entity.
The module is at Points. The feature of Points moderation is not included at the moment; the plan is to take advantage and fully integrate with Drupal 8.3/8.4 core workflow module.

Any help with testing and bug reporting will be appreciated.

Currently working on this. It will take a few weeks.

Assuming that @cribsb is no longer working on it after 2 years of no activity.

Marked as Active since points module is an alternative to user points, not really a Drupal 8 porting of it.

The reason that Points module work with any entity instead of just user entity is to follow the idea in #1258032: Allow to attach a points field to any entity and migrate the current hardcoded assignement to users. Comparing to the Drupal 7 version, there are a few views, forms (or upgrade path) were missing, but that doesn't mean it's very hard to add.

@manuel.adan I'd appreciate if your effort will be spent in collaboration, or offer a plan on how would you implement a D8 version of user points that is different from Points module.

@skyredwang in few words, the plan to accommodate all the requirements is a 3-layers design:

1. a base module for transactions with basic functionality
   provides a generic transaction framework, the hard work is done here
2. a functional module (might be just a plugin) for balance-type transactions
   provides balance transactions for any kind of accounting. This is the one to use over any entity type
3. the userpoints D8 module based on the balance transactions module
   provides the same functionality as current D7 does, specific for users

As soon as I have some work finished I'll comment here.

I just published the first -dev release of the new transaction module. This module provides multipurpose transactional flows linked to any content entity type. Initially, two transaction types are provided, a generic one, just for tracking systems or to be used as a base, and another for accounting transaction flows.

Transactions is a more generic idea than points. It can be used for a wide scenarios, such as stock control, tracking systems or workflows.

As mentioned, the idea is to base the D8 version of userpoints on this generic module. As a first -dev, there is still work to be done in transaction module before to start with userpoints, but as soon as an alpha version is reached, a 8.x-dev version of userpoints could be released.

I'd appreciate any testing or suggestion of the transaction module.

@manuel.adan and @skyredwang

Would the two of you be willing to collaborate with each other to make a module with the best of both projects?

To me it seems that the the best way forward would be a common points module based on Transactions (like the upcoming D8 UserPoints) that could be attached to any entity (like Points).
A module like this could easily also provide the functionality of Commerce Credits.

It could be 3 modules in one project with more contributors instead of 3 separate efforts, each with their weaknesses.

We have two type of requirements, the common to any accounting / transactional system, and those specific to a use case.

The common requirements should be provided by a base or generic module. That is the purpose of the new transaction module. But a generic module, like points or the new transaction, can not fit the specific requirements that, in this case, the userpoints module has. For instance, user roles or account states (blocked/active) are particular features only applicable to users that any points module must to work with.

The key principles for the transaction module are:

-> custom logic
the transaction process itself is backed by a transactor plugin. The transactor is where the data process and validations are carried out. It has particular settings and options, defines the fields it needs, it composes the transaction description, details and execution result code / message, etc.

-> usage of standard fields to store the transaction data
standard fields are fully supported, they make use of any core or contrib formatter or widget, have multilingual support, views integration, etc. In addition to that, site builders have total control over them, they can set a custom field name, reuse existing fields (prices, etc). That makes transaction versatile and adaptable to multiple scenarios

-> do not touch the target entity type
there is no need for extra fields in the target entity, it remains intact since the data source is always the transaction flow. That also prevents the target entity from depedending on the transaction system. However, transactors can work with the target entity, for example, to reflect the current balance in a numeric field or update a reference to the last executed transaction

-> transaction driven
the work is done in the transaction flow, not in the target entity. For instance, an user points credit is done by creating a new transaction. Pending / applied points is supported by the transaction execution state (pending / executed)

-> fully multilingual
the transaction description must to be multilingual (which is not the same as translatable). The transaction description, details and the execution result message are generated by the transactor, optionally with tokenized templates from transaction operations

-> multiple point types/accounts
not just a single points account. D7 version of userpoints has categorization by taxonomy term, but this is not a real different balance, just a classification of movements

All of this is present in the just released 8.x-1.0-alpha1 of transaction. Pending features are:

-> revertible support (generate a transaction that reverts a previous one)

-> scheduled and automatic transaction execution

-> expiry of pending transactions

Now is the time to start work with specific modules that cover specific transaction scenarios such points, user points or commerce credit. From my point of view, all of them should be based on a common base module and be focused in the particular use case they cover.

I've already started with userpoints, based on transaction, since I need it for my current project. I expect to have a first -dev version soon, considering that the hard work is already done in the transaction module.

Thank you for the detailed explanation.
I am more interested in Commerce Credits (for which the only D8 version that exists is based on Points) so I will post in the Commerce Credits issues.

First version for testing. The patch applies on the latest 7.x-2.x-dev, a tar gzipped version also attached. Currently it provides the basics, that is, the transaction flow orchestrated by a specific transactor plugin and a default configuration that mimics the 7.x look and feel, provided by a submodule (userpoints_default).

TO-DO list:

• API, integration is easy because it uses standard entities and fields, but a service is needed to provide quick access to common operations, such as granting points to a user
• moderation workflow
• specific rules integration

also pending, because no yet available in the transaction module:

• points expiration (needs transaction revertion support)
• scheduled and automatic execution

and, as usual in -dev/alpha versions, documentation is also pending.

Simply wondering if new development has been worked on this module?

At this point there is a -dev available in the project's page. Some feedback is always wellcome. There is work to do in the integration with rules, see #2956286: Add basic rules examples. I am currently busy to work on this, but I can participate in any patch review.

As mentioned in the tracker issue: see https://github.com/graber-1/userpoints if anyone is interested. It'll be further developed and supported at least in my current project usage scope.

is there any roadmap or time estimate to get initially 8.x working version?
There is so many other dependent modules so would be great if this could move forward.
thank you

It will be already 1 year without any newer 8x version update... so sad :(

What is more sad is that I wrote a new version, Pasted the link in my last comment almost 4 months ago and nobody including you @igorik even noticed.

Since the current 8.x version was published a year ago, have emerged several new implementations (#22, user_points...), each one created from scratch under its own unique approach, ignoring the existing one and published with no previous dialogue with the community. The only sad thing is that, until today, we (the community) have failed to join efforts to work together in one direction in this project.

I think it's up to the maintainers to get involved at least a bit and either check the existing solutions and make a choice / roadmap or just declare that the project is abandoned if they don't have time to do anything. For me being a maintainer is taking responsibility for a project, leaving it completely unattended for months leads to what we have here.
Can you please check what's been done and make a decision or declare that the project is abandoned so the community knows what to expect?

As 8.x-1.0-alpha1 was released a year ago which based on the transaction module, should we just work in this direction and close this issue?

Totally agree with Graber #27
This is not responsible behavior from the maintainer, there is no roadmap, no interest regarding his own module, so widely used, there is only 1 year old test and nothing more.

I found this new module "User Points for Drupal 8", so I hope this module and its maintainer will have enough energy to finish it.
So far it looks like the only chance for us who need user points in drupal 8.
https://www.drupal.org/project/user_points

8.x-1.0-alpha1 works as expected for me. which uses the transaction entity form the transaction module to store details. user points is just a Transactor plugin.

Maybe it just lacks documentation.

Thanks @manuel.adan for your module.

Guys,
so which module should I try?
Graber version https://github.com/graber-1/userpoints
or
the official 1-year-old version 8.x-1.0-alpha1
?
Which of them has the bigger chance to have any development in the future?

Alpha version sounds like a very very early version, full of potential problems/bugs and it's 1 year old.
If it is is widely used and tested, maybe it could go to beta version at least.

Thank you

Any update on this issue?

isn't there http://drupal.org/project/userpoints for Drupal 8 now?

@SocialNicheGuru, last update on dev version was in August 2020. So that I'd like to ask for information about current progress.

If you don't see progress on issue queues and repos - there is no progress, we don't secretly develop contrib modules so no one can see ;)
If you really need this or feel like contributing - there are a lot of ways, a good start would be accessing the current existing solutions and posting their pros and cons etc.

@Graber: Maybe you can develop a simple version of your module where all it does is, for example, add a point to a custom user field each time the user creates a new content? I'm asking because the last time Rules was able to do this was for Drupal 7, and it's a shame that the current version can't even do something simple like this. Thanks!

Here's a new release based on my GitHub version (actually not much left todo to make it D9 and community - ready):
https://www.drupal.org/project/userpoints/releases/2.0.0-beta1

Please check.

I'll maintain the issue queues (review patches and MRs if RTBC) but will not have much time for volunteer development so what happens with this module next depends on the community mainly. If something is RTBC I'll check it.

This documentation issue would be good to start with: #3271905: Update module description page