bounties-network/bountiesapi

The caching layer of the Bounties Network

bountiesapi's Issues

OverflowError: Python int too large to convert to C ssize_t

Description

Advanced issue. Solidity and python experience required.

Here is the current stack trace for the error:

bounties_subscriber_1       | Traceback (most recent call last):
bounties_subscriber_1       |   File "/code/std_bounties/management/commands/bounties_subscriber.py", line 68, in handle
bounties_subscriber_1       |     bounty_id, contract_method_inputs, event_timestamp)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/contextlib.py", line 52, in inner
bounties_subscriber_1       |     return func(*args, **kwds)
bounties_subscriber_1       |   File "/code/std_bounties/client.py", line 38, in issue_bounty
bounties_subscriber_1       |     inputs.get('fulfillmentAmount'))
bounties_subscriber_1       |   File "/code/std_bounties/client_helpers.py", line 149, in map_token_data
bounties_subscriber_1       |     token_symbol = HumanStandardToken.symbol()
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/web3/contract.py", line 805, in __call__
bounties_subscriber_1       |     return self.__prepared_function(**kwargs)(*args)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/web3/contract.py", line 844, in call_contract_function
bounties_subscriber_1       |     output_data = decode_abi(output_types, return_data)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/abi.py", line 109, in decode_abi
bounties_subscriber_1       |     return decoder(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 102, in __call__
bounties_subscriber_1       |     return self.decode(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_utils/functional.py", line 22, in inner
bounties_subscriber_1       |     return callback(fn(*args, **kwargs))
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 138, in decode
bounties_subscriber_1       |     yield HeadTailDecoder.as_decoder(tail_decoder=decoder)(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 102, in __call__
bounties_subscriber_1       |     return self.decode(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 118, in decode
bounties_subscriber_1       |     stream.seek(start_pos)
bounties_subscriber_1       | OverflowError: Python int too large to convert to C ssize_t
bounties_subscriber_1       | Traceback (most recent call last):
bounties_subscriber_1       |   File "manage.py", line 22, in <module>
bounties_subscriber_1       |     execute_from_command_line(sys.argv)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
bounties_subscriber_1       |     utility.execute()
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 356, in execute
bounties_subscriber_1       |     self.fetch_command(subcommand).run_from_argv(self.argv)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 283, in run_from_argv
bounties_subscriber_1       |     self.execute(*args, **cmd_options)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/django/core/management/base.py", line 330, in execute
bounties_subscriber_1       |     output = self.handle(*args, **options)
bounties_subscriber_1       |   File "/code/std_bounties/management/commands/bounties_subscriber.py", line 132, in handle
bounties_subscriber_1       |     raise e
bounties_subscriber_1       |   File "/code/std_bounties/management/commands/bounties_subscriber.py", line 68, in handle
bounties_subscriber_1       |     bounty_id, contract_method_inputs, event_timestamp)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/contextlib.py", line 52, in inner
bounties_subscriber_1       |     return func(*args, **kwds)
bounties_subscriber_1       |   File "/code/std_bounties/client.py", line 38, in issue_bounty
bounties_subscriber_1       |     inputs.get('fulfillmentAmount'))
bounties_subscriber_1       |   File "/code/std_bounties/client_helpers.py", line 149, in map_token_data
bounties_subscriber_1       |     token_symbol = HumanStandardToken.symbol()
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/web3/contract.py", line 805, in __call__
bounties_subscriber_1       |     return self.__prepared_function(**kwargs)(*args)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/web3/contract.py", line 844, in call_contract_function
bounties_subscriber_1       |     output_data = decode_abi(output_types, return_data)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/abi.py", line 109, in decode_abi
bounties_subscriber_1       |     return decoder(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 102, in __call__
bounties_subscriber_1       |     return self.decode(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_utils/functional.py", line 22, in inner
bounties_subscriber_1       |     return callback(fn(*args, **kwargs))
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 138, in decode
bounties_subscriber_1       |     yield HeadTailDecoder.as_decoder(tail_decoder=decoder)(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 102, in __call__
bounties_subscriber_1       |     return self.decode(stream)
bounties_subscriber_1       |   File "/usr/local/lib/python3.6/site-packages/eth_abi/decoding.py", line 118, in decode
bounties_subscriber_1       |     stream.seek(start_pos)
bounties_subscriber_1       | OverflowError: Python int too large to convert to C ssize_t

It points to this line of code: https://github.com/ethereum/eth-abi/blob/master/eth_abi/decoding.py#L118 in the eth_abi decoding for web3

This error is triggered by the symbol() call for the human standard token: https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/client_helpers.py#L144

This is for the Coin DAI represented at this address: https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/client_helpers.py#L145

That line of code is a major workaround for now until this issues is solved. I tried to call different ERC20 token standards, but it still did not fix the issue.

Definition of Done

A solution to the bug has been implemented and presented

Reviewers

Myself and @mbeylin

Review Requirements

• WIP explanation of when the cause of the bug has been found along with proposed solution
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev
• This is an advanced issue. Please do not accept this unless you have solidity and python experience.

ENS Hourly Script and Minor Frontend Updates

This is an advanced task and we are only accepting candidates who have time, resources, and bandwidth to put significant time into this.

We want to take our first step into integrating ENS int our app, but we want to start off with it at just a functional level.

We would like a daily script that does a reverse lookup of all our current users with their address to see if they own any root ENS domains. If they own multiple, then choose the smallest. A new field should be added on the user model. Additionally, the frontend repo should update the avatar component here to accept an ENS input and prioritize that vs. the address if it is there. All instances of avatar across the app should be updated appropriately to pass that through.

Requirements

• Add the following fields to the user model:
  • created, edited as shown here (default to both to NOW)
  • last_viewed which should be set and saved in this endpoint (default for current users to NOW)
  • last_logged_in which should be set and saved here (default for current users to NOW)
• Daily script should be set up to iterate through users and check for a root ENS domain, but only for users who have a last viewed within the last day
• the frontend repo should update the avatar component here to accept an ENS input and prioritize that vs. the address if it is there
• All instances on the frontend should be updated to pass it through if it is currently showing the address
• This should be a django management script like this

Communication

• Join our slack community and message in our community-dev channel for questions
• Put a PR up directly into the bounties-api repo

Slack Client Refactor

We need to decouple the slack client from the bounty client. I'd like the master client to look like this:

bounty_client = BountyClient()
slack_client = SlackMessageClient()
sc = SlackClient(settings.SLACK_TOKEN)


def bounty_issued(bounty_id, **kwargs):
    bounty = Bounty.objects.filter(bounty_id=bounty_id)

    if not bounty.exists():
        bounty = bounty_client.issue_bounty(**kwargs)
        slack_client.bounty_issued(bounty)```

(That's of course just one example).

In this case, I removed the event field and just pass the bounty through. This makes it cleaner, and now we can add an email client or notificer client after this in the master client. Eventually, these will be all long-running jobs as well.

Additionally, the template strings I'd like to be in a slack_templates.py file and imported.

Content spoofing in the api sub.

So this is my report:
i find a text injection can be used in phishing 404 page should not include attacker text !
Description :
This report is about how an attacker is able to spoof the content of 404 page and can add thr own Text in way that the Current Website is moved to someone new URL which is Attackers website , yet its not that much effective to make this attacker successful but still this need to fix .

Vulnerable URL : https://api.bounties.network
POC URL: https://api.bounties.network/%20https://api.bounties.network%20has%20been%20changed%20to%20http://ATTACKER.com%20so%20please%20visit%20it%20or%20contact%20the%20support%20on%20this%20email:%[email protected]%20,%20and%20about%20Bounties.network%20service
Reference : https://www.owasp.org/index.php/Content_Spoofing
POC : https://i.imgur.com/Ez9SBpq.png
Mediation :
User Predefined 404 page , with fixed error content !
Please let me know if any more info needed !

Regard's

NESSIM JERBI

Include Categories in Analytics Endpoint

We want to show the most used categories in our beta analytics dashboard

There is a bit of base work that needs to be done to first tackle this.

Requirements

• Currently the timeline generator aggregates the stats by schema. We need this updated to aggregate instead by platform. Platform is a field on both bounties and fulfillments. Right now we will have bounties-network and gitcoin. bounties-network should be the default if no schema is attached.
• The endpoint should show each category name along with its total count for the timeframe
• This should be completed using django calls not raw sql. It should be a query on the fly and will need to aggregate the numbers by normalized_name
• The actual endpoint however needs to join with the RankedCategory model to get the prioritized name (as the normalized name can map to multiple names, RankedCategory has already done the proper mapping work to the human readable name).

Review

• Should correspond regularly and give an initial plan of action
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel

Qualifications

• This is a fairly advanced task, but the patterns are already in place. A good github history and good experience with python, django, SQL, docker are mandatory.

Deadline

• Please only take this issue if you have the capacity to work on this ACTIVELY over the next week. We'd like this finished quickly and do not want someone to take it who will passively work on it.

Before starting work, please communicate your plan and availability along with your intention to take the task. After initial communication, I'll approve the best candidate to take the task.

Increase the codecov by 5%

Requirements

• You must increase the code coverage (as measured by codecov) of this repo by 5%.
• You must put (show) some thought into success / failure criteria for each method tested.
• Please coordinate with other bounty hunters who are working on this bounty so you don't overlap work (we will do multiple payouts)
• No tests on the analytics subapp

Communication

• Join our slack community and message in our community-dev channel for questions
• Put a PR up directly into the bounties-api repo

Should 404 when user is not found

When request a user address that doesn't exist, I think it would make sense for the api to return a 404 code along with normal response rather than a 200.

{
    "user": null,
    "stats": {}
}

Response expects an object, but gets a string

BountiesAPI/bounties_api/analytics/views.py

Line 43 in b7f756d

res = {"error": 400, "message": "The fields since & until needs being formated as YYYY-MM-DD"}

We should drop the json.dumps, otherwise it looks like this:

Feature: Analytics Endpoint

This is the first bounty in an upcoming set of bounties focused around building an analytics dashboard for projects that utilize the standard bounties contract such as gitcoin, and other upcoming open source sites.

This first task begins the work of exposing endpoints around daily stats for a range of time. Ultimately, these will be used to build a react frontend connected to highcharts or other charting libraries. The data is already stored in PSQL, it just needs to be served up via the format requested below. This task ultimately requires just one endpoint to be built for now.

Requirements

• endpoint should accept a start and end-date filter - ?publish_date__range=2016-01-01,2016-02-01 format
• Results need to be returned as daily. Daily represents 00:00 - 23:59 UTC time. The current day will of course be a partial day.
• endpoint should live in the newly added analytics directory/application - https://github.com/Bounties-Network/BountiesAPI/tree/master/bounties_api/analytics
• Url should be prefaced with /analytics route
• A new model should be introduced. This model should include a date field, along with the names of the requested stats. For now, I only foresee one model being created.
• A management job should be created. This job should be intended to run daily. Don't worry about setting up the scheduling - I'll put that work in after the PR. To see an example job/management command: https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/management/commands/get_token_values.py
• The job should fill in empty dates. For example, if the model and table is newly created and empty, the job should insert records for every day. Basically, the job should do calculations from the latest insertion date, but should not repeat work if the date has already been included.
• The endpoint should be an APIView - similar to these - https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/views.py#L83
• The job should already have the previous days pre-calculated. IT will be expected to run every 5 minutes, and therefore should update the current day's stats.
• This is time-series data! This means, the endpoint should return the values on each stat for each day in-between the range. IN addition to the timeseries data - it should also return the aggregates.
• Pep8 compliance required
• The BountyState table in models.py is essential to get the bounty stage data.
• Additionally should be able to filter by the Schema field on the Bounty model

Statistics

• Total number of bounties issued
• Total number of fulfillments submitted
• Total number of fulfillments accepted
• Total number of fulfillments without acceptance
• Total fulfiller acceptance rate
• Total bounty fulfilled rate
• Average fulfiller acceptance rate
• Average bounty fulfilled rate
• Average fulfillment amount (usd_price)
• Total fulfillment amount
• Number of bounties in each bountyStage (each stage count would be a separate field on the model)

All of the above should be a separate field on one model that the job writes to. These should all be exposed on one api endpoint.

Example Response to https://api.bounties.network/analytics/stats?publish_date__range=2016-01-01,2016-01-04

The example response is missing the aggregate response. The aggregate response should include the values over the entire timerange.

[{
  date: 2016-01-01,
  bounties_issued: 44,
  fulfillments_submitted: 23,
  fulfillments_accepted: 21,
  fulfillments_pending_acceptance: 2,
  fulfillment_acceptance_rate: .91,
  bounty_fulfilled_rate: .83,
  avg_fulfiller_acceptance_rate: .73,
  avg_fulfillment_amount: 45.32,
  total_fulfillment_amount: 184,
  bounty_draft: 11,
  bounty_active: 48,
  bounty_completed: 22,
  bounty_expired: 5,
  bounty_dead: 11
}, {
  date: 2016-01-02,
  bounties_issued: 44,
  fulfillments_submitted: 23,
  fulfillments_accepted: 21,
  fulfillments_pending_acceptance: 2,
  fulfillment_acceptance_rate: .91,
  bounty_fulfilled_rate: .83,
  avg_fulfiller_acceptance_rate: .73,
  avg_fulfillment_amount: 45.32,
  total_fulfillment_amount: 184,
  bounty_draft: 11,
  bounty_active: 48,
  bounty_completed: 22,
  bounty_expired: 5,
  bounty_dead: 11
}]

Definition of Done

• All requirements are completed above with the endpoint functional.

Reviewers

Myself and @mbeylin

Review Requirements

• A WIP pull request along the way with initial progress
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev

Build Slack Client Managing Slack Notifications

Description

Currently, we have a notification channel in slack that lets us know when contract events have occurred.
In its current state, it only sends the following info to the slack channel:

'Event {} passed for bounty {}'.format(event, str(bounty_id))
or an example:
Event BountyFulfilled passed for bounty 162

We would like to make this slack channel public, and would like to provide more information. Gitcoin's notification channel provides a great example of detailed messages.

In our iteration, we'd actually like the std_bounties client to call the slack function at the end of each of the functions. Keep in mind, the std_bounties client is called by the long-running job bounties_subscriber. A file should be added called slack_clienty.py with the same functions as the std_bounties client and work as a mirror.

We want the following info posted for each event:

issue_bounty: Bounty Title, ID, Token info (symbol @ price), Fulfillment Amount, USD Price, Deadline
activate_bounty: Bounty Title, ID, Token, USD_Price
fulfill_bounty: Same as issue_bounty with fulfillment_id included
fulfillment_updated: Bounty Title, ID, fulfillment_id
fulfillment_accepted: Same as issue_bounty with fulfillment_id included
bounty_killed: Bounty Title, ID
contribution_added: Bounty Title, ID, Balance Added (token and USD_PRICE), Previous Balance, Token Info.
deadline_extended: Bounty Title, ID, previous deadline, new deadline
bounty_changed: Bounty title, ID
Issuer Transferred: Bounty Title, ID
Payout Increased: Bounty title, ID, Payout added (token and USD_PRICE), previous payout amount

Also, each should give a link to the issue on the bounty network: beta.bounties.network

Once work has been started, we will give access to the appropriate slack channels. Once completed, the channels will be public.

Pep8 compliance required

Definition of Done

• All events post properly

Reviewers

• Myself and @mbeylin

Review Requirements

• A WIP pull request along the way with initial progress
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev

Thoughts from building the SDK to inform future development

I want to leave some thoughts I've had while building the SDK that may help to inform the development of the next iteration of the API.

• Does it make sense to prescribe one notification to be push and another to be activity? As an open protocol I'd argue that they are all notification and it should be up to developers building on our platform to make that distinction in their frontend by choosing which are quickly visible and through a setting panel that allows users to turn on and off emails for specific notifications.

• The leaderboard endpoint is a departure from the pattern put in place by bounties, fulfillments, etc where a single entity can be retrieved by drilling down /{entity}/{id} or a list could be retrieved via some query to the /{entity} endpoint. I believe that leaderboard should be generalized and accessible via the /user endpoint and customizable using queries.

• For continuity sake, I think the categories, skills, tokens, and languages should also follow the /{entity}/{id} || /{entity} pattern.

• The comments endpoint should be decoupled from a bounty like fulfillments. It may be useful to retrieve all of a specific user's comments.

• How are we going to seamlessly integrate STB2 where bounties are identified by addresses instead of ids? It doesn't make sense to me to require users who want to know about a bounty at 0x123...456 to first ping our API to determine that bounties id before calling the /bounty endpoint.

I'll add more to this thread as they come up!

Increase Code Coverage by 5%

Simple. Codecov - bring the % up by 5. :D

Responsible Disclosure: Bug Bounty Inquiry

Hi there,

I’m a Security Researcher and I found some Vulnerabilities in your websites. Where Can I Report Security issues?

Do you have a Running Bug bounty program?

Thank you

Analytics Endpoint Updates

Currently the analytics endpoint aggregates everything by day. We'd like to also have an aggregation by week option.

Requirements

• Include a query param that returns the data in weekly increments vs. daily increments
• Week is broken up into UTC calendar week up through Saturday 11:59:59
• Propose how this will be stored. Do we extend the current table or do we create a new one?

Deadline

• Please only take this issue if you have the capacity to work on this ACTIVELY over the next week. We'd like this finished quickly and do not want someone to take it who will passively work on it.

Qualifications

• This is a fairly advanced task, but the patterns are already in place. A good github history and good experience with python is required

Definition of Done

• All requirements are completed above with the endpoint functional.
  Reviewers
  Myself and @mbeylin

Review Requirements

• A WIP pull request along the way with initial progress
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel

Contract Subscriber Tries to Process Same Block

If no new events occur between iterations of the contract subscriber loop, it will process the same block over and over again.

BountiesAPI/contract_subscriber/index.js

Lines 15 to 21 in fa40025

	let fromBlock = await getAsync('currentBlock') || 0;
	let events = await StandardBounties.getPastEvents({fromBlock, toBlock: 'latest'});
	let eventBlock = await sendEvents(events);
	if (eventBlock) {
	await writeAsync('currentBlock', eventBlock);
	}

I think that eventBlock should be incremented by 1 before updating the currentBlock in the Redis cache. This is a minor issue since messageDeduplicationId should stop it from actually getting processed, however it seems like it puts unnecessary strain on the cache.

Fulfillment/Bounty Stats Analytics Endpoint

We want to show the cumulative number of unique bounty issuers and cumulative bounty fulfillers over time. We also want to show cumulative USD over time. You can view the current beta analytics dashboard. This task only requires updating the API. A separate task will be created around the frontend.

Requirements

• The endpoint should return cumulative numbers on unique issuer addresses and fulfiller addresses
• Cumulatives should be added to both daily and weekly records
• Cumulative USD paid out over time. This is reflected by fulfillments with the accepted flag set to true and have an associated usd_price field with them.

Review

• Should correspond regularly and give an initial plan of action
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel

Qualifications

• This is an intermediate task and the patterns are already in place. A good github history and prior experience with python, django, docker are required/encouraged

Deadline

• Please only take this issue if you have the capacity to work on this ACTIVELY over the next week. We'd like this finished quickly and do not want someone to take it who will passively work on it.

Before starting work, please communicate your plan and availability along with your intention to take the task. After initial communication, I'll approve the best candidate to take the task.

Set up Code Coverage configuration

Requirements

• Code coverage should be properly configured to cover both the node.js files and the django application.
• Code coverage should be configured properly to run on all required files (management jobs, helpers, etc.)

As an example, code coverage is already setup within the django application. However, the configuration needs to be fixed as it is not covering the right files. To run it, just try docker-compose exec bounties_api python manage.py test --with-coverage

Definition of Done

• All requirements are completed above with the endpoint functional.

Reviewers

Myself and @mbeylin

Review Requirements

• A WIP pull request along the way with initial progress
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev

Manage Internal Transactions

Currently, we run into a few issues:

1. Our current architecture does not pass enough information on events. As a result, we have to pull the transaction to find the original inputs: https://github.com/Bounties-Network/BountiesAPI/blob/master/contract_subscriber/eventsRetriever.js#L37-L42 . This approach will not work with wrappers around the std bounties contract. This is because a wrapper contract will create an internal transaction that is not reliable enough to track the original inputs.
2. Leaderboard and other endpoints track the fulfillment address from msg.sender. This means in the case of an internal transaction, we must grab this value from the data schema. This is a bit tricky and will definitely require us to branch out the code.

Roadmap Ahead

These are some of the areas we need to begin to tackle. Feedback on prioritization and any other discussion is encouraged.

New Features

• Events API to track diffs/events in the contract. This could be used as the groundwork for analyzing datapoints such as user behavior, reputation, recommended pricing, spam, etc.
• Reputation metrics
• A better definition of user profiles
• Pricing field to lock the usd_price on payout. On resyncs, this will require apis with historical data.
• Leaderboards and categories filtered by platform (gitcoin, bounties network, etc.)
• Recommended pricing
• Spam detection
• Analytics tag for each platform or vertical to include on their application. This tag would enrich our datasets and enable us to provide better metrics around reputation, pricing, etc.. We would also want to include a dashboard for users where they may remove access to their data.
• Websocket endpoint to provide our structured data to clients/platforms after we write it to our DB.

Cleanup and Organizational Tasks

• Setup Linters
• Ops Documentation
• Contribution Guidelines
• Circle Integration and automatic deployments
• Basic Tests

Feature: Analytics Endpoint V1

This is the first bounty in an upcoming set of bounties focused around building an analytics dashboard for projects that utilize the standard bounties contract such as gitcoin, and other upcoming open source sites.

This first task begins the work of exposing endpoints around daily stats for a range of time. Ultimately, these will be used to build a react frontend connected to highcharts or other charting libraries. The data is already stored in PSQL, it just needs to be served up via the format requested below. This task ultimately requires just one endpoint to be built for now.

Requirements

• endpoint should accept a start and end-date filter - ?publish_date__range=2016-01-01,2016-02-01 format
• Results need to be returned as daily. Daily represents 00:00 - 23:59 UTC time. The current day will of course be a partial day.
• endpoint should live in the newly added analytics directory/application - https://github.com/Bounties-Network/BountiesAPI/tree/master/bounties_api/analytics
• Url should be prefaced with /analytics route
• A new model should be introduced. This model should include a date field, along with the names of the requested stats. For now, I only foresee one model being created.
• A management job should be created. This job should be intended to run daily. Don't worry about setting up the scheduling - I'll put that work in after the PR. To see an example job/management command: https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/management/commands/get_token_values.py
• The job should fill in empty dates. For example, if the model and table is newly created and empty, the job should insert records for every day. Basically, the job should do calculations from the latest insertion date, but should not repeat work if the date has already been included.
• The endpoint should be an APIView - similar to these - https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/views.py#L83
• The job should already have the previous days pre-calculated. However, the endpoint will need to calculate the statistics for the current day (since it is ongoing) and add that to the dataset (hint: a shared function should be used here)
• This is time-series data! This means, the endpoint should return the values on each stat for each day in-between the range. IN addition to the timeseries data - it should also return the aggregates.
• Pep8 compliance required

Statistics

• Total number of bounties issued
• Total number of fulfillments submitted
• Total number of fulfillments accepted
• Total number of fulfillments without acceptance
• Total fulfiller acceptance rate
• Total bounty fulfilled rate
• Average fulfiller acceptance rate
• Average bounty fulfilled rate
• Average fulfillment amount (for now just eth volume, ignore noneth on this one)
• Total fulfillment amount
• Number of bounties in each bountyStage (each stage count would be a separate field on the model)

All of the above should be a separate field on one model that the job writes to. For the current day, this should be calculated in realtime. These should all be exposed on one api endpoint.

Definition of Done

• All requirements are completed above with the endpoint functional.

Reviewers

Myself and @mbeylin

Review Requirements

• A WIP pull request along the way with initial progress
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev

Analytics Dashboard

This should be our first bountied issue. @mbeylin let me know if we're missing anything here.

Basic Details

• All endpoints should accept a start and end-date filter
• Results should return as daily, monthly, or weekly. Daily is pegged to 00:00 - 23:59 UTC, monthly to calendar months, and weekly to Sunday - Saturday. Current week would always start on Sunday at 0:00 UTC and will be partial
• I will provide an example endpoint that provides the above on one simple endpoint as guidance
• Frontend should be an eslint-airbnb compliant React/Redux application
• Utilizes highcharts or other quick graphing library
• Design is up to the contributor

Datapoints and Graphs

• Total number of bounties issued
• Total number of fulfillments submitted
• Total number of fulfillments accepted
• Total number of fulfillments without acceptance
• Total fulfiller acceptance rate
• Total bounty fulfilled rate
• Average fulfiller acceptance rate
• Average bounty fulfilled rate
• Average fulfillment amount (v1 as eth volume, v2 takes into account usd_price)
• Total fulfillment amount
• Leaderboard
• Categories and quantities in a pie chart
• Number of bounties in each bountyStage

@mbeylin these mimic a lot of what we have in the app right now. Let me know if you have ideas/thoughts on other metrics we may want. Also, we may want to narrow down to just a few of the above to make v1 of the dashboard as simple as possible. We can expand on it later.

Add missing is_valid call

Hi there. When I was working on adding tests, I stumbled upon update_fulfillment method. When I tried to call it from test code, it failed.

I think the reason of failing is that it should call is_valid before saving the object to DB, similar to the fulfill_bounty method just above.

Here's the method: https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/bounty_client.py#L122-L124

Refactor to use an event storage model

Description

The current system sends events directly via sqs, and then the std_bounties client responds directly to the messaged events.

As we want to include more realtime systems in response (ie. stats and more to come), we are running into the issue of how we accomplish it without resyncing everything to the blockchain and passing through the events via sqs. In addition, we want to store the actual events that have passed in a table for analytics reasons.

A good solution to everything is to store the events in a table and use this table to resync. This will require a refactor of the current system.

Definition of Done

• Events are stored
• No need to resync data with having to re-initiate the sqs queue

Reviewers

@mbeylin and myself

Review Requirements

A WIP pull request along the way with initial progress
Key questions posted here
Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev

Update Swagger to Match Endpoints

Requirements

• Update the swagger schema to be in line with our current api

Communication

• Join our slack community and message in our community-dev channel for questions
• Put a PR up directly into the bounties-api repo

Bounty created by direct Smart Contract interaction not showing in API

New bounty was created in Rinkeby: https://rinkeby.etherscan.io/address/0x38f1886081759f7d352c28984908d04e8d2205a6

When querying for bounties with the issuer specified in the successful issueAndContribute call, no bounties were found. This was queried using the Rinkeby API for Standard Bounties, http://rinkeby.api.bounties.network/.

Std. Bounties V2 Architecture

Opening a thread to begin discussing, researching major changes we will need to implement for Std. Bounties V2.

The new proxy architecture - which is awesome 💯- https://github.com/Bounties-Network/StandardBounties/blob/develop/contracts/inherited/Proxy.sol is going to require some major changes. For example, each bounty will create a proxy contract with its own address.

• We will need to build a way to listen to all proxy addresses for events as well as the factory https://github.com/Bounties-Network/StandardBounties/blob/develop/contracts/StandardBountiesFactory.sol.
• We need to track the token inputs and payouts. This gets tricky as the new version supports multiple tokens and multiple recipients for fulfillments. Events cannot pass all this information, so we will most likely have to monitor the contract address for transactions. This brings a lot of questions/challenges to mind.

Bounty API React/Redux Dashboard

Example endpoint to mock should return the following:

https://api.bounties.network/analytics/stats?publish_date__range=2016-01-01,2016-01-04

Please stay in touch with the person also working on this task: #21

[{
  date: 2016-01-01,
  bounties_issued: 44,
  fulfillments_submitted: 23,
  fulfillments_accepted: 21,
  fulfillments_pending_acceptance: 2,
  fulfillment_acceptance_rate: .91,
  bounty_fulfilled_rate: .83,
  avg_fulfiller_acceptance_rate: .73,
  avg_fulfillment_amount: 45.32,
  total_fulfillment_amount: 184,
  bounty_draft: 11,
  bounty_active: 48,
  bounty_completed: 22,
  bounty_expired: 5,
  bounty_dead: 11
}, {
  date: 2016-01-02,
  bounties_issued: 44,
  fulfillments_submitted: 23,
  fulfillments_accepted: 21,
  fulfillments_pending_acceptance: 2,
  fulfillment_acceptance_rate: .91,
  bounty_fulfilled_rate: .83,
  avg_fulfiller_acceptance_rate: .73,
  avg_fulfillment_amount: 45.32,
  total_fulfillment_amount: 184,
  bounty_draft: 11,
  bounty_active: 48,
  bounty_completed: 22,
  bounty_expired: 5,
  bounty_dead: 11
}]

The endpoint should also return the above stats as full aggregates (representing the aggregate of the entire date range), and these should also be visualized.

You may also filter by schema, ie:
https://api.bounties.network/analytics/stats?publish_date__range=2016-01-01,2016-01-04&schema=gitcoin

Requirements

• Utilizes highcharts or other quick graphing library
• Design is up to the contributor
• Frontend should be an eslint-airbnb compliant React/Redux application
• Bounty states (draft, active, etc.) should be represented by a pie chart
• Remaining stats could go on one line chart with toggles for each
• Perhaps introduce other charts (bar, etc.), or sepearate the average stats into a separate line chart
• Visualize the full aggregates in addition to the time series data
• Have a dropdown for the page to control the daterange
• Have a dropdown for the page to filter by schema

Definition of Done

• All requirements are completed above with the endpoint functional.

Reviewers

Myself and @mbeylin

Review Requirements

• A WIP pull request along the way with initial progress
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev

Token Endpoint

Description

We'd like to provide an endpoint that returns all tokens that have been used at least once in a contract. It should also return its associated token data.

We do not want to refactor or change the current structure (address is on the bounty, but pricing token data is a separate model) due to various reasons at this point. Feel free to disagree with that approach, but I've wanted to keep a separation of concerns between third party data and our internal data. For example, we may have a token as part of a contract that does not exist yet on coinmarketcap. Additionally, the address and decimals live on the bounty schema in the contract, so I want to keep things consistent.

Requirements

• Token endpoint that returns all tokens that have been associated with a bounty and associated pricing data (if it is available)
• /token endpoint - no need for a /token/{id}
• The endpoint should return the count as well (how many bounties has the token attached) and should order its results based on count. Tokens that are in the Token table but not associated with a bounty should not be returned.
• It should live in the std_bounties app and endpoint should go in the views.py file.
• Pep8 compliance required

Related Info

• Token model attached to coinmarket cap - https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/models.py#L19
• Token fields attached to bounty - https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/models.py#L52-L55
• Not related to this task, but if interested, the coinmarket script - https://github.com/Bounties-Network/BountiesAPI/blob/master/bounties_api/std_bounties/management/commands/get_token_values.py

Definition of Done

• Endpoint fully functions, returns the token schema along with address and decimals

Reviewers

• Myself and @mbeylin

Review Requirements

• A WIP pull request along the way with initial progress
• Key questions posted here
• Conversational and longer discussions should be directed to the bounties network slack in this channel: https://bountiesnetwork.slack.com/messages/community-dev