PotLock / bos-app

PotLock BOS (blockchain operating system - decentralized front ends) App
MIT License
8 stars 9 forks source link

[ENHANCE] Enable flagging of accounts in pot (🟠 NEEDS DESIGN) #530

Closed lachlanglen closed 5 months ago

lachlanglen commented 5 months ago

Summary

Pot owner, admins & chef need a way to flag accounts (whether donors or projects) within a pot, thereby excluding them from the payouts calculations.

Requirements:

  1. Chef/admin/owner can flag a donor or a project from a donation row in Pot > Donations view (click on Flag icon,

    • Click on Flag icon
    • Choose an option: "Flag donor" or "Flag project"
    • View modal displaying title ("Flag "), a required "Reason" input, and a note saying "Flagging this account will remove their donations when calculating payouts for this pot"
    • Click "Cancel" or "Confirm". "Confirm" will prompt a transaction. Success screen indicating account has been flagged with given note.
  2. If I flag a donor or project, I should also be able to unflag them (no need for a modal or success screen in this case, just a transaction is fine). NB: Due to social DB permissions, unflagging will have to happen from the same account that flagged in the first place. This is possible to work around but shouldn't be necessary initially.

  3. Anyone can see that a given donor or project has been flagged when viewing Pot > Donations (note that flagging is only within the context of this specific pot, so if you view the donor or project profile there should not be an indication there). Displays account that has been flagged, whether it's a donor or project, the reason, and the account that did the flagging and their role (chef, admin or owner)

  4. Payouts page lists flagged donors & projects, whether they are a donor or a project, who did the flagging (account ID + role e.g. chef, admin or owner) & reason for flagging

Motivation

[More detailed explanation of the motivation for the enhancement, including any benefits it would provide]

Description

[Detailed description of the enhancement, including how it would work and any design considerations]

Alternatives

[Discussion of any alternative solutions that were considered and why the proposed solution is preferred]

Risks

[Identification and mitigation of any potential risks associated with the enhancement]

Acceptance Criteria

[List of criteria that must be met for the enhancement to be considered accepted]

Additional Information

[Any other relevant information, such as links to related issues or pull requests]