# Vedrixa Forms Product SRS

Version: 1.0
Date: 2026-03-08
Status: Draft baseline for restart
Owner: Vedrixa Forms

## 1. Purpose
This document defines the product scope, system behavior, architecture boundaries, and release requirements for Vedrixa Forms Free and Vedrixa Forms Pro.

It is intended to prevent implementation drift before Pro development starts.

## 2. Product Overview
Vedrixa Forms is a WordPress form builder focused on two primary use cases:
- Contact forms
- User registration forms

The Free plugin is the public foundation distributed through WordPress.org.
The Pro plugin is a commercial extension plugin that depends on the Free plugin and adds premium modules without duplicating Free plugin logic.

## 3. Product Goals
- Keep the Free plugin stable, lean, and suitable for WordPress.org releases.
- Build Pro as a clean extension layer using hooks, filters, and service classes.
- Focus Pro value on registration workflows, user lifecycle, account management, privacy, and automation.
- Avoid feature sprawl and avoid generic form-builder parity work unless it directly improves the registration product story.

## 4. Non-Goals
- No survey, quiz, or poll suite in Pro v1.
- No landing page builder in Pro v1.
- No AI generation features in Pro v1.
- No full membership/content restriction system in Pro v1.
- No separate form type for profile editing.
- No Pro business logic embedded directly into Free plugin screens unless the Free plugin only exposes extension seams.

## 5. Product Split
### 5.1 Free Plugin Responsibilities
The Free plugin owns:
- Plugin bootstrap and lifecycle
- Form CRUD
- Form builder UI for supported free form types
- Free field definitions and rendering engine
- Submission storage and admin viewing for free workflows
- Registration and contact frontend rendering shortcode
- Validation, email transport, and core helper services
- Global settings that belong to the Free plugin only
- Hooks and filters used by Pro extensions

### 5.2 Pro Plugin Responsibilities
The Pro plugin owns:
- Dependency check on the Free plugin
- Pro module registration and admin UI
- Premium fields and premium modules
- User account features
- Privacy and GDPR features
- Advanced submission workflows
- Integrations and automation features
- Feature unlocks driven through Free plugin hooks

## 6. Architecture Principles
1. Free remains the source of truth for the shared form engine.
2. Pro must extend; it must not fork or copy Free logic.
3. Any new Free changes required for Pro must be hook-first.
4. Free must not hardcode Pro UI, Pro settings forms, or Pro behavior.
5. Pro modules must be isolated by class/service area.
6. Backward compatibility code should not be added for features that have not launched.

## 7. Supported Form Types
### Free v1
- Contact Form
- Registration Form

### Removed from scope
- Edit Profile Form as a standalone form type

Profile editing will instead use:
- Global account settings
- A selected registration form as profile source
- Built-in fallback common profile fields if no form is selected

## 8. User Roles
### Site Administrator
- Creates and configures forms
- Enables Pro modules
- Configures account/privacy workflows
- Reviews submissions
- Manages logs and exports

### End User / Visitor
- Submits contact forms
- Registers through registration forms
- Logs in through frontend account/login tools
- Updates profile through account/profile flows
- Views and manages own submissions if allowed
- Uses privacy controls if allowed

## 9. Functional Scope
### 9.1 Free Plugin Functional Requirements
#### FR-F-01 Form Management
- Admin can create, edit, duplicate, preview, and delete forms.
- Admin can choose Contact or Registration form type.

#### FR-F-02 Builder
- Admin can build forms using drag-and-drop fields.
- Admin can configure field labels, names, validation, defaults, visibility, layout, and conditional logic for supported fields.

#### FR-F-03 Frontend Rendering
- Forms render through shortcode.
- Form assets load only when needed.

#### FR-F-04 Submission Handling
- Contact submissions are stored and viewable.
- Registration submissions may create WordPress users when configured.

#### FR-F-05 Email and Notifications
- Form-level notifications and auto responder remain available for supported Free workflows.
- Global email transport configuration remains in Free.

#### FR-F-06 Security
- Nonce validation, sanitization, capability checks, and optional reCAPTCHA support.

#### FR-F-07 Extension Layer
The Free plugin must provide extension seams for:
- Pro module registration
- Premium field registration
- Builder field settings extension
- Configure screen registration
- Global settings tab/module registration
- Submission lifecycle hooks
- User creation/update lifecycle hooks
- Frontend account/profile extension hooks

### 9.2 Pro Plugin Functional Requirements
#### FR-P-01 Pro Activation
- Pro detects whether Free is active.
- Pro deactivates or blocks itself cleanly if Free is unavailable.

#### FR-P-02 Premium Field Unlocks
- Premium fields are visible but locked in Free when Pro is inactive.
- Premium fields become usable when Pro is active.

#### FR-P-03 Custom User Meta Mapping
- For registration/profile-supported fields, admin can assign a custom user meta key where appropriate.
- Reserved core user fields cannot be remapped.

