Open mo-jaber opened 3 days ago
CollinsC1O
commented
2 days ago I am applying to this issue via OnlyDust platform.
Hello I'm a front-end and a blockchain developer and will love to work on this issue. Please assign
martinvibes
commented
2 days ago I am applying to this issue via OnlyDust platform.
hello @ i'm an experienced frontend developer and a blockchain developer i would love to work on this issue Pleasee kindly assign :)
Oshioke-Salaki
commented
2 days ago I am applying to this issue via OnlyDust platform.
I am a frontend developer with alot of flexibility. I have worked on projects in several ecosystems. from webapplications, to contracts and to dapps. Therefore i believe that i am equipped to handle this issue and contribute to this ecosystem.
I would take a look at the requirments and follow it exactly to make sure that i complete everything and leave no stone unturned. I would first go through the codebase to understand the project and coding styles.
saimeunt
commented
2 days ago I am applying to this issue via OnlyDust platform.
I'm the maintainer of op-scan (https://github.com/walnuthq/op-scan) a blockchain explorer with a very similar tech stack so I'm familiar with the patterns and best practices used in this project. I will use my XP in Full Stack Web3 Development to implement this issue.
The user story being self explanatory, I will carefully implement it using the latest Next.js best practices, choosing the right shadcn/ui component for the job. I will probably use a Data Table to let the admin filter/sort the entire request history. I will use an API route to get the data in CSV.
Benjtalkshow
commented
2 days ago I am applying to this issue via OnlyDust platform.
I am a Full Stack Developer specializing in Next.js, TypeScript, Node.js, Cairo and Rust . With over 31 contributions across projects in the OnlyDust ecosystem, I’ve developed strong proficiency in delivering high-quality solutions and resolving complex issues within tight deadlines. My experience spans frontend, backend, smart contracts, and the optimization and maintenance of scalable codebases.
I will implement a comprehensive Request History feature that allows both users and admins to view transaction requests. Users will have restricted access to view only their own request history, while admins will be able to see all requests on the platform without any restrictions.
On the /requests page, I will provide a full history tab where users can access their transaction history. From the /dashboard page, users will see a preview of their most recent five requests for quick reference. The transaction history will include all incoming and outgoing transactions related to their activities (for users) and all activities across the platform (for admins).
Each transaction entry will display crucial information such as the date and time of the transaction, transaction ID (Txid), account (visible only to admins), transaction type (incoming or outgoing), amount of BSV tokens, and the status (pending, confirmed, or failed). Clicking on any line item will redirect users to the transaction ID on the block explorer at test.whatsonchain.com.
I will ensure that the transaction history updates in real-time to reflect the latest request activity, providing users and admins with the most current information. Also, users will have the option to export their complete transaction history as a CSV file for offline review and record-keeping, enhancing their ability to track their activities on the platform.
ShantelPeters
commented
2 days ago I am applying to this issue via OnlyDust platform.
have a solid background in full-stack web development, with experience in building user management systems and implementing role-based access controls. This experience equips me to effectively design and implement the requests history feature, ensuring that the system adheres to the specified business rules while maintaining a seamless user experience.
To implement the request history feature, I will begin by designing the user interface for both user and admin roles to ensure intuitive access to the transaction history. For users, I will restrict views to their own request history while allowing admins to view all user requests. I will set up a dedicated tab on the /requests page and incorporate a preview of the five most recent requests on the /dashboard page.
Next, I will implement backend functionality to retrieve and display transaction details, including the date and time, transaction ID, account (admin only), transaction type, amount of BSV tokens, and status. I will ensure that clicking on a transaction entry redirects users to the appropriate block explorer link.
To facilitate real-time updates, I will utilize WebSocket or similar technology to refresh the transaction history dynamically. Additionally, I will incorporate an export feature, enabling users to download their complete transaction history as a CSV file for offline record-keeping. Throughout the development process, I will prioritize security and data integrity to protect user information and transaction details.
aniruddhaaps
commented
2 days ago I am applying to this issue via OnlyDust platform.
I am a python dev . A new-comer here, willing and ready to contribute to solve the issue.
Description Allow a user and admin to see the requests history.
Business rules: user = restricted view to their own request history admin = no restrictions - show all user requests on the platform.
Transaction storage and tracking https://github.com/bitcoin-sv/bsv-faucet/issues/17 It should be a similar structure to the wallet treasury, the wallet treasury will need to be updated and also referenced in a users/transactions tbale.
Store all transactions in the database with the following details:
Date of Transaction: Record the date and time of each transaction. TXID: Store the transaction ID for unique identification. Raw Transaction (Raw TX): Save the raw transaction data. Beef Transaction (Beef TX): Include parsed transaction details for further analysis. Vout (Output Tracking) - Track outputs to determine whether they are spendable or not. Transaction Type (TX Type): Define the type of transaction (e.g., incoming, outgoing). Spent Status: - Initially set to false when a transaction is received. Mark the transaction as Spent (true) or Unspent (false). Update to true when the transaction has been used or sent to a user. Testnet Flag: - Set a flag indicating the transaction is on the testnet (true). Amount (in Satoshis): Record the transaction amount in satoshis for precision.
Acceptance Criteria: