request_funds Function for Improved Efficiency and Maintainability

[Yunusabdul38]

Pull Request: Enhance request_funds Function for Improved Efficiency and Maintainability

Issue: #48

Description:

This pull request enhances the request_funds function by consolidating validation logic and streamlining storage updates, leading to improved gas efficiency and overall maintainability of the contract. This update reduces redundant checks and ensures consistent storage operations during fund request creation.

Key Changes:

• Consolidated Validation: Integrated the following validations directly into the request_funds function, removing external calls to check_owner, check_milestone, and funds_released:
  • Verify that the provided project_id exists in the projects storage. Throws ERROR_INVALID_PROJECT_ID if not.
  • Confirm the requester is the project's owner. Throws ERROR_UNAUTHORIZED_REQUESTER if not.
  • Validate that the milestone_id corresponds to a valid milestone for the project. Throws ERROR_INVALID_MILESTONE if invalid.
  • Ensure the milestone has been completed. Throws ERROR_MILESTONE_NOT_COMPLETED otherwise.
  • Check that funds for the milestone have not already been released. Throws ERROR_FUNDS_ALREADY_RELEASED if they have.
• Streamlined Storage Updates: Implemented the following storage updates within the request_funds function:
  • Generated a unique request_id by incrementing _fund_request_counter.
  • Created a new FundRequest struct populated with project_id, milestone_id, amount (derived from the milestone's milestone_amount and safely converted to u128), requester, and Status set to Pending.
  • Updated the following storage mappings consistently:
    • Added the new FundRequest to fund_requests (Map<(u64, u64), FundRequest>).
    • Updated fund_requests_count for the project with the latest request ID.
    • Stored request details in fund_request (Map<u64, (u64, u64, ContractAddress)>).
    • Marked the milestone as requested in milestone_funds_released (LegacyMap<(u64, u64), bool>), setting it to true.
  • Incremented the _fund_request_counter correctly after processing the request.
  • Emitted a FundsRequested event containing the project_id, request_id, and milestone_id.
• Code Cleanup:
  • Removed the now-redundant calls to check_owner, check_milestone, and funds_released.
  • Evaluated and confirmed that these functions can be safely deprecated, as their usage is now limited and consolidated.
  • Updated relevant documentation to reflect the consolidated validation logic and storage update process.

Key Improvements:

• Gas Efficiency: By consolidating validations, the number of external calls is reduced, leading to lower gas consumption.
• Maintainability: Centralizing the logic within the request_funds function simplifies code maintenance and reduces the risk of inconsistencies.
• Clarity: The code is now more readable and easier to understand, as all related operations are grouped together.
• Consistency: Ensures consistent handling of fund requests across the contract.

Acceptance Criteria:

• All validations are performed directly inside the request_funds function:
  • Invalid project_id triggers ERROR_INVALID_PROJECT_ID.
  • Unauthorized requester triggers ERROR_UNAUTHORIZED_REQUESTER.
  • Invalid milestone triggers ERROR_INVALID_MILESTONE.
  • Non-completed milestone triggers ERROR_MILESTONE_NOT_COMPLETED.
  • Duplicate funds release triggers ERROR_FUNDS_ALREADY_RELEASED.
• Successful execution creates a unique FundRequest and updates:
  • fund_requests with the new entry.
  • fund_requests_count for the given project.
  • fund_request mapping with the request details.
  • _fund_request_counter is incremented.
  • milestone_funds_released is marked true.
  • The FundsRequested event is emitted with correct details.
• Robust Testing:
  • Comprehensive unit tests have been implemented to cover:
    • Successful creation of a fund request.
    • Edge cases for invalid inputs and unauthorized calls.
    • Consistency across all storage mappings.

Technical Considerations:

• Ensured that conversion for milestone_amount to u128 is performed safely.
• Aligned validation logic with that of create_fund_request to prevent duplicate logic and ensure consistency across the contract.