#### FR-P-04 User Accounts Module
- Frontend login shortcode
- Frontend account dashboard shortcode
- Frontend profile shortcode
- Frontend password change shortcode
- Global account page settings
- Global login/profile/account redirect settings
- Global allowed-role and logged-out handling
- Optional selected registration form as profile source
- Built-in fallback profile fields when no source form is selected

#### FR-P-05 My Submissions Module
- Frontend users can view their own submissions.
- Submission listing can be filtered/paginated.
- Submission visibility is controlled globally.
- Optional self-service delete/export subject to privacy settings.

#### FR-P-06 Privacy & GDPR Module
- Global privacy settings only, not per form.
- Allow or block self-service export.
- Allow or block self-service delete.
- Consent confirmation before privacy actions when enabled.
- Submission retention policy.
- Privacy log retention policy.
- Audit log storage for privacy actions.
- Admin privacy log viewer/export.

#### FR-P-07 Global Admin Submissions Module
- A Pro-wide submissions screen across forms.
- Filter by form, keyword, status, and date.
- Pagination and bulk actions.

#### FR-P-08 Notifications and Automation Module
- Global profile/account notification templates.
- Test-email tools for profile/account notifications.
- Future webhook and mailing integrations via separate Pro modules.

## 10. Pro Module Inventory
Pro will be structured into distinct modules.

### Module A: Premium Fields
- Advanced fields
- Social/profile fields
- Future repeater/signature/etc.

### Module B: User Accounts
- Login
- My Account dashboard
- Profile editing
- Password change
- Account access rules
- Profile data source selection

### Module C: My Submissions
- Frontend submission history
- Detail view
- Search/filter/pagination
- Optional self-service actions

### Module D: Privacy & GDPR
- Global privacy settings
- Export/delete permissions
- Consent
- Retention
- Privacy logs

### Module E: Global Admin Submissions
- Central submission management
- Cross-form filtering and bulk actions

### Module F: Notifications & Automation
- Global account/profile notifications
- Test email tools
- Later webhook/integration features

## 11. Admin IA Requirements
### Free Admin Menu
- Vedrixa Forms
- All Forms
- Global Settings

### Pro Admin Menu Additions
- All Submissions
- User Accounts
- Privacy & GDPR
- Privacy Logs
- Future modules only when implemented

Requirement:
- The first menu item must remain All Forms for Free plugin users.
- Pro menu additions must not break the Free admin experience.

## 12. Global Settings Requirements
### Free Global Settings
- General Settings
- Security
- Email Configuration
- Free account activation settings that belong to registration creation flow

### Pro Global Settings / Module Pages
#### User Accounts
- Default profile source form
- Account page
- Login page
- Profile page
- Logged-out handling
- Allowed roles
- Success messages and redirects
- Notification templates
- Submission visibility settings

#### Privacy & GDPR
- Allow export
- Allow delete
- Require consent
- Consent label
- Submission retention days
- Privacy log retention days

## 13. Shortcode Requirements
### Free
- `[wpefb_registration id="FORM_ID"]`

### Pro
- `[wpefb_login]`
- `[wpefb_account_dashboard]`
- `[wpefb_profile]`
- `[wpefb_change_password]`

Requirements:
- Pro shortcodes must work with global settings.
- Profile shortcode may accept a registration form ID override.
- If no form is assigned, profile shortcode renders fallback common fields.

## 14. Data Requirements
### Existing Data Stores
- Forms
- Form options / metadata
- Sections / fields
- Submissions
- Global options

### Pro Additional Data
- Privacy log table
- Any new Pro data tables must be documented and versioned separately.

## 15. UX Requirements
- Free builder remains uncluttered.
- Locked premium fields are visible and clearly upsell Pro.
- Pro modules must appear as named modules, not hidden inside unrelated settings.
- Account pages must behave like a coherent user area, not mixed anchors on one screen.

## 16. Security Requirements
- WordPress capability checks for all admin actions
- Nonce verification for all state-changing actions
- Sanitization on all input
- Escaping on all output
- Restrict self-service submission access to current owner only
- Privacy actions must be auditable

## 17. Performance Requirements
- Frontend assets load only when relevant shortcodes exist.
- Submission and privacy log screens must be paginated.
- Retention cleanup must be scheduled, not request-bound.

## 18. Release Constraints
- Free plugin changes should be minimized and hook-oriented.
- Pro feature work must occur primarily in the Pro repo.
- No compatibility/deprecation layer is required for features not launched publicly.

## 19. Acceptance Criteria
The restart is acceptable when:
- Free repo contains only shared engine and extension seams.
- Pro repo contains isolated premium modules.
- No standalone Edit Profile form type exists.
- Privacy settings are global and module-based.
- Account settings are global and module-based.
- Admin submissions are manageable from one Pro screen.
- SRS and implementation backlog are committed to git before feature coding resumes.

## 20. Initial Implementation Order
1. Define Free extension seams required by Pro
2. Build Pro module bootstrap and module registry
3. Build User Accounts module
4. Build My Submissions module
5. Build Privacy & GDPR module
6. Build Global Admin Submissions module
7. Build Premium field unlock and meta mapping cleanup
8. Build Notifications & Automation module