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

Addressed code4arena findings in the docs #323

Merged
merged 1 commit into from
Mar 6, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -77,34 +77,6 @@ If this is the case, the function call will succeed, otherwise it will revert.
We can now add additional constraints to it by using the `grantWithCondition` function.
Below, we show four exemplary conditions for different 4 different use cases that we could attach to the permission.

### Condition 1: Checking the properties

Let’s imagine that we want to make sure that `_amount` is not more than `1 ETH` without changing the code of `Example` contract.

We can realize this requirement by deploying a `ParameterConstraintCondition` condition.

```solidity title="ParameterConstraintCondition.sol"
contract ParameterConstraintCondition is IPermissionCondition {
uint256 internal maxValue;

constructor(uint256 _maxValue) {
maxValue = _maxValue;
}

function isGranted(
address _where,
address _who,
bytes32 _permissionId,
bytes calldata _data
) external view returns (bool) {
(_where, _who, _permissionId); // Prevent compiler warnings resulting from unused arguments.

(address _to, uint256 _amount) = abi.decode(_data, (address, uint256));

return _amount <= _maxValue;
}
```

### Condition 1: Adding Parameter Constraints

Let’s imagine that we want to make sure that `_amount` is not more than `1 ETH` without changing the code of `Example` contract.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ and are introduced in the following.
For all subsequent builds and releases, `createVersion` inside the registered `PluginRepo` has to be called.
-->

### The `PuginRepoFactory` Contract
### The `PluginRepoFactory` Contract

The `PluginRepoFactory` is a contract of the Aragon OSx protocol framework infrastructure being called when the first version if a plugin is published.
It contains the `createPluginRepoWithFirstVersion`,
Expand Down Expand Up @@ -47,7 +47,7 @@ Additional to the information required by the [`createVersion` function discusse
- A valid ENS `_subdomain` name under that isn't already taken
- The address of the plugin repo maintainer who ends up having the `ROOT_PERMISSION_ID`, `MAINTAINER_PERMISSION_ID`, and `UPGRADE_REPO_PERMISSION_ID` permission allowing to call the internal `PermissionManager`, the `createVersion` and `updateReleaseMetadata` functions as well as upgrading the contract.

For more details visit the [`PuginRepoFactory` reference guide entry](../../../../03-reference-guide/framework/plugin/repo/PluginRepoFactory.md).
For more details visit the [`PluginRepoFactory` reference guide entry](../../../../03-reference-guide/framework/plugin/repo/PluginRepoFactory.md).

### The `PluginRepoRegistry` Contract

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ Different versions might contain

</div>

### The `PuginRepo` Contract
### The `PluginRepo` Contract

The `PluginRepo` contract versions the releases of a `Plugin`. The first version of a plugin is always published with the version tag `1.0`.
When you publish the first plugin version, a new plugin repository is automatically created for you by the Aragon OSx protocol in which you are the maintainer. The creation process is described in the [plugin repo creation process](./01-plugin-repo-creation.md) section.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ contract SimpleAdmin is Plugin {
</details>

:::note
We used Solidity's `immutable` keyword so that the admin variable can never be changed. Immutable variables can only be declared in the constructor.
We used Solidity's `immutable` keyword so that the admin variable can never be changed. Immutable variables can only be initialized in the constructor.
:::

The `Plugin(_dao)` constructor stores the `IDAO _dao` reference in the right place. If our plugin implementation is deployed often, which we expect, we can [save significant amounts of gas by deployment through the minimal proxy pattern](https://blog.openzeppelin.com/workshop-recap-cheap-contract-deployment-through-clones/).
Expand Down