Crowdaction badge threshold

[rubenhorn]

⚠ Blocked by #73

• Add field to crowdaction (DB, API): 'badge_thresholds': [30, 50, 100, 150] (example values)
• Add field to commitment (DB, API): points: 10 (example value)
• (Enforce array length of 4 in validation)
• Update API documentation

At the end of the crowdaction the points of the selected commitments will be summed up and compared to the threshold values to determine the badge that should be awarded.

[edreinoso]

How is this ticket dependent of the crowdactions? The way I look at it is that the participants are the ones that needed to be awarded.

Maybe when you fetch the crowdaction you can get to see the different badges from each participant. Similar to a competition, just kind of showing which participant received Golden, Silver, Bronze?

[rubenhorn]

The badge-instances are properties of the profiles, but the crowdactions need to define thresholds for how many points are required to earn them.
Basically this is just adding this array property to the crowdaction records in DynamoDB.
The client may use this property to determine and display which badge a user might earn and other lambdas will use this property to actually calculate the reward at the end of the crowdaction.

[edreinoso]

So when you fetch a crowdaction, you should be able to see how many points are required to get one of the 4 different badges: diamond, gold, silver, bronze?

Is there anything else that needs to be done besides just adding the additional fields for the badges in the DDB table?

I thought of this task in this way, maybe correct me if I'm wrong:

• A user registers for the crowdaction with
  """func (h *ParticipationHandler) createParticipation()"""

• The system will retrieve the information from the request
  """userID, name, crowdaction, err := retrieveInfoFromRequest(req)"""

• The system will then make the proper call to the adaptor to register the user
  """if err := h.service.RegisterParticipation(ctx, userID, name, crowdaction, payload); err != nil {"""

• The system will then evaluate certain conditions as specified in the documentation from https://collaction.atlassian.net/wiki/spaces/DOC/pages/2537226279/CollAction+app+features
  For example, the user is in the earliest bid range will receive 10 points

• The system will provide points to the user according to this evaluation.

• Lastly, the system will award the user if they had the necessary points to receive a medal

[rubenhorn]

No, not in the scope of this task. We will go with the minimum for now.

[edreinoso]

Okay so the task for this is to create an extra attribute in DDB with badges with the values specified in the array? Couple of follow up questions regarding this:

• Is this supposed to be done manually? I mean if the crowdactions are created directly on DDB console, I don't see a way to automate this for now.

• What are the values that need to specified for a certain crowdaction? In the ticket it mentions:
  'badge_thresholds': [30, 50, 100, 150]
  But I am not sure if they are examples for all crowdactions.

• Lastly, what exactly is meant by the (Enforce array length of 4 in validation)? Which validation is it being referred here?

[rubenhorn]

• For now, this has to be manually included when creating the crowdaction record, but will be part of a form in the CMS
• There are no fixed values (as they can be different for each crowdaciton). There just have to be exactly four and they must obviously be positive (not-zero) and in ascending order.
• I suppose currently we don't have any existing validation logic for the crowdactions atm, since the "C/U" of the crowdaction CRUD will only be implemented as part of the CMS. (Maybe just add a standalone validation function for this)

[edreinoso]

Okay I will create some new attributes manually in my DDB single table.

I am not sure if I have to do some code changes. It seems like the CMS task would own some of these checkpoints, but maybe I'm wrong (hence the discussion haha).

For me this task does not really make much sense if we don't build the logic behind getting the points, and rewarding the badges 😅. But I assume there are other tasks for this to be implemented.

[rubenhorn]

Yes, the points are calculated and compared to the threshold in #120
...and it should just be one attribute, but an array (see description of issue above)

[edreinoso]

All right, I will get on that today. That was my bad, I accidentally typed the plural

[rubenhorn]

Re-opening issue, since change has not yet been merged.
Please reference it from some PR. 😉
Also make sure to update the YAML file for the API.

[rubenhorn]

Added additional field (s. description above)

[edreinoso]

Is this more or less the change that needs to be done for the second checkpoint? The value of points need to be according to the table in Confluence:

Since this is type of commitment is: Vegan, it receives 70 points.

I am doing this manually for now, but this needs to be taken care of when the CMS part is getting implemented

[rubenhorn]

Actually, this also needs to be changed in the GoLang code (here and maybe somewhere else as well, such as the crowdactions file), so we can access this fields after fetching a record from dynamo, since we don't work on the raw dynamo response and instead map them to a plain GoLang object.

In the case of "Vegan", it would be 20 here and the rest of the points come from the commitments in "required".

[edreinoso]

Perfect, I have already made the appropriate changes to the API documentation, as well as to the Commitment models. Please revise it in this branch:

https://github.com/CollActionteam/collaction_backend/tree/feat/gh-111/badge_threshold