pi: Add additional proposal metadata.

[lukebp]

Summary
The following fields should be required for all proposal submissions.

• USD funding limit
• Start date
• Estimated end date
• Domain (development, marketing, documentation, etc)

This will allow for more granular filtering in politeiagui and will also allow other applications such as CMS to query this data in order to help validate contractor invoices.

Implementation

• Add the following fields to the ProposalMetadata in the pi plugin and politeiawww API:
  • Amount
  • StartDate
  • EndDate
  • Domain

type ProposalMetadata struct {
	Name      string `json:"name"`      // Proposal name
	Amount    uint64 `json:"amount"`    // Funding amount in cents
	StartDate int64  `json:"startdate"` // Start date, Unix time
	EndDate   int64  `json:"enddate"`   // Estimated end date, Unix time
	Domain    string `json:"domain"`    // Proposal domain
}

• Validate all new fields in the politeiad pi plugin on proposal submissions and edits.
• Add sane default settings for all fields to the pi plugin.
  • The defauls can be overwritten using plugin setting config options.
  • The default domains should be: development, marketing, research, and design.
  • If one or more domains is provided then none of the default domains should be used.
• Return all newly added settings in the pi plugin and politeiawww API PolicyReply.

[amass01]

will do

[amass01]

@lukebp any min/max values/validations for the amount/date fileds ?

[lukebp]

Min/max for the amount. Maybe $1000 min and $1M max.
Min/max for the dates. Start date cannot be in the past. A good default max end date might be 1 year from the current date.

[xaur]

When filling invoices in the CMS the user needs to see only proposals that can be considered "active". I'm not sure the Estimated end date field alone is enough to help with that use case. Intuitively I think whether the proposal is still "active" (its funds can be used if >0) could be a manual bool flag.

[xaur]

Domains are tricky because we have two systems (Pi and CMS) that might handle them differently:

• In CMS we have the Domain field on users and invoice line items. The visibility rules have changed recently and now the value of line item's domain controls what users can see it.
• I guess in Politeia, proposal's domain will be used for categorization and filtering on the UI.
• I don't have a good idea on how CMS should treat the domain of a proposal (managed by Pi). I think it should not impose any additional restrictions on who can bill what.
• iirc CMS has an API endpoint that provides the list of allowed domains. We might want to use that to avoid multiple copies of the domain set (and a risk of them going out of sync).

[lukebp]

When filling invoices in the CMS the user needs to see only proposals that can be considered "active". I'm not sure the Estimated end date field alone is enough to help with that use case. Intuitively I think whether the proposal is still "active" (its funds can be used if >0) could be a manual bool flag.

End date is only for information purposes to give the stakeholders and idea of the estimated completion date. What you're referring to here are the additional proposal life cycle statuses outlined in the pi proposal.

Regarding domains, the domains are a plugin setting that can be configured by the server operator. They default to the domains listed in CMS.