debionetwork / debio-node Goto Github PK

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

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

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

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

@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

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

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?

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

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
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