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

Discussions #1050

Merged
merged 86 commits into from
Aug 23, 2019
Merged

Discussions #1050

merged 86 commits into from
Aug 23, 2019

Conversation

Schwartz10
Copy link
Collaborator

No description provided.

Schwartz10 and others added 30 commits June 18, 2019 11:00
* Clean up styles
* Improve behavior
These buttons look good, but don't do anything yet
It needs a working save function in Discussion.js, but the rest is in
place and it behaves properly on the frontend.
@chadoh chadoh removed request for a team, rkzel, ottodevs and topocount August 22, 2019 12:38
"publish:http": "npm run build:script && aragon apm publish major --http localhost:9999 --http-served-from ./dist",
"versions": "aragon apm versions",
"lint": "eslint . & solium --dir ./contracts",
"lint:fix": "eslint . --fix & solium --dir ./contracts --fix",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should these two lines use && instead of &?

"description": "",
"dependencies": {
"@aragon/api": "latest",
"@aragon/api-react": "latest",
Copy link
Collaborator

Choose a reason for hiding this comment

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

This differs from our other apps. Does that matter?

apps/discussions/app/App.js Outdated Show resolved Hide resolved
Most of the linting errors were complaining about use of `now`. This [can
cause security problems][1], if using `now` for security-related
functions. We are not doing that here, so I am guessing that our use of
`now` is safe, and am therefore ignoring these lint warnings explicitly.

  [1]: https://consensys.github.io/smart-contract-best-practices/recommendations/#timestamp-dependence
@@ -45,12 +45,12 @@ contract DiscussionApp is IForwarder, AragonApp {
post.author = msg.sender;
post.postCid = postCid;
post.discussionThreadId = discussionThreadId;
post.createdAt = now;
post.createdAt = now; // solium-disable-line security/no-block-members
Copy link
Member

@ottodevs ottodevs Aug 22, 2019

Choose a reason for hiding this comment

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

Just for future reference, we are using the TimeHelpers from AragonOS for these cases, so you can perfectly replace now for getTimestamp() or getTimestamp64() depending on what data type is post.createdAt (uint or uint64), but these kind of changes will likely will be applied on future audits to these contracts, so no worries! just to share the info :)

NOTE: The danger will be there anywhere, but it should be prevented at contract design stage, by avoiding using block members for critical outcomes, since these values are gameable by miners

Source: https://github.com/aragon/aragonOS/blob/next/contracts/common/TimeHelpers.sol#L36
(TimeHelpers members are automatically inherited by every AragonApp contract, and now is just an alias to block.timeStamp)

Copy link
Collaborator

Choose a reason for hiding this comment

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

avoiding using block members for critical outcomes

Good to know about getTimestamp for AragonOS! In this case, I don't think the time at which a comment is created is a critical outcome, so I doubt it matters, but if I'd mistaken on that point I'd love for you to correct me!

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah I mean they're functionally identical, the main advantage is in testing since you can create a mock that overrides that call.

@coveralls
Copy link

coveralls commented Aug 22, 2019

Coverage Status

Coverage remained the same at 100.0% when pulling c6212bc on discussions into 2ced247 on dev.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling a34c083 on discussions into 2ced247 on dev.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling a34c083 on discussions into 2ced247 on dev.

Schwartz10 and others added 4 commits August 22, 2019 14:47
This UI shows up when you select Discussions in the sidebar. We have
nothing to show for the Discussions app itself at this point in time,
and now we explain that here.
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.

A few small comments, I'm also not seeing any getters. This might not be an issue since all of the information needed is being emitted (which as a pattern I don't love) so this probably isn't an issue. Generally I think relying on events to pull all the contract information isn't a great pattern, but that's mainly for concurrency reasons where the data would be inaccurate if received out of sequence but I don't specifically see that being a problem here so I think it's okay.

You also don't have any tests for the contract that I'm seeing.

import "@aragon/os/contracts/common/IForwarder.sol";


