-
Notifications
You must be signed in to change notification settings - Fork 54
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
Discussions #1050
Conversation
…ite into discussions
* 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.
apps/discussions/package.json
Outdated
"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", |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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?
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 |
There was a problem hiding this comment.
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
)
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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.
Fix lint and remove package-lock files
1 similar comment
…kevin discussions Readme updates
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.
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
* 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
* 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 ...
* 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 ...
No description provided.