Raphaelpg

.gitignore

@@ -0,0 +1,113 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+lerna-debug.log*
+
+# Diagnostic reports (https://nodejs.org/api/report.html)
+report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+*.lcov
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+#Typescript compiled JS
+build/
+
+# TypeScript v1 declaration files
+typings/
+
+# TypeScript cache
+*.tsbuildinfo
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Microbundle cache
+.rpt2_cache/
+.rts2_cache_cjs/
+.rts2_cache_es/
+.rts2_cache_umd/
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variables file
+.env
+.env.test
+
+# parcel-bundler cache (https://parceljs.org/)
+.cache
+
+# Next.js build output
+.next
+
+# Nuxt.js build / generate output
+.nuxt
+dist
+
+# Gatsby files
+.cache/
+# Comment in the public line in if your project uses Gatsby and *not* Next.js
+# https://nextjs.org/blog/next-9-1#public-directory-support
+# public
+
+# vuepress build output
+.vuepress/dist
+
+# Serverless directories
+.serverless/
+
+# FuseBox cache
+.fusebox/
+
+# DynamoDB Local files
+.dynamodb/
+
+# TernJS port file
+.tern-port
+
+# VSCode folder
+.vscode/
+.vscode
+vscode/
+vscode

README.md

@@ -1,34 +1,42 @@
 ## Introduction
 