contract DiscussionApp is IForwarder, AragonApp {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Rename to Discussions to be conformant to contract naming conventions.

@@ -45,12 +45,12 @@ contract DiscussionApp is IForwarder, AragonApp {
post.author = msg.sender;
post.postCid = postCid;
post.discussionThreadId = discussionThreadId;
post.createdAt = now;
post.createdAt = now; // solium-disable-line security/no-block-members
Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah I mean they're functionally identical, the main advantage is in testing since you can create a mock that overrides that call.

discussionThreadId,
postId,
post.createdAt,
now // solium-disable-line security/no-block-members
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is redundant since the time information should be accessible from the event either way.

event Hide(address indexed author, uint discussionThreadId, uint postId, uint hiddenAt);
event CreateDiscussionThread(uint actionId, bytes _evmScript);

bytes32 constant public DISCUSSION_POSTER_ROLE = keccak256("DISCUSSION_POSTER_ROLE");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Having a single role for all three actions isn't exactly ideal, what I would consider doing is splitting hide into two function calls with a seperate HIDE_DISCUSSION_ROLE and then keeping the one that exists but removing the role protections. As it is in most cases the auth check will have occured at the time of post, so this pattern only serves to prevent a poster from hiding their own post if they've had posting permissions removed. I think it makes more sense for hide to be something you can always do for your own posts and a separate role can do for other peoples posts.


uint discussionThreadId;

mapping(uint => DiscussionPost[]) public discussionThreadPosts;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not sure how this will behave on an upgrade... this may need to be a mapping into another mapping instead of an array.

address author;
string postCid;
uint discussionThreadId;
uint id;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would specify unit256 for all params, and for indexes or anything else that's only being modified based on incrementation you can probably get away with a uint64.



contract DiscussionApp is IForwarder, AragonApp {
using SafeMath for uint256;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Doesn't look like you're using this anywhere.

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.

Good for now, circle back to resolve the rest of the issues.

@Schwartz10 Schwartz10 merged commit fc9f7fb into dev Aug 23, 2019
@Schwartz10 Schwartz10 deleted the discussions branch August 23, 2019 19:19
chadoh added a commit that referenced this pull request Aug 24, 2019
* dev:
  Dot voting demo fixes (#1176)
  Discussions (#1050)
  Fix linting and remove package-lock files
chadoh added a commit that referenced this pull request Aug 24, 2019
* newstyle:
  Add a minimal EMPTY_ROLE to Discussions - This is needed to be considered an actual Aragon app by the Kernel - Reference: https://hack.aragon.org/docs/cli-dao-commands#dao-install
  Remove partial ACL guards on discussions:
  Discussions: fix typos in README examples
  Dot voting demo fixes (#1176)
  Discussions (#1050)
  Fix linting and remove package-lock files
chadoh added a commit that referenced this pull request Aug 27, 2019
* newstyle: (47 commits)
  Revert Rewards & Projects to previous aragonUI
  Dot Voting: fix issues found during QA
  Dot Voting/CastVote: fix prop type
  Revert "[DEV] rm pre-commit lint"
  Dot Voting: mv totalSupport calc to VotingResults
  Dot Voting/VoteDetails: mv Participation
  Dot Voting/CastVote: rm tokenData; keep userBalance
  Dot Voting: define tokenContract in CastVote
  Dot Voting: mv CastVote to own file
  Dot Voting/VoteDetails: mv VoteEnact & VotingResults
  Add a minimal EMPTY_ROLE to Discussions - This is needed to be considered an actual Aragon app by the Kernel - Reference: https://hack.aragon.org/docs/cli-dao-commands#dao-install
  Remove partial ACL guards on discussions:
  Discussions: fix typos in README examples
  Dot voting demo fixes (#1176)
  Dot Voting/VoteDetails: mv DescriptionAndCreator
  Discussions (#1050)
  Dot Voting/VoteDetails: mv Title to own file
  Dot Voting/VoteDetail: mv Status to new file
  Dot Voting/VoteDetails: mv AppBadge to new file
  [DEV] rm pre-commit lint
  ...
chadoh added a commit that referenced this pull request Aug 27, 2019
* newstyle: (36 commits)
  Upgrade date fns (#1188)
  upgrade Rewards ADS UI (#1187)
  Aragon DS upgrade: addressbook (#1156)
  Revert Rewards & Projects to previous aragonUI
  Dot Voting: fix issues found during QA
  Dot Voting/CastVote: fix prop type
  Revert "[DEV] rm pre-commit lint"
  Dot Voting: mv totalSupport calc to VotingResults
  Dot Voting/VoteDetails: mv Participation
  Dot Voting/CastVote: rm tokenData; keep userBalance
  Dot Voting: define tokenContract in CastVote
  Dot Voting: mv CastVote to own file
  Dot Voting/VoteDetails: mv VoteEnact & VotingResults
  Add a minimal EMPTY_ROLE to Discussions - This is needed to be considered an actual Aragon app by the Kernel - Reference: https://hack.aragon.org/docs/cli-dao-commands#dao-install
  Remove partial ACL guards on discussions:
  Discussions: fix typos in README examples
  Dot voting demo fixes (#1176)
  Dot Voting/VoteDetails: mv DescriptionAndCreator
  Discussions (#1050)
  Dot Voting/VoteDetails: mv Title to own file
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants