optriment / web3-employment Goto Github PK

We would like to optimize the gas consumption during batch payment processing on the blockchain by moving the relevant logic from the smart contract to our backend API. The proposed solution involves creating a new endpoint, /api/blockchain/verify_batch_payment, which will accept a POST request with the following attributes in the request body:

• groupId: The identifier of the group to which the user should have access.
• recipients: An array of objects containing the following attributes for each recipient:
  • recipient_id: The identifier of the recipient.
  • payment_amount: The positive value of the payment amount.

The primary responsibility of this endpoint will be to validate the data that will be sent from the frontend to the blockchain. The validation process should include the following steps:

1. Verify that the user making the request has access to the specified groupId.
2. Verify that each recipient belongs to the specified groupId.
3. Ensure that the payment_amount for each recipient is a positive value.

If all the validation checks pass, the endpoint should return a response with a status code of 200. In case of any validation failure, the endpoint should return a response with a status code of 422, along with an appropriate error explanation.

We need to create a new API endpoint for unarchiving companies in our system. The endpoint should be accessible at /api/companies/[id]/unarchive and should accept the POST HTTP method. The purpose of this endpoint is to set a company as active in our database.

Your task is to create the /api/companies/[id]/unarchive endpoint and implement the logic for unarchiving a company. If the company is already active, the endpoint should not do anything. The archived status of a company is stored as a timestamp in the archived_at column in the companies table.

If the company is archived (archived_at is not null), the endpoint should update the archived_at column in the companies table to the null.

The endpoint should return a HTTP 200 code, and a success message if the company is successfully unarchived, and an error message if there is an issue with the request (like company doesn't exist, for example).

Tests should be written to verify the functionality of the endpoint

We need to add a new component called CompaniesList to the companies screen, which will display all the companies with their attributes.

You will need to fetch the companies from the API endpoint that you have already created and pass them into the CompaniesList component. Your task is to implement this functionality while adhering to the same code organization as the EmployeesList component.

Steps:

1. Implement the CompaniesList component, which should be similar to the EmployeesList component, to display the attributes of each company.
2. Integrate the CompaniesList component into the companies screen.
3. Fetch companies data from the API endpoint that you have created and pass it into the CompaniesList component.
4. Ensure that the code organization for the CompaniesList component matches that of the EmployeesList component.
5. Test the CompaniesList component to ensure that it is displaying the companies and their attributes correctly.

Please take a look into employees list screen. I hope it will be helpful for you :-)

As a frontend developer, your task is to implement a feature that allows users to upload their recipients list from a CSV file on a specific group page. Users should be able to upload the CSV file from their computer using a popup dialog triggered by an "Import" button.

The following steps outline the expected behavior of the feature:

1. On the specific group page, a button labeled "Import" should be prominently displayed.
2. When a user clicks the "Import" button, a popup dialog should appear, prompting them to select a CSV file from their computer.
3. Upon submitting the file selection in the popup dialog, the frontend should send the CSV file to the backend through a specific API endpoint (POST /api/groups/:group_id/import).
4. The backend API will then parse the uploaded CSV file, validate its contents, and reject any invalid records.
5. After successful validation, the backend will insert the valid recipients into the specified group.
6. The user should receive a confirmation message indicating that the import has been successful.

Validations to be applied to the CSV file are as follows:

1. Records with empty wallet addresses should be skipped during import.
2. If the payment amount is invalid (not a number or a negative number), the frontend should insert a value of 0 for that particular recipient.
3. If a recipient's display name is empty, the frontend should use the associated wallet address in its place.
4. All values, including wallet addresses, contacts, and display names, should be cleansed of any leading or trailing whitespaces.

Good luck with the implementation! If you encounter any challenges during the development process, don't hesitate to reach out for assistance. We look forward to seeing the successful integration of this essential feature into our platform.

          I suggest to rename this function to `addBatchPayment`

Originally posted by @gruz0 in #124 (comment)

I was logged in on TrustWallet dApps using email magic link on iPhone. But was unable to sign transaction because of the following error:

          I think we can merge these two migrations into single one, just change the `total_amount` type in original migration.

