If 'Ownable' is the account which migrated the contract, how can this be used for giving a 'user' and not the deployer permission?

Question

Caveat: new dapp developer here, so probably missing something.

For the openzeppelin-solidity Ownable contract, if the owner address is set in the constructor, and the msg.sender is the address of the account which migrated the contract to the network - how can a simple user (whom should take the role of admin) ever be the owner? In my dapp, users aren't responsible for migrating contracts themselves. The user I'm referring to would be an administrator, and therefore having a contract which inherits Ownable would be ideal; I'm just not sure on why the owner's address needs to be the person who migrated the contract.

Answer 1

owner is not special in any way although, by convention, it's an address representing a privileged user. Importantly, it has meaning only by interpretation in the contract, usually something like:

require(msg.sender == owner);

It's customary to bootstrap a contract by setting owner to msg.sender in the constructor so it has a non-null value and so we know the deployer (they who deployed the contract) can sign transactions.

The "deployer" may be a developer and the "owner" is often a sponsor, so it's routine to transfer the ownership to the proper custodian. This is typically done with a transaction to function changeOwner(address newOwner) .... The original owner is usually the only account that can sign such a transaction, owing to the rule that only the owner can transfer ownership. Something like:

function changeOwner(address newOwner) public onlyOwner ...

It's also a de facto standard to issue the initial supply of a fixed-supply token to the deployer. Often the developer isn't the sponsor (or treasurer) so it would be part of the migration process to transfer the tokens to the custodian.

A choreographed migration process can be scripted with truffle migrations, or it can be done manually. It might go something like:

1. Developer deploys token contract (developer receives the total supply).
2. Developer deploys crowdsale contract (developer assumes owner role).
3. Developer transfers 100% of tokens from self to the crowdsale contract.
4. Developer changes ownership of the crowsale contract from self to custodian.
5. Developer account has no tokens and no privileges.
6. Crowdsale contract has 100% of the token supply in "inventory" for sale.
7. Custodian has the privilege of starting/stopping the crowdsale and withdrawing ETH collected by the contract.

There is, of course, plenty of latitude for customization.

Hope it helps.

Answer 2

Naturally, I stumble across a potential answer after posting!

Taken from: https://medium.com/codexprotocol/a-simple-framework-for-deploying-ownable-contracts-63ed4bd3c657

Q: Why can’t the Ownable constructor be updated to accept an owner address at deployment time instead of having to call transferOwnership?

A: This can actually be done for any case that doesn’t require post-deployment steps BUT it does mean modifying the Ownable contract which has its own risk. For any case that does require post-deployment steps (e.g., minting tokens after the token contract is deployed), this can’t be done. If the owner is not the same as msg.sender, then it would be impossible for the deployer to do anything other than deploying the contract itself.