From 4e10ab43e209c46bb0a15ca9453d595179483fe7 Mon Sep 17 00:00:00 2001 From: Michael Heuer Date: Mon, 6 Mar 2023 13:50:32 +0100 Subject: [PATCH] Addressed code4arena findings in the docs --- .../01-core/02-permissions/01-conditions.md | 28 ------------------- .../01-plugin-repo/01-plugin-repo-creation.md | 4 +-- .../01-plugin-repo/index.md | 2 +- .../01-initialization.md | 2 +- 4 files changed, 4 insertions(+), 32 deletions(-) diff --git a/packages/contracts/docs/osx/01-how-it-works/01-core/02-permissions/01-conditions.md b/packages/contracts/docs/osx/01-how-it-works/01-core/02-permissions/01-conditions.md index 53a88a6b7..fc856036d 100644 --- a/packages/contracts/docs/osx/01-how-it-works/01-core/02-permissions/01-conditions.md +++ b/packages/contracts/docs/osx/01-how-it-works/01-core/02-permissions/01-conditions.md @@ -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. diff --git a/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/01-plugin-repo-creation.md b/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/01-plugin-repo-creation.md index accd43d78..b7d0b7247 100644 --- a/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/01-plugin-repo-creation.md +++ b/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/01-plugin-repo-creation.md @@ -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`, @@ -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 diff --git a/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md b/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md index d299249a8..32539e3da 100644 --- a/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md +++ b/packages/contracts/docs/osx/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md @@ -25,7 +25,7 @@ Different versions might contain -### 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. diff --git a/packages/contracts/docs/osx/02-how-to-guides/02-plugin-development/03-non-upgradeable-plugin/01-initialization.md b/packages/contracts/docs/osx/02-how-to-guides/02-plugin-development/03-non-upgradeable-plugin/01-initialization.md index 5215f2161..d16b9c424 100644 --- a/packages/contracts/docs/osx/02-how-to-guides/02-plugin-development/03-non-upgradeable-plugin/01-initialization.md +++ b/packages/contracts/docs/osx/02-how-to-guides/02-plugin-development/03-non-upgradeable-plugin/01-initialization.md @@ -43,7 +43,7 @@ contract SimpleAdmin is Plugin { :::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/).