-Solidity is the primary language for developing smart contracts on blockchain platforms such as Celo. A common use case of blockchain technology is to build supply chain solutions, enabling transparent and immutable tracking of assets from production to delivery. This challenge involves creating a simple supply chain contract using Solidity.
+This is an answer to CELO [Blockchain-Supply-Chain-Tracking-Assets-in-Solidity-Coding-Challenge](https://github.com/celo-academy/Blockchain-Supply-Chain-Tracking-Assets-in-Solidity-Coding-Challenge) developed with Hardhat, the contract is coded in Solidity and tests in JavaScript.
 
-## Problem Statement
+The main purpose of this repository is to provide an educational example for a basic Supply Chain problem, while teaching basic Solidity principles and how to test them.
 
-Design a smart contract that facilitates a basic supply chain for tracking assets with the following requirements:
+Contract and tests are commented for an easy understanding.
 
-1. The contract should allow producers to register new assets, each with a unique ID and additional details such as product type, production date, and origin.
-2. The contract should allow assets to be transferred from the producer to a carrier, from the carrier to a retailer, and from the retailer to a consumer.
-3. Each transfer should update the asset's current holder and maintain a history of all past holders.
-4. The contract should allow anyone to check an asset's current holder and its holder history by querying the asset's unique ID.
-5. The contract should prevent an asset's details from being altered once it is registered.
+## How to run
 
-## Hints
+Clone repository and install dependencies.\
+There is one contract called SupplyChainTracking.sol included in the "contracts" folder.\
+Test files are included inside the "test" folder.\
+To compile the contract run:
+```
+npx hardhat compile
+```
+To run the test suite:
+```
+npx hardhat test
+```
+You can also visit [https://remix.ethereum.org/](https://remix.ethereum.org/) to deploy and play with the contract.
 
-- Use a `struct` to define an asset with attributes like ID, product type, production date, origin, current holder, and holder history.
-- Use `mapping` to link asset IDs with their respective asset data.
-- Use `msg.sender` to track the current holder during asset transfers.
-- Use `modifier` functions to enforce restrictions, such as preventing changes after an asset is registered.
+## Challenge requirements:
 
-## Evaluation Criteria
+Design a smart contract that facilitates a basic supply chain for tracking assets with the following requirements:
 
-- **Correctness**: The contract should compile without errors and fulfill all the requirements.
-- **Readability**: The contract should be well-documented, with comments explaining the code.
-- **Testability**: You should also provide examples of how to test each function of the contract.
+1. [x] The contract should allow producers to register new assets, each with a unique ID and additional details such as product type, production date, and origin.
+2. [x] The contract should allow assets to be transferred from the producer to a carrier, from the carrier to a retailer, and from the retailer to a consumer.
+3. [x] Each transfer should update the asset's current holder and maintain a history of all past holders.
+4. [x] The contract should allow anyone to check an asset's current holder and its holder history by querying the asset's unique ID.
+5. [x] The contract should prevent an asset's details from being altered once it is registered.
+6. [x] Use a `struct` to define an asset with attributes like ID, product type, production date, origin, current holder, and holder history.
+7. [x] Use `mapping` to link asset IDs with their respective asset data.
+8. [x] Use `msg.sender` to track the current holder during asset transfers.
+9. [x] Use `modifier` functions to enforce restrictions, such as preventing changes after an asset is registered.
 
-Please note, managing asset information on a supply chain requires considerations for privacy and security. This challenge does not cover all aspects of a real-world decentralized supply chain system.
+## Warning
 
-For a comprehensive understanding of Celo smart contracts and Solidity, please refer to the Celo and Solidity tutorials.
-
-## Submission
+Please note, managing asset information on a supply chain requires considerations for privacy and security. This challenge does not cover all aspects of a real-world decentralized supply chain system.
 
-Please reply with a link to your PR on GitHub, including your supply chain contract. Also, include any notes or comments you think are necessary to understand your design and choices. Lastly, provide a brief explanation about how each function of the contract should be tested.
+For a comprehensive understanding of Celo smart contracts and Solidity, please refer to the Celo and Solidity tutorials.

artifacts/@openzeppelin/contracts/access/Ownable.sol/Ownable.dbg.json

@@ -0,0 +1,4 @@
+{
+  "_format": "hh-sol-dbg-1",
+  "buildInfo": "..\\..\\..\\..\\build-info\\f54596849a897a67ea2e588cc2693605.json"
+}

artifacts/@openzeppelin/contracts/access/Ownable.sol/Ownable.json

@@ -0,0 +1,85 @@
+{
+  "_format": "hh-sol-artifact-1",
+  "contractName": "Ownable",
+  "sourceName": "@openzeppelin/contracts/access/Ownable.sol",
+  "abi": [
+    {
+      "inputs": [
+        {
+          "internalType": "address",
+          "name": "owner",
+          "type": "address"
+        }
+      ],
+      "name": "OwnableInvalidOwner",
+      "type": "error"
+    },
+    {
+      "inputs": [
+        {
+          "internalType": "address",
+          "name": "account",
+          "type": "address"
+        }
+      ],
+      "name": "OwnableUnauthorizedAccount",
+      "type": "error"
+    },
+    {
+      "anonymous": false,
+      "inputs": [
+        {
+          "indexed": true,
+          "internalType": "address",
+          "name": "previousOwner",
+          "type": "address"
+        },
+        {
+          "indexed": true,
+          "internalType": "address",
+          "name": "newOwner",
+          "type": "address"
+        }
+      ],
+      "name": "OwnershipTransferred",
+      "type": "event"
+    },
+    {
+      "inputs": [],
+      "name": "owner",
+      "outputs": [
+        {
+          "internalType": "address",
+          "name": "",
+          "type": "address"
+        }
+      ],
+      "stateMutability": "view",
+      "type": "function"
+    },
+    {
+      "inputs": [],
+      "name": "renounceOwnership",
+      "outputs": [],
+      "stateMutability": "nonpayable",
+      "type": "function"
+    },
+    {
+      "inputs": [
+        {
+          "internalType": "address",
+          "name": "newOwner",
+          "type": "address"
+        }
+      ],
+      "name": "transferOwnership",
+      "outputs": [],
+      "stateMutability": "nonpayable",
+      "type": "function"
+    }
+  ],
+  "bytecode": "0x",
+  "deployedBytecode": "0x",
+  "linkReferences": {},
+  "deployedLinkReferences": {}
+}

artifacts/@openzeppelin/contracts/utils/Context.sol/Context.dbg.json

@@ -0,0 +1,4 @@
+{
+  "_format": "hh-sol-dbg-1",
+  "buildInfo": "..\\..\\..\\..\\build-info\\f54596849a897a67ea2e588cc2693605.json"
+}

artifacts/@openzeppelin/contracts/utils/Context.sol/Context.json

@@ -0,0 +1,10 @@
+{
+  "_format": "hh-sol-artifact-1",
+  "contractName": "Context",
+  "sourceName": "@openzeppelin/contracts/utils/Context.sol",
+  "abi": [],
+  "bytecode": "0x",
+  "deployedBytecode": "0x",
+  "linkReferences": {},
+  "deployedLinkReferences": {}
+}

artifacts/contracts/SupplyChainTracking.sol/SupplyChainTracking.dbg.json

@@ -0,0 +1,4 @@
+{
+  "_format": "hh-sol-dbg-1",
+  "buildInfo": "..\\..\\build-info\\f54596849a897a67ea2e588cc2693605.json"
+}