Control New Voting Process (backend)

[jpaulet]

As Vocdoni, we want to reuse the current voting process structure stored in the Blockchain but also store some new information in the database, after passing the corresponding checks/permissions/subscription level by the backend. In the database, we should store for each process, the extra-features enabled for that specific process. The proccess could have a list of new extra-features, like:

1 - Check if the process can be created by the user:
- If the organization is in a "free" plan:
- If the organization has less tokens than the needed, the organization must buy more tokens.
- If the organization has more tokens than the needed, use the tokens to create the process.

• If the organization is in a "pro/premium" plan:
  • If the plan supports all the features, create the process.
  • If the process has more features than the plan, the organization needs to upgrade.
    2 -Design the process table in the BBDD
    3 - Store the process object in the BBDD with the news params.

Premium Features List

1. Customization and Personalization

   • personalization
   • Description: Customize the voting page with the organization's logo, colors, branding elements, and custom background images or themes. If present, the "personalization" should store the parameters selected by the user, like: "color: red", "logo: logoURL", "header: headerURL"...

2. Email Reminders

   • emailReminder
   • Description: Send automated email reminders to voters to encourage participation and remind them of voting deadlines. If "present, the emailReminder should store the parameters selected by the user, like: "remind: 1D/3D/1W".

3. SMS Notifications

   • smsNotification
   • Description: Send SMS notifications for voting reminders, updates, or important announcements.

4. Anonymous voting

   • anonymousVoting
   • Description: Enable anonymous voting in the voting page.

5. Custom Voting Instructions and Popups

   • customMessages
   • Description: Create custom voting instructions, confirmation messages, and popups to guide voters through the process. If present, the customMessages should store the parameters selected by the user, like: "votingInstructionsMsg: The custom message that the user wrote...", "confirmModalMsg: The text that will appear in the confirm modal", "afterVotingMsg: The custom message that will appear after the voting...", etc.

6. White-Label Voting Page

   • whiteLabel
   • Description: Remove any references to the voting platform's branding and present a fully white-labeled voting page.

7. Advanced Voter Authentication

   • advancedAuthentication
   • Description: Enable advanced authentication methods for voters, such as two-factor authentication (2FA) or biometric verification.

8. Custom URL for Voting Page

   • customURL
   • Description: Set a custom URL for the voting page (e.g., ago2025.vocdoni.app).
   • If present, the customURL should store the URL.

9. Post-Voting Redirect and Countdown

   • postVotingRedirect
   • Description: Set a custom redirect URL and countdown timer after a voter completes their vote. If present, the postVotingRedirect should store the redirect URL and the nº of seconds of the countdown.

10. Live Streaming

    • liveStreaming
    • Description: Display real-time streaming. If present, the liveStreaming should store the URL of the video to live stream.

11. Extended Support and Priority Service

    • extendedSupport
    • Description: Offers extended support hours and priority customer service for faster resolution of issues and queries.

12. Custom Email Templates

    • customEmailTemplates
    • Description: Create and use custom email templates for voter notifications, invitations, and reminders.

13. Support for Attachments

    • attachments
    • Description: Allow attachments (e.g., documents, PDFs) within ballots to provide additional context or information for voters. Allow to upload up to 3 links to docs.

14. Emergency Voting Pause

    • emergencyPause
    • Description: Allow admins to temporarily pause voting in emergencies or unforeseen circumstances.

15. Private Voting

    • privateVoting
    • Description: Allows to have private voting (only accessible with a password).

16. Daily updates on voting turnout

    • dailyTurnout
    • Description: Receive daily updates in your inbox with the current turnout.

17. Free text input

    • openComments
    • Description: Allow voters to add free text/comments in a text input box (private).

18. Options in Random Order

• randomOptions
• Description: Render the question options in a random order.

19. Welcome Page

• welcomePage
• Description: Adds a welcome page/landing page before the voting one.

Others: Quorum, Encrypted, etc.

And the list of features could increase in the future.

Then, in the DDBB, we must relate the process ID with the list of extra-features added, and in some cases, the frontend should be able to read those parameters to render extra information or change the look'n'feel of the voting page.

Possible solution for the BBDD:

ProcessId: 0x02323....ab
Features:

{
   "liveStreaming": "https:/youtube.com/fasoaasjoisfaj",
   "whiteLabel": "true"
   ...
}

The backend must compare each feature name with the current organization subscription and check if is enabled in the current plan, then, in the plans it will be something similar to:

{
     plan: "pro",
     organization: {
         memberships: 5,
         subOrgs: 3,
         maxProcesses: 10,
         maxSMS: 1000,
         ....
     },
     votingTypes: {
          single: true,
          multiple: true,
          approval: true,
          cumulative: false,
          ...
      },
      features: {
          personalization: true,
          emailReminder: false,
          whiteLabel: true,
          ...
     }
}

If a feature is not in the subscription list, it can't be stored in the process list and should be ignored.

[selankon]

Just FYI, actually the frontend can get an env var called "features", more or less accepts this:

{
  "faucet": true,
  "calculator": true,
  "vote": {
    "anonymous": true,
    "overwrite": true,
    "secret": true,
    "customization": true
  },
  "types": {
    "single": true,
    "multi": false,
    "approval": false,
    "participatory": false,
    "borda": false
  },
  "login": [
    "web3",
    "web2"
  ],
  "census": [
    "spreadsheet",
    "token",
    "web3"
  ],
  "unimplemented_census": [],
  "voting_type": [
    "single",
    "approval"
  ],
  "unimplemented_voting_type": [],
  "languages": [
    "en",
    "es",
    "ca"
  ]
}

This configure what the ui-scaffold have to show on the frontend. Take special attention to unimplemented_census and unimplemented_voting_type, this are those to be shown on the view with a badge Pro.

Feature object is defined here: https://github.com/vocdoni/ui-scaffold/blob/main/src/importmeta.d.ts#L1

And the keys of the unimplemented features are:

• Voting types: https://github.com/vocdoni/ui-scaffold/blob/main/src/components/ProcessCreate/Questions/useUnimplementedVotingType.ts#L8-L10
• Census https://github.com/vocdoni/ui-scaffold/blob/main/src/components/ProcessCreate/Census/UnimplementedTypeSelector.tsx#L9-L14

I suggest to adapt this code, or think if we need to develop something on this direction to show this pro features

[jpaulet]

This would be for showing/not showing by configuration in the ENV var. What we want to archive is to know if the current org plan includes the feature in the subscription plan in order to render a "PRO" (for instance) and change the behavior (allow directly to select it or upgrade the plan/pay extra tokens).