Originally posted by @gruz0 in #124 (comment)

          We don't need to have `group_id` there, because batch payments relate to selected people, not a group. Instead we've to create a new table named `batch_payment_recipients` and set relation between `batch_payments_recipients.batch_payment_id` and `batch_payments.id`

Originally posted by @gruz0 in #124 (comment)

When using OKX Wallet:

When using TronLink:

We need to create a new API endpoint for archiving companies in our system. The endpoint should be accessible at /api/companies/[id] and should accept the DELETE HTTP method. The purpose of this endpoint is to set a company as archived in our database.

Your task is to create the /api/companies/[id] endpoint and implement the logic for archiving a company. If the company is already archived, the endpoint should not do anything (but return success response). The archived status of a company is stored as a timestamp in the archived_at column in the companies table.

If the company is not already archived (has a null in the column), the endpoint should update the archived_at column in the companies table to the current timestamp. If the company is already archived, the endpoint should not update the database.

The endpoint should return a HTTP 200 code, and a success message if the company is successfully archived, and an error message if there is an issue with the request (like company doesn't exist, for example).

Tests should be written to verify the functionality of the endpoint

Especially it should be added for WalletConnect on mobile devices, because we need to jump into wallet and then confirm transaction there. And right after that get back to dApps to see the result.

I had 0.0005 TRX before sending transaction and it was reverted on blockchain.

https://tronscan.org/#/transaction/48d78c4c36ced585901557e43e5c985087323480b30f04cf7cc1522ba8943800

As a frontend developer, your next task is to implement a feature that allows users to export the recipients of a specific group from the database to a CSV file. The feature should be accessible through a button labeled "Export" on the group interface.

The following steps outline the expected behavior of the export feature:

1. On the group interface, a button labeled "Export" should be visible to the user.
2. When a user clicks the "Export" button, the frontend should send a request to the backend API endpoint: /api/groups/:group_id/export.
3. The backend API should retrieve all entries from the recipients table associated with the specified group, including all fields for each recipient.
4. The backend should then generate a CSV file containing the recipient data from the database.
5. The CSV file should be sent as the output to the browser in response to the frontend request.
6. The browser should initiate the download of the CSV file, allowing the user to save it to their computer.

Additionally, ensure that the exported CSV file includes all relevant recipient information, and each field is properly formatted to adhere to CSV standards.

Test the feature thoroughly to ensure it works smoothly and handles any potential edge cases gracefully.

Currently, our application saves individual payment transactions to the database, but it doesn't do the same for batch payments.
It's crucial that we also store batch payments in the database to have complete information about all transactions.

Expected Behavior:

When a batch payment is processed, the details of the transaction should be saved in the database, similarly to how individual payments are handled.To facilitate this, a new API endpoint should be created, like POST /api/groups/:id/batch_payment

Reference Links:

For the implementation of this feature, the following existing code can be referred to:

• https://github.com/optriment/web3-employment/blob/main/src/useCases/createPayment.ts#L22
• https://github.com/optriment/web3-employment/blob/main/src/pages/api/groups/%5Bid%5D/recipients/%5Brecipient_id%5D/payment.ts

The task is to create a new API endpoint that will allow users to list all available companies from the database. The endpoint should be accessible through a GET request to /api/companies.

The endpoint should return a JSON response that includes a list of all available companies, along with their attributes. The attributes that should be included for each company are: id, display_name, comment, created_at, updated_at, and archived_at.

In addition, the API endpoint should be tested thoroughly to ensure that it works as expected. Test cases should cover scenarios such as when there are no companies in the database, and when there are companies in the database. When there are no companies in the database, the endpoint should return an empty array. When there are companies in the database, the endpoint should return an array of companies with all attributes.

By the end of the week, I expect to have successfully implemented the API endpoint and tested it thoroughly to ensure that it meets all requirements.

I used desktop version of OptriTool, picked WalletConnect and opened TrustWallet to scan QR code. Transaction was confirmed on mobile and then I've got the following message on desktop:

          We should not list recipients without wallets.

There are two possible ways how to optimize such code:

1. Implement new function on API side to return only recipients with non-empty wallet
2. Filterize them on frontend side and keep getGroupById as it is right now

WDYT?

Originally posted by @gruz0 in #110 (comment)