Constructs and prepares an instance of this scheduler.
The arguments passed to the command. Typically, this holds required parameters of commands.
Memory store for the fees asset configuration object. This
object defines which assets are discoverable on dHealth Network
and used to pay for transaction fees.
This asset configuration is referred to as the base asset
used in a specific dApp. The reason for this is that transactions
on the underlying dHealth Network are always paid with one and the
same asset.
Memory store for the booster asset configuration object. This
object defines which assets are discoverable on dHealth Network
and used to tokenize a particular booster operation.
This asset configuration is referred to as a booster asset
used in a specific dApp.
The internal dApp configuration object. This object is used to configure key functionalities such as the name of a dApp and the enabled scopes of the backend runtime.
Contains the dApp Identifier as attached to contracts on-chain.
Typically, the dApp identifier is created using a slug-format of
the dappName
configuration inside config/dapp.ts
.
Memory store for the earn asset configuration object. This
object defines which assets are discoverable on dHealth Network
and used to tokenize a particular operation.
This asset configuration is referred to as the earn asset
used in a specific dApp. The reason for this is that individual
dApps may want their end-users to earn a custom asset, or not.
The internal dApp network configuration object. This object is used to configure the access to the underlying blockchain network.
The command scope. This is the scope that must be enabled
through the configuration files for this command to be
available.
This property is required through the extension of
BaseCommand.
Requires state information of the module. This object is typically populated upon first execution and updated any time later.
Memory store for the total number of prepared payouts. This is used in getStateData to update the latest execution state.
This method must return a database collection which
is used to discover subjects for this preparation.
e.g. "accounts"
Abstract method forwarded from PayoutCommand. This field is used to improve logging and discovery of schedulers execution.
Memory story for the minimum count of referrals that were
confirmed for a user.
The referral progress bars fills 5 steps for each level. There
is a maximum of 3 levels.
This method determines whether the payoutState
and activityAssets
fields must be set on the payout subject document, or not.
This method must return a command signature that
contains hints on the command name and its required
and optional arguments.
e.g. "command
This property is required through the extension of
PayoutCommand.
Getter for the discovery state identifier, e.g.
"discovery.accounts", "discovery.transactions",
"payout.outputs" etc.
This method is an implementation necessary because
of the extensions of StatefulModule.
This method uses the logger to print debug messages.
This method uses the logger to print error messages.
Optionally, a stack
can be passed to print a stack trace.
This method implements the processor logic for this command
that will prepare relevant subjects' payout entities. Subjects
in this command are defined by the PreparePayouts.collection
implementation.
This method returns an array of accounts that satisfy the following conditions:
createdAt
in ascending
direction. A maximum number of 10
accounts are returned.This method must return an asset amount which will be attached to a transfer transaction.
The payout subject (activity) of which activityData
is used.
The amount multiplier (in case of "boosters"). Defaults to 1
.
An amount that is computed and depends on the intensity of an activity.
This method must return an asset identifier which will be used in a transfer transaction.
This method must return a multiplier that is applied to payout amounts. This is used internally to add boosters when users have referred a specific number of accounts.
Booster payouts always return an amount (and multiplier) of 1
.
Creates a state query for this discovery service. Each discovery service shall set its own stateIdentifier which is considered the identifier of the discovery module's state document.
This method uses the logger to print info messages.
This method is the entry point of any command line
executed command. nest-commander
implements a flow
where this method is called with parameters that are
respectively the raw arguments and the parsed arguments
to this command call.
This method uses the stateService to fetch the
current execution and also uses it to update the state.
Note that the runWithOptions method is called inside
a try-catch block to force the error handling process.
This method is the entry point of this scheduler. It must be
implemented in child classes and must be decorated with a Cron
Cron
decorator.
Child classes are responsible for the registration of schedulers
and therefor the Cron()
decorator is not used in this abstract
method definition, instead you should use the Cron()
decorator
in the method implementation of child classes.
This method implements the execution logic for
processor commands that extend this class. Child
classes must implement a process method
that is called in here.
Note that this method is called by BaseCommand
under the hood, which permits to execute and track
failures more consistently at a higher level.
The parsed runtime arguments passed to the command.
This method must update a payout subject document. Note that subjects are the subject of a payout execution.
The document being updated.
The columns and their respective value.
The updated document.
This method prints usage information to the command line
and is used by nest-commander
to print a correctly formatted
help message.
Note that usage methods can be overwritten but must always
print a standard command line signature.
This method verifies whether an account, as designated
by its address, is allowed to receive the paid out token
or not.
This method verifies the entries in the assets
collection
to determine whether a user has been previously assigned a
token or not.
The recipient account.
Generated using TypeDoc
PAYOUT
The implementation for the payout preparation scheduler. Contains source code for the execution logic of a command with name:
processor:PrepareBoosterPayouts
.Notably, this command fetches accounts that have not been the subject of payouts yet and then creates transactions and signs transactions.
v0.4.0