Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decoupled projects: Contract changes #1912

Closed
wants to merge 3 commits into from

Conversation

topocount
Copy link
Collaborator

@topocount topocount commented Jan 23, 2020

Addresses #1875 and #1897

This PR adds functions to the projects contract for:

  • creating decoupled projects that can include an IPFS hash
  • creating and modifiying issues that don't yet contain bounties

This PR also contains

  • gas optimizations to allow these issues to fit in the contract
  • the removal of the standard bounties bytecode check to make room for these features, since isContract should be sufficient

Note

@topocount topocount requested review from a team as code owners January 23, 2020 12:48
@ghost ghost requested review from ottodevs, Quazia and PeterMPhillips and removed request for a team January 23, 2020 12:48
@topocount topocount changed the title Decoupled projects Decoupled projects: Contract changes Jan 23, 2020
@javieralaves javieralaves added app: projects contracts Involves changes to solidity files labels Jan 23, 2020
Quazia
Quazia previously approved these changes Jan 23, 2020
Copy link
Collaborator

@Quazia Quazia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, in integration we'll need to check for all instances of IssueUpdated and the parsing of return data from getIssue I'm not seeing anything else that should need changing.

apps/projects/test/Projects.test.js Show resolved Hide resolved
apps/projects/contracts/Projects.sol Outdated Show resolved Hide resolved
@rkzel
Copy link
Collaborator

rkzel commented Jan 28, 2020

Specification suggests that there should be a fuction to edit project as well as add/remove. Editing will involve only replacing ipfs hash saved in_projectData, so all we need is a simple function like this:

    function updateRepo(bytes32 _repoId, string _repoData) external auth(....?)
     {
        require(isRepoAdded(_repoId), ERROR_REPO_MISSING);
        uint rowToUpdate = repos[_repoId].index;
        repoIndex[repoIndexLength] = _repoId;
        repos[rowToUpdate].repoData = _repoData;
        emit Repo....?
    }

Probably a new right and event to emit need to be added as well - what do you think, @topocount ? Alternatively if it's too complicated for current timeline, maybe we leave it for now and not allow editing projects at all?

- add decentralized project entries
- add and update issues directly without bounties
- enable multi-fulfillment bounties

BREAKING CHANGE: Projects contract updates
- `fulfillBounty` radspec message now shows up in external tx panel
- remove extraneous logging from deploy script
- remove unneeded functions from Bounties interface
Projects: improve querying behavior
@ottodevs ottodevs changed the base branch from dev to issue-querying February 5, 2020 19:04
Copy link
Member

@ottodevs ottodevs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed base branch to merge, to properly see the exact changes going on here

Most of the contract and tests look fine for me, and they are passing. I am a bit concerned about opening potential security vectors, as we are not auditing this new code on this review.

Just some minor details to comment about:

It would be preferable to properly document each function that was added or changed
I would just take advantage of this work to keep the contract clean and audit-ready by properly documenting this new code.

I would also bet to improve the tests suite and make it more readable/ less error prone by making use of constants and avoiding magic numbers and text everywhere.

@@ -319,12 +297,16 @@ contract Projects is AragonApp, DepositableStorage {
/**
* @notice Get an entry from the registry.
* @param _repoId The id of the repo in the projects registry
* @return index the repo registry index
* @return index the repo registry index, number of open bounties, decoupled bool, repo metadata
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is preferable to document @return params into separate lines each one

@@ -357,20 +339,25 @@ contract Projects is AragonApp, DepositableStorage {
// Repository functions
///////////////////////
/**
* @notice Add repository
* @notice Add new Project: `_projectData`.
* @param _repoId The id of the repo in the projects registry
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should document the rest of params as well

string _data
) external
{
revert();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we just want to display the radspec, why revert? Also this should be a pure function

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revert will cause non 0 exit status and that maybe non gracefully handled by the frontend

Copy link
Collaborator Author

@topocount topocount Feb 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function should never execute. It's just a workaround for getting the radspec showing up in the frontend. BY forcing it to revert, it effectively doesn't exist and is an invalid call on the contract

repos[_repoId].repoData = _repoData;
if (!isRepoAdded(_repoId)) {
repoIndex[repoIndexLength] = _repoId;
repos[_repoId].index = repoIndexLength++;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we accounting on a potential overflow here?

) internal
{
// ensure the transvalue passed equals transaction value
//checkTransValueEqualsMessageValue(msg.value, _bountySizes,_tokenBounties);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment relevant anymore or just dead code? We should remove to avoid confusion

event ContributionsRefunded(uint _bountyId, address _issuer, uint [] _contributionIds);
event BountyDrained(uint _bountyId, address _issuer, uint [] _amounts);
event ActionPerformed(uint _bountyId, address _fulfiller, string _data);
event BountyFulfilled(uint _bountyId, uint _fulfillmentId, address [] _fulfillers, string _data, address _submitter);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some spacing between array brackets and types seem wrong with inconsistently 1 or 2 spaces, maybe we should try to be consistent about it, I vote for no spacing between type and brackets

Suggested change
event BountyFulfilled(uint _bountyId, uint _fulfillmentId, address [] _fulfillers, string _data, address _submitter);
event BountyFulfilled(uint _bountyId, uint _fulfillmentId, address[] _fulfillers, string _data, address _submitter);

Some for the rest of lines on this block

@@ -1,4 +1,4 @@
/* global artifacts, assert, before, beforeEach, contract, context, expect, it, web3 */
/* global artifacts, assert, before, beforeEach, contract, context, expect, it, web3, xit */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xit should actually not need to be defined here, as tests should only be skipped during deployment

1,
1,
true,
'QmbUSy8HCn8J4TMDRRdxCbK2uCCtkQyZtY6XYv3y7kLgDl',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move most of these arbitrary magic values to constante to have a more manageable/less error prone test suite, but that's only a personal preference

new web3.BigNumber(56),
new web3.BigNumber(15),
new web3.BigNumber(0),
'0xffffffffffffffffffffffffffffffffffffffff',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use ANY_ADDR (line 16) constant in places like here, otherwise, we define it at all?

context('decoupled project', () => {
let repoId
beforeEach(async () => {
await app.setRepo('1', true, 'abc')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use real repo ids as in other test cases to avoid false negatives when repoId length does not find in the contract field

Copy link
Collaborator Author

@topocount topocount Feb 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Projects will be using integers for decoupled repoIds going forward. They'll still get hashed by the frontend before passing them in, but that's really just a messier magic number in the context of tests

@topocount
Copy link
Collaborator Author

Changed base branch to merge, to properly see the exact changes going on here

We're working out of the https://github.com/AutarkLabs/open-enterprise/tree/decentralized-project-integration banch, and this branch has already been merged in there. I'll make your requested changes in there and redirect https://github.com/AutarkLabs/open-enterprise/tree/issue-querying to that branch as well.

@topocount
Copy link
Collaborator Author

This branch has been merged into PR #1941. The review above has been addressed there

@topocount topocount closed this Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app: projects contracts Involves changes to solidity files
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants