There are unused function parameters in the unchained initializers in the Preset contracts

💻 Environment
OpenZeppelin Contracts Ethereum Package v3.0.0

📝 Details

Reported on Telegram (see forum post: https://forum.openzeppelin.com/t/unused-function-parameters-in-preset-contracts-in-openzeppelin-contracts-ethereum-package/2906)

The preset contracts have unused function parameters (name and symbol) in the unchained initializers.

https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/blob/v3.0.0/contracts/presets/ERC20PresetMinterPauser.sol#L49

https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/blob/v3.0.0/contracts/presets/ERC721PresetMinterPauserAutoId.sol#L57

🔢 Code to reproduce bug

MyNFT.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.2;

import "@openzeppelin/contracts-ethereum-package/contracts/Initializable.sol";
import "@openzeppelin/contracts-ethereum-package/contracts/presets/ERC721PresetMinterPauserAutoId.sol";


contract MyNFT is Initializable, ERC721PresetMinterPauserAutoIdUpgradeSafe {
    function initialize() public initializer {
        ERC721PresetMinterPauserAutoIdUpgradeSafe.initialize(
            "MyNFT",
            "MYN",
            "https://example.com/token/"
        );
    }
}

Compiler warnings

$ npx oz compile
✓ Compiled contracts with solc 0.6.7 (commit.b8d736ae)
Compilation warnings:
@openzeppelin/contracts-ethereum-package/contracts/presets/ERC721PresetMinterPauserAutoId.sol:57:62: Warning: Unused function parameter. Remove or comment out the variable name to silence this warning.
    function __ERC721PresetMinterPauserAutoId_init_unchained(string memory name, string memory symbol, string memory baseURI) internal initializer {
                                                             ^----------------^

@openzeppelin/contracts-ethereum-package/contracts/presets/ERC721PresetMinterPauserAutoId.sol:57:82: Warning: Unused function parameter. Remove or comment out the variable name to silence this warning.
    function __ERC721PresetMinterPauserAutoId_init_unchained(string memory name, string memory symbol, string memory baseURI) internal initializer {
                                                                                 ^------------------^

Readme:

(sreenshot)

Upgradeable Proxy Pattern:

My understanding:

• Proxy contract that delegates call
• Logic contract
• When upgrading, deploying a new logic contract, upgradeTo in the proxy contract

I do not get the pre-deployed part?

🧐 Motivation

we are using @openzeppelin/upgrades and @openzeppelin/contracts-ethereum-package in our project .
We implemented a DAOFactory contract which is based(and use) on @openzeppelin/upgrades.
We would like to be able to compile this contract + all other contracts with solc 0.6 ..
We can come out with a workaround which works with the precompiled contracts you provide (can you give a reference to a truffle project which doing so? ) though I guess that it will complicated our truffle project..I would like to avoid it.

see OpenZeppelin/openzeppelin-sdk#1463

🎉 Description

Here we are missing theindexed keyword on Approval event for ERC721 based on the EIP-721

It should look the same as openzeppelin-solidity

• 🐛 This is a bug report.

💻 Environment

OpenZeppelin Contracts Ethereum Package v3.0.0

📝 Details

GSNRecipient.sol has different abstract contract name GSNRecipientUpgradeSafe. This causes an error, when you try to use npx oz deploy.

🔢 Code to reproduce bug

GSNRecipientUpgradeSafe.sol

abstract contract GSNRecipientUpgradeSafe is Initializable, IRelayRecipient, ContextUpgradeSafe {
    function __GSNRecipient_init() internal initializer {
        __Context_init_unchained();
        __GSNRecipient_init_unchained();
    }
...
}

Counter.sol

See Sending Gasless Transactions

// contracts/Counter.sol
pragma solidity ^0.5.0;

import "@openzeppelin/contracts-ethereum-package/contracts/GSN/GSNRecipient.sol";

contract Counter is GSNRecipient {...}

Compiler errors

Compilation errors: 
contracts/Counter.sol:5:21: DeclarationError: Identifier not found or not unique.
contract Counter is GSNRecipient {

Latest minor updates (1.9.2, 1.9.3 and 1.9.4) were not deployed to Rinkeby. Please consider providing support for that testnet as well.

🧐 Motivation
Feedback in the Community Forum: https://forum.openzeppelin.com/t/how-to-use-ownable-with-upgradeable-contract/3336/8

📝 Details

1. Add documention on the docsite on how to use:
2. What to import
3. What to extend (UpgradeSafe version) and Initializable (and in what order)
4. What Initializers to call from dependencies

When using the StandaloneERC20 as per the guide if you pick "No" when asked to call a function after deployment, an error is produced.

? Pick a contract to instantiate @openzeppelin/contracts-ethereum-package/StandaloneERC20
? Pick a network development
√ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-1564745320775
All contracts are up to date
? Do you want to call a function on the instance after creating it? No
Possible initialization method (initialize) found in contract. Make sure you initialize your instance.
Invalid JSON RPC response: ""

Reproduce by following above flow.

Recommended fix: remove Yes/No option from contracts that can't be deployed without those an init function being called.

💻 Environment

• Windows 10 + Cmder
• [email protected]
• openzeppelin-cli 2.5.1

💻 Environment
@openzeppelin/[email protected]
@openzeppelin/[email protected]
solc 0.5.2

📝 Details
I want to call the contract by balanceOf method, but i got below error

 Error: Invalid number of parameters for "balanceOf". Got 1 expected 7!

I printed the balanceOf ABI. It's magical, i guess they are conflicts

console.log(proxy._jsonInterface.find(item => item.name === 'balanceOf'))

🔢 Code to reproduce bug

There seems to be no way to call setTokenURI for ERC721 tokens when using stdlib.

MintableERC721Token only exposes address and tokenId
https://github.com/OpenZeppelin/openzeppelin-zos/blob/6e5596e80c6bc6746ed02be89c7e50ba771edec6/contracts/token/ERC721/MintableERC721Token.sol#L16

ERC721 setTokenUri is internal only
https://github.com/OpenZeppelin/openzeppelin-zos/blob/6e5596e80c6bc6746ed02be89c7e50ba771edec6/contracts/token/ERC721/ERC721Token.sol#L106

This behaviour is fine when inheriting from ERC721, but becomes inaccessbile when using an already deployed instance.
There is no other public method available to set the uri.

🎉 Description

Here we are missing theindexed keyword on Transfer event for ERC721 based on the EIP-721

It should look the same as openzeppelin-solidity

• 🐛 This is a bug report.

Hi,

🧐 Motivation
@openzeppelin/contracts-ethereum-package and @openzeppelin/contracts share many contracts names. The duplication prevents the correct compilation artifacts to be generated if a codebase uses both packages.

📝 Details
Most of the compilation frameworks do not handle well codebase with contract's name duplicate. For example, when generating the json artifacts, Truffle will not be able to generate correctly the files trufflesuite/truffle#1087.

As a result, it can prevent the integration with third-party tools. For example, we had to develop a specific detector in Slither to know what contracts names are reused. But if a codebase uses both @openzeppelin/contracts-ethereum-package and @openzeppelin/contracts, it is difficult for a user to avoid the duplicate names.

Example
A codebase that would have both an upgradeable ERC20 token a non-upgradeable one will be affected:

// contracts/UpgradeableERC20.sol
import '@openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20.sol';

contract UpgradeableERC20 is ERC20 {
}

// contracts/NonUpgradeableERC20.sol
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract NonUpgradeableERC20 is ERC20 {
}

Running truffle compile on a codebase with these two files will result in one build/contracts/ERC20.json file that will either represent @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20.sol or @openzeppelin/contracts/token/ERC20/ERC20.sol.

A better practice would be to have separate contract names according to the package.

Let me know if you have any questions,
Thanks!

Due to the added gaps for future compatibility, the storage layout of all contracts has changed from version 1.x to 2.0. In particular, this affects ERC20 and ERC721, the two most widely used contracts.

We should add a migration method from the old version of these contracts to the new ones. This method should know the storage layout for both the old and the new implementations, and copy them as needed. It is possible that the migration requires more than a single tx, since several balances may need to be copied.

This method should not in the regular contracts, but added as separate ones, similar to the ERC20Migration.

It's not clear to users why this package exists, why they have to use it, if they have to install it side-by-side with OpenZeppelin, etc.

We should improve the README first and foremost, and also check if the ZeppelinOS docs make all of this clear enough.

Additionally we should explain to people how they are expected to reuse the OpenZeppelin contracts that are on-chain within their custom systems.

Applies to Ownable, MinterRole, etc.

• Mainnet
• Ropsten
• Rinkeby
• Kovan

StandaloneERC20 symbol function shows an address parameter. symbol(account: address)
First reported in the Community Forum: https://forum.openzeppelin.com/t/sdk-testing-getting-invalid-number-of-parameters/1570

💻 Environment

"@openzeppelin/contracts-ethereum-package": "^2.3.0"

$ oz --version
2.5.3

📝 Details

Occurs on version 2.3.0 but not 2.2.3

🔢 Code to reproduce bug

mkdir token
cd token
npm init -y
oz init
oz link @openzeppelin/contracts-ethereum-package

Create token on ganache-cli

$ oz create
No contracts found to compile.
? Pick a contract to instantiate @openzeppelin/contracts-ethereum-package/StandaloneERC20
? Pick a network development
✓ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-1571358909036
All contracts are up to date
? Do you want to call a function on the instance after creating it? Yes
? Select which function * initialize(name: string, symbol: string, decimals: uint8)
? name (string): Test Token
? symbol (string): TST
? decimals (uint8): 18
✓ Setting everything up to create contract instances
✓ Instance created at 0x4bf749ec68270027C5910220CEAB30Cc284c7BA2
0x4bf749ec68270027C5910220CEAB30Cc284c7BA2

Attempt to call symbol

$ oz call
? Pick a network development
? Pick an instance StandaloneERC20 at 0x4bf749ec68270027C5910220CEAB30Cc284c7BA2
? Select which function symbol(account: address)
? account (address): 0x4bf749ec68270027C5910220CEAB30Cc284c7BA2
✖ Calling: 'symbol' with:
- account (address): "0x4bf749ec68270027C5910220CEAB30Cc284c7BA2"
Error while trying to call 0x4bf749ec68270027C5910220CEAB30Cc284c7BA2#symbol(address). Error: Returned error: VM Exception while processing transaction: revert

Reverting to 2.2.3 resolves the issue

npm uninstall @openzeppelin/contracts-ethereum-package
oz link @openzeppelin/[email protected]

$ oz create
No contracts found to compile.
? Pick a contract to instantiate @openzeppelin/contracts-ethereum-package/StandaloneERC20
? Pick a network development
✓ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-1571358909036
All contracts are up to date
? Do you want to call a function on the instance after creating it? Yes
? Select which function * initialize(name: string, symbol: string, decimals: uint8)
? name (string): Test Token
? symbol (string): TST
? decimals (uint8): 18
✓ Setting everything up to create contract instances
✓ Instance created at 0x1b88Bdb8269A1aB1372459F5a4eC3663D6f5cCc4
0x1b88Bdb8269A1aB1372459F5a4eC3663D6f5cCc4

$ oz call
? Pick a network development
? Pick an instance StandaloneERC20 at 0x1b88Bdb8269A1aB1372459F5a4eC3663D6f5cCc4
? Select which function symbol()
✓ Method 'symbol()' returned: TST
TST

Contracts have an undocumented uint256[50] private ______gap;

This variable should be documented with a very clear explanation, because it's weird.

🧐 Motivation
Many developers choose Ethereum Classic to deploy their contracts to. By January, ETC's upcoming Agartha hard fork will provide feature-parity with Constantinople. It would be useful to developers on ETC if the openzeppelin-contracts-ethereum-package contracts could be deployed to Ethereum Classic's mainnet and the primary testnet Kotti (https://github.com/goerli/testnet).

📝 Details
I have tried to deploy this myself manually. I have an ETC account with a balance on it and I have the following settings in my network.js file:

require('dotenv').config();
const HDWalletProvider = require('truffle-hdwallet-provider');
module.exports = {
  compilers: {
    solc: {
      version: '0.5.1',
      settings: {
        evmVersion: 'byzantium'
      }
    }
  },
  networks: {
    kotti: {
      provider: () => new HDWalletProvider(
        [process.env.DEV_PRIVATE_KEY], 
        "https://www.ethercluster.com/kotti"),
      networkId: '6'
    }
  }
};

Here is the output I get from open-zeppelin-sdk:

$ openzeppelin push                                                
Nothing to compile, all contracts are up to date.
? Pick a network kotti
? One or more linked dependencies are not yet deployed on dev-6.
Do you want to deploy them now? Yes
✖ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-6
Failed deployment of dependency @openzeppelin/contracts-ethereum-package with error: Failed to check for transaction receipt:
{}

I think this is probably just one of many upgrading issues, but it would be nice if there was a way to handle this in codebases that are upgrading to solidity 0.5.

openzeppelin-eth/contracts/token/ERC20/ERC20.sol:189:13:
TypeError: Operator != not compatible with types address and int_const 0
    require(account != 0);

🧐 Motivation
This is in relation to OpenZeppelin/openzeppelin-contracts#2234 and OpenZeppelin/openzeppelin-contracts#2235

📝 Details
As of Solidity 0.6.8 Solidity issues warnings on all contracts that has no SPDX license identifier as shown by the image below.

Until we support initialization of logic contracts in zOS, self-destructable contracts are open to being accidentally killed (see https://github.com/OpenZeppelin/openzeppelin-zos/blob/master/contracts/drafts/BreakInvariantBounty.sol#L68 for an example).

We should remove all selfdestruct calls from the oz-zos codebase.

Thanks @cwhinfrey for the report!

The latest available version is 3.0.0

RelayHub's ABI has changed in tabookey-gasless (the withdraw method has changed). We need to update it locally as well.

This implies modifying the withdraw internal method on GSN context as well (and removing the payable fallback function we had to add to support the old version).

🎉 Description

• 🐛 This is a bug report.
• 📈 This is a feature request.

💻 Environment

Next, we need to know what your environment looks like.

• Which version of OpenZeppelin are you using?
• What network are you deploying to? Ganache? Ropsten?
• How are you deploying your OpenZeppelin-backed contracts? truffle? Remix? Let us know!

📝 Details

Describe the problem you have been experiencing in more detail. Include as much information as you think is relevant. Keep in mind that transactions can fail for many reasons; context is key here.

🔢 Code To Reproduce Issue [ Good To Have ]

Please remember that with sample code it's easier to reproduce the bug and it's much faster to fix it.

insert short code snippets here

👍 Other Information

🧐 Motivation
When StandaloneERC20, StandaloneERC721, TokenVesting, PaymentSplitter are deployed to networks (Mainnet, Kovan, Ropsten, and Rinkeby) they would ideally be verified on Etherscan, as can't verify using the CLI, so have to manually verify.

e.g. StandaloneERC20 logic contract: https://ropsten.etherscan.io/address/0xe491769618d3acfbbdc403841a66fc1023e711c6#code

📝 Details

Create a StandaloneERC20 contract:

$ npx oz create
No contracts found to compile.
? Pick a contract to instantiate @openzeppelin/contracts-ethereum-package/StandaloneERC20
? Pick a network ropsten
✓ Linked dependency @openzeppelin/contracts-ethereum-package 2.2.3
All contracts are up to date
? Do you want to call a function on the instance after creating it? Yes
? Select which function * initialize(name: string, symbol: string, decimals: uint8, initialSupply: uint256, initialHolder: address, minters: address[], pausers: address[])
? name (string): My Token
? symbol (string): TKN
? decimals (uint8): 18
? initialSupply (uint256): 10000e18
? initialHolder (address): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1
? minters (address[]): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1
? pausers (address[]): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1
✓ Setting everything up to create contract instances
✓ Instance created at 0x8b5Cc25340457339AFB0F3b739214cD27aBE13aD
0x8b5Cc25340457339AFB0F3b739214cD27aBE13aD

The logic contract can't be verified using the CLI. Ideally it would be verified when the Ethereum Package logic contracts are deployed to the networks.

$ npx oz verify
? Pick a network ropsten
A contract alias must be specified

ropsten.json

  "proxies": {
    "@openzeppelin/contracts-ethereum-package/StandaloneERC20": [
      {
        "address": "0x8b5Cc25340457339AFB0F3b739214cD27aBE13aD",
        "version": "2.2.3",
        "implementation": "0xe491769618D3acFbBdC403841a66FC1023E711C6",
        "admin": "0x94E01684a8853bb6Fb7F3bc71D2e0a02729B2D5D",
        "kind": "Upgradeable"
      }
    ]
  }

StandaloneERC20 logic contract: https://ropsten.etherscan.io/address/0xe491769618d3acfbbdc403841a66fc1023e711c6#code

If the dev is upgrading from a non-GSN contract to one that is, they need to manually set the relayhub address on the contract. It is highly likely that they forget doing this.

A valid fix is assuming that the hub address is the singleton one, if it is not set. Evaluate whether this is a good solution, and if so, implement it.

On version 1.9.2, we are listing zos-lib@^0.1.26 as a required peer dependency, which should be upgradeable to the 1.4.1 being used by the CLI now.

Check if the the dependency is actually needed, and can be removed or upgraded.

Reported by @ghostbuster91 in OpenZeppelin/openzeppelin-contracts#1012.

Hi, right now openzeppelin-zos is deployed on mainnet, ropsten and rinkeby but not on kovan. Since kovan uses POA it is much faster than other chains, and so more pleasant for development.

I know that it should be possible to deploy openzeppelin-zos to kovan using zos cli, simply invoking:
zos push --deploy-stdlib --network kovan but there is a problem with that (zeppelinos/zos-cli#256)

Have all contracts inherit from a base context that defines msgSender and msgData with their default implementations, so they can be overridden by the GSN context.

Port this change to oz/contracts as well.

https://github.com/OpenZeppelin/openzeppelin-contracts runs on compiler 6.0+ current npm version 2.5.0 of this repo runs with compiler 5.0

To prevent arguments from being passed multiple times in the case of diamond inheritance, we don't call the parent initializers. When using constructors, the compiler would report the contract was abstract, but that doesn't happen with initializer functions.

Consider SampleCrowdsale:

contract SampleCrowdsale is Initializable, CappedCrowdsale, RefundableCrowdsale, MintedCrowdsale

Its initialization looks like:

Crowdsale.initialize(rate, wallet, token);
CappedCrowdsale.initialize(cap);
TimedCrowdsale.initialize(openingTime, closingTime);
RefundableCrowdsale.initialize(goal);

This is fairly non-obvious to most users, but is the natural result of taking this route. A simple improvement that can be made to prevent these sort of mistakes is to add assert statements in the initializers of derived contracts, verifying that their parents have been initialized (despite them not doing so). For example, a TimedCrowdsale may check that the base rate, wallet and token are non-zero. These checks are somewhat fragile in that it is difficult to make sure all of the relevant ones have been added, but they an objective improvement over the current situation.

Merge the changes from OpenZeppelin/openzeppelin-contracts#1843 into this package.

We are working on updating the solidity version from 0.5.16 to 0.6.5
pragma solidity 0.6.5;
When changing the solc version and contract solidity version we got an issue as are using ownable.sol from "@openzeppelin/contracts-ethereum-package": "^2.5.0" in our project.
When openzeppelin/contracts-ethereum-package package gonna support new solitidy version and updated ownable into 0.6.5

https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/blob/bf0277b398c0454276bd8caf0ee35efaf46e686b/contracts/ownership/Ownable.sol#L1

MintableERC20 and the onlyMinter modifier ?

A contract with imports of contracts from both Contracts and the upgrade safe fork of Contracts that use libraries such as Address and SafeMath fails to compile with error Identifier already declared.

💻 Environment
OpenZeppelin Contracts 3.2.0
OpenZeppelin Contracts Ethereum Package 3.0.0

$ npx truffle version
Truffle v5.1.48 (core: 5.1.48)
Solidity - 0.6.12 (solc-js)
Node v10.22.1
Web3.js v1.2.1

📝 Details

The upgrade safe fork of Contracts has the UpgradeSafe suffix on contracts but doesn't on libraries such as SafeMath and Address. When compiling a contract that imports from both of these you get Identifier already declared

Reported by a community member in the forum, who added the suffix to libraries to resolve: https://forum.openzeppelin.com/t/using-openzeppelin-contracts-and-upgrade-safe-versions-in-the-same-project/4140

🔢 Code to reproduce bug

Contract that imports contracts from Contracts and Upgrade Safe fork that use libraries.

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.2;

import "@openzeppelin/contracts/presets/ERC20PresetMinterPauser.sol";
import "@openzeppelin/contracts-ethereum-package/contracts/presets/ERC20PresetMinterPauser.sol";

contract MyContract {
}

$ npx truffle compile

Compiling your contracts...
===========================
> Compiling ./contracts/Migrations.sol
> Compiling ./contracts/MyContract.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/GSN/Context.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/Initializable.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/access/AccessControl.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/presets/ERC20PresetMinterPauser.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Burnable.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Pausable.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/IERC20.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/utils/Address.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/utils/EnumerableSet.sol
> Compiling @openzeppelin/contracts-ethereum-package/contracts/utils/Pausable.sol
> Compiling @openzeppelin/contracts/GSN/Context.sol
> Compiling @openzeppelin/contracts/access/AccessControl.sol
> Compiling @openzeppelin/contracts/math/SafeMath.sol
> Compiling @openzeppelin/contracts/presets/ERC20PresetMinterPauser.sol
> Compiling @openzeppelin/contracts/token/ERC20/ERC20.sol
> Compiling @openzeppelin/contracts/token/ERC20/ERC20Burnable.sol
> Compiling @openzeppelin/contracts/token/ERC20/ERC20Pausable.sol
> Compiling @openzeppelin/contracts/token/ERC20/IERC20.sol
> Compiling @openzeppelin/contracts/utils/Address.sol
> Compiling @openzeppelin/contracts/utils/EnumerableSet.sol
> Compiling @openzeppelin/contracts/utils/Pausable.sol

> Compilation warnings encountered:

... [SPDX warnings]

CompileError: /home/abcoathup/projects/forum/example/contracts/MyContract.sol:5:1: DeclarationError: Identifier already declared.
import "@openzeppelin/contracts-ethereum-package/contracts/presets/ERC20PresetMinterPauser.sol";
^----------------------------------------------------------------------------------------------^
@openzeppelin/contracts/utils/Address.sol:8:1: The previous declaration is here:
library Address {
^ (Relevant source part starts here and spans across multiple lines).
,/home/abcoathup/projects/forum/example/contracts/MyContract.sol:5:1: DeclarationError: Identifier already declared.
import "@openzeppelin/contracts-ethereum-package/contracts/presets/ERC20PresetMinterPauser.sol";
^----------------------------------------------------------------------------------------------^
@openzeppelin/contracts/utils/EnumerableSet.sol:29:1: The previous declaration is here:
library EnumerableSet {
^ (Relevant source part starts here and spans across multiple lines).
,/home/abcoathup/projects/forum/example/contracts/MyContract.sol:5:1: DeclarationError: Identifier already declared.
import "@openzeppelin/contracts-ethereum-package/contracts/presets/ERC20PresetMinterPauser.sol";
^----------------------------------------------------------------------------------------------^
@openzeppelin/contracts/token/ERC20/IERC20.sol:8:1: The previous declaration is here:
interface IERC20 {
^ (Relevant source part starts here and spans across multiple lines).
,/home/abcoathup/projects/forum/example/contracts/MyContract.sol:5:1: DeclarationError: Identifier already declared.
import "@openzeppelin/contracts-ethereum-package/contracts/presets/ERC20PresetMinterPauser.sol";
^----------------------------------------------------------------------------------------------^
@openzeppelin/contracts/math/SafeMath.sol:18:1: The previous declaration is here:
library SafeMath {
^ (Relevant source part starts here and spans across multiple lines).

Compilation failed. See above.
    at run (/home/abcoathup/projects/forum/example/node_modules/truffle/build/webpack:/packages/compile-solidity/run.js:51:1)
Truffle v5.1.48 (core: 5.1.48)
Node v10.22.1

trying to use erc721full from this package but cannot initialize it correctly. the compiler is telling me that the constructor shouldnt have any arguments. error gets thrown at here. everything works when i switch the library to the original onezeppelin/contracts library

💻 Environment

im using zepkit from the site.

🔢 Code to reproduce bug

`import "@openzeppelin/contracts-ethereum-package/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts-ethereum-package/contracts/token/ERC721/IERC721Enumerable.sol";
import "@openzeppelin/contracts-ethereum-package/contracts/token/ERC721/ERC721Enumerable.sol";
import "@openzeppelin/contracts-ethereum-package/contracts/token/ERC721/IERC721Metadata.sol";
import "@openzeppelin/contracts-ethereum-package/contracts/token/ERC721/ERC721Metadata.sol";
import "@openzeppelin/contracts-ethereum-package/contracts/token/ERC721/ERC721Full.sol"
contract Thing is ERC721Full, ERC721MetadataMintable, ERC721Burnable, Ownable {
using SafeMath for uint256;
struct Price {
uint256 tokenId;
uint256 price;
string metaId;
TokenState state;
}

mapping(uint256 => Price) public items;
constructor(
    string memory name,
    string memory symbol,
    string memory uri,
    address payable fee,
    address payable creator
) public ERC721Full(name, symbol) {
    maker = creator;
    feeAddress = fee;
    baseUri = uri;
    id = 0;
    transferOwnership(creator);
    _addMinter(creator);

}}`

Abstract

We are trying to update from a previous version of OZ to the latest.

We had automation scripts in charge of deploying things on dev / staging environments before and they broke.

The commands we were issuing before were something like:

yarn oz create Access --skip-compile --init initialize $zosArgs --args "$GOVERNOR"

We saw the notice during deployment that create was deprecated, so we used deploy instead. However, we're stuck for several reasons.

The --kind Argument

The documentation for the new required --kind argument shows:

By trial and error, we found out that --kind upgradeable would probably be the equivalent of what we had before (our contracts inherit from @openzeppelin/upgrades/contracts/Initializable.sol).
Is that correct? I would hint that it's not.
Reading the documentation tells us that the inheritance from Initializable.sol doesn't seem to be required anymore - but in that case, how would we migrate contracts that inherit from Initializable.sol in production?

The --init Argument

As we're trying to get the new oz deploy command to run with the --no-interactive flag, we're also trying to understand how to have the old equivalent of --init to work. From what I understand, there's no such thing - what's the right way of doing things here?

As part of #56, change the GSNContext private relayHub address to use unstructured storage, to allow any contract to easily upgrade to using it.

Not sure if this is a bug or intentional feature, but looks like all the roles in
https://github.com/OpenZeppelin/openzeppelin-eth/blob/master/contracts/access/roles/

only restrict the addRole function to an account with the same level of permission. This does not allow for hirachial permissions. Any Minter role for instance can add more minters to the contract

Also the renounceMinter seems to be not restricted at all

This fork is behind openzeppelin-solidity.

OpenZeppelin 2.0 is being released soon. We should update this package to 2.0.

Adding new storage variables to a contract that has been extended by another is impossible, since the storage from the child contract will clash with the new variables added by the parent. To mitigate this, we can "reserve" a few slots in the base contracts, to allow for new variables to be added later. This could be done by declaring some fixed-length uint256 arrays in storage, until ethereum/solidity#4519 is implemented.

When running npm run lint you get several warnings and 9 errors (see screenshot below)

This PR is intended to fix only the errors, as I understand the warnings are related to well known naming conventions defined by the OZ team (mainly camelCase naming requirement).

IMPORTANT NOTE: One of the errors was related to naming of private variables in the Initialize.sol contract which is extremely crucial. Even though they do not represent API or breaking changes should be double-checked if this contract wants to be modified.

💻 Environment

Repo: @openzeppelin/open-zeppelin-contracts-ethereum-package
Version: 3.0.0Branch:master`

📝 Details

🔢 Code to reproduce bug
1 - Clone repo - master branch
2 - npm install
3- npm run lint

Goerli is now a thing and is working fine with Infura. @spalladino has already created an issue to support it on ZeppelinOS. We may also want to consider publishing openzeppelin-eth to it 🙂.

Given that some contracts are not included in openzeppelin-zos, users need to import them from openzeppelin-solidity, such as Destructible. However, that poses a problem, as Destructible imports
Ownable from -solidity, which clashes with the implementation provided in -zos, and fails with a compile error. This may affect any other contract that also extends from contracts from both repos.

import "openzeppelin-zos/contracts/ownership/Ownable.sol";
import "openzeppelin-zos/contracts/lifecycle/Pausable.sol";
import "openzeppelin-solidity/contracts/lifecycle/Destructible.sol";
import "openzeppelin-solidity/contracts/math/SafeMath.sol";
import "zos-lib/contracts/migrations/Migratable.sol";

contract MyContract is Migratable, Ownable, Pausable, Destructible {
  // ...
}

Note that, in this case, using -solidity's Destructible would be an error, since its owner cannot be initialized on proxy creation due to lack of an initializer; but we should plan for users attempting to mix contracts from both repos.

We currently have some constant state variables that are defined next to the declaration in the contracts, like:

contract Foo {
  uint public constant x = 1234;
}

This works because the value is inlined into the bytecode and not written to storage. If it was written to storage it would be a problem because it would be written in the storage of the implementation whereas the proxy would try to read it from its own storage. Note that this kind of variable definition is an implicit part of the constructor.

We've experimentally verified that the compiler behaves in this way (i.e. inlining the value) with string, uint, and bytes4 types which are those found in OpenZeppelin 2.0. However, we are opening this issue because it is not really a guarantee of the compiler that this will always remain so. In fact, it would be correct if the compiler decided to write to storage and read from it. So we have to keep this in mind and review it.

📝 Details
Is there any solidity 0.7 support?

On version 1.9.4, attempting to create a contract that is both detailed preminted and pausable yields an error Linearization of inheritance graph impossible:

contract MyToken is PausableToken, DetailedPremintedToken {
  function initialize() 
    isInitializer("MyToken", "1.0.0")
    public
  {
    uint8 decimals = 18;
    uint256 totalSupply = 1e8 * (10 ** uint256(decimals));
    DetailedPremintedToken.initialize(
      msg.sender, 
      "My Token", 
      "MYT",
      decimals,
      totalSupply
    );
  }
}

My guess is that this is caused by all of these contracts extending from Migratable, which is affecting the multiple inheritance. I think we should consider:

• Removing Migratable from all the mixins we have (such as PausableToken),
• Switching initialize to a regular internal function that must be manually called,
• Keeping the Migratable (or Initializable) ancestor only on the leaves (such as DetailedPreminted)

🎉 Description

npm WARN [email protected] requires a peer of [email protected] but none is installed. You must install peer dependencies yourself.

I believe this is causing an issue with the zeppelinOS zos create command as it returns a "ProviderError" and doesn't recognize any of my accounts with test eth in them.

• [X ] 🐛 This is a bug report.

💻 Environment

Next, we need to know what your environment looks like.

• Which version of OpenZeppelin are you using? "zos": "2.0.1", "openzeppelin-eth": "^2.0.2", "truffle-hdwallet-provider": "0.0.6"
• What network are you deploying to? Ganache? Ropsten? Rinkeby
• How are you deploying your OpenZeppelin-backed contracts? truffle? Remix? Let us know! zeppelinOS

🔢 Code To Reproduce Issue [ Good To Have ]

npm install openzeppelin-eth

With the latest implementation of Ownable.sol , there is no way straight fwd way to set owner other than the deployer.
https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/blob/master/contracts/access/Ownable.sol#L23
One need to deploy and then need to transferOwnership from the deployer account.

This is not so optimal pattern , especially , if using the upgradable proxy pattern where the actual deployer..is the a contract which does not provide a way to do that ...like this

In the previous implementation of Ownable there was an initilize function which enable that.
/** * @dev Initializes the contract setting the deployer as the initial owner. */ function initialize(address sender) public initializer { _owner = sender; emit OwnershipTransferred(address(0), _owner); }