debionetwork / debio-node Goto Github PK

Create Specimen Tracking Pallet

• Create specimen on create order
• Receive Specimen
• Reject Specimen
• Process Specimen
• Fulfill Order iff Specimen Processed
• Refund to customer on Specimen rejected

Description
refund_order extrinsic is calling the wrong function in its implementation.

Steps to Reproduce
make a refund_order extrinsic using polkadot.js/apps

Expected vs. Actual Behavior
Expected:
It should update the Order.status to OrderStatus::Refunded.
Event::OrderRefunded should be emitted

Actual:
It calls fulfill_order function.
error.UnauthorizedOrderFulfillment is emitted

Motivation
There seems to be confusion about the naming of OrderStatus::Success.
Currently it means that the Order has been successfully processed and the DnaSample result has been submitted.
Some people seem to think OrderStatus::Success to mean that the Order has been successfully created.

Suggested Solution
Change OrderStatus::Success to OrderStatus::Fulfilled

wdyt?
@SHA888 @agustinustheo

Currently, Order type is connected to a concrete Service (which is currently a genetic testing service) type.
To accomodate for different product/services types, an Order should be connected to a generic OrderItem type instead.
The generic OrderItem type can then be implemented as e.g GeneticService, MedicalTest, etc

Motivation
The flow of order processing is such that when a dna sample is rejected, then Event::OrderFailed will be emitted.
Currently the Order.status is not yet updated to OrderStatus::Failed, but the plan is to do that.

Then the escrow will do the refund in the ethereum network.
In this case, the refund_order extrinsic have to be called separately by escrow backend to update Order.status to OrderStatus::Refunded.

Now, the Order.status will change from OrderStatus::Failed to OrderStatus::Refunded.

Since all failed orders will be refunded, maybe we only need one of the 2 statuses.

Suggested Solution
Remove the refund_order extrinsic. update the Order.status to OrderStatus::Failed on DnaSampleRejected event.
Also, because the payment is done in the ethereum network and escrow backend (in the future might be a smart contract), maybe there is no need to mark the Order.status to OrderStatus::Refunded, rather Order.status = OrderStatus::Failed is sufficient

Alternatives
Just an idea..
Keep the refund_order extrinsic and OrderStatus::Refunded enum.
Have 2 status fields on Order struct. Order.fulfillment_status and Order.payment_status.
Order.fulfillment_status -> Failed / Fulfilled / OnProgress
Order.payment_status -> Unpaid / Paid / Refunded

• Set admin key in genesis config
• Use T::Hashing::hash function to generate order_id instead of RandomnessSource
• Define and implement Orders pallet interface

Description

When I tried to run cargo check -p node-template-runtime or cargo check -p debio-node it throws an error:

failed to select a version for `certifications`.
    ... required by package `node-template-runtime v3.0.0 (/home/user/debio/debio-node/runtime)`
    ... which is depended on by `debio-node v0.1.0 (/home/user/debio/debio-node/node)`
versions that meet the requirements `=0.1.0` are: 0.1.0

the package `node-template-runtime` depends on `certifications`, with features: `sp-io` but `certifications` does not have these features.


failed to select a version for `certifications` which could resolve this conflict

Steps to Reproduce

1. Go to root folder
2. Run ``cargo check -p node-template-runtimeorcargo check -p debio-node```

Expected vs. Actual Behavior
Expected: check passes
Actual: Failed

Environment

• Operating system: Linux Ubuntu 20.04

• Template version/tag:

• Rust version :
  Default host: x86_64-unknown-linux-gnu
  rustup home: /home/sha888/.rustup

  installed toolchains

  stable-x86_64-unknown-linux-gnu (default)
  nightly-x86_64-unknown-linux-gnu

  active toolchain

  stable-x86_64-unknown-linux-gnu (default)
  rustc 1.53.0 (53cb7b09b 2021-06-17)

@kevinjanada @agustinustheo Any idea what might I went wrong? Thanks

@kevinjanada What is the difference between sp_version::RuntimeVersion and sp_vesion::NativeVersion implementation? When I refactor #[cfg(feature = "std"] and run Cargo Check, it says they are referring to the same thing

https://github.com/Degenics/debio-node/blob/ae72aaeec41937608249a8c3d5f2bda399a26a68/runtime/src/lib.rs#L22

Regarding this doc https://substrate.dev/rustdocs/v3.0.0/sp_version/struct.NativeVersion.html
this statement
https://github.com/Degenics/debio-node/blob/ae72aaeec41937608249a8c3d5f2bda399a26a68/runtime/src/lib.rs#L137
should be like
pub struct NativeVersion { pub runtime_version: RuntimeVersion, --- }
Am I understand it correctly or I missed something here?
Thank you for the clarification

• Update the following pallets to work with substrate v3:
  • Labs
  • Services
  • Orders
  • Escrow
  • Specimen

Question

Please include information such as the following: is your question to clarify an existing resource
or are you asking about something new? what are you trying to accomplish? where have you looked for
answers?