Artwork Management

User Scenarios & Testing

User Story 1 - Upload Artwork Files (Priority: P1)

As a sponsor, I need to upload artwork files for my stand so that Nimlok can print my graphics according to the specifications.

Why this priority: This is the core workflow - without the ability to upload artwork, the entire feature is non-functional. This delivers immediate value by allowing sponsors to submit their graphics.

Independent Test: Can be fully tested by having a sponsor with a configured stand view their artwork requirements, upload files up to 1GB, and verify the files are stored and Nimlogix is notified. Delivers value by accepting artwork submissions.

Acceptance Scenarios:

Given a sponsor has a configured stand with artwork requirements, When they view their artwork list, Then they see all required artwork items with specifications
Given a sponsor is viewing an artwork requirement, When they download the specification document, Then they receive the PDF guidance from Nimlogix
Given a sponsor is uploading a 500MB PDF file, When the upload connection is interrupted mid-transfer, Then the upload resumes from where it left off
Given a sponsor successfully uploads an artwork file, When the upload completes, Then Nimlogix receives a webhook notification with the file details
Given a sponsor uploads a file larger than 1GB, When they attempt the upload, Then they see an error message stating the maximum file size

User Story 2 - Handle Artwork Approval/Rejection (Priority: P1)

As a sponsor, I need to know whether my artwork was approved or rejected so that I can correct any issues and resubmit if necessary.

Why this priority: This is essential feedback for the core workflow. Without approval/rejection handling, sponsors cannot know if their artwork is acceptable, blocking the entire process.

Independent Test: Can be tested by simulating Nimlogix webhook responses (approved/rejected) and verifying sponsors receive appropriate notifications and can take corrective action. Delivers value by closing the feedback loop.

Acceptance Scenarios:

Given a sponsor has uploaded artwork, When Nimlogix approves the artwork via webhook, Then the sponsor sees the artwork status as "Approved"
Given a sponsor has uploaded artwork, When Nimlogix rejects the artwork via webhook with a reason, Then the sponsor receives both an in-app notification and an email with the rejection reason
Given a sponsor's artwork was rejected, When they view the rejected artwork, Then they can see the rejection reason and upload a corrected version
Given a sponsor uploads a corrected version after rejection, When the new file is uploaded, Then the previous version is retained in history and Nimlogix is notified of the new submission

User Story 3 - Approve Artwork Proofs (Priority: P1)

As a sponsor or organiser, I need to review and approve final artwork proofs so that Nimlok can proceed with printing my graphics.

Why this priority: This is the final step before printing and is essential for the complete workflow. Without proof approval, the artwork cannot move to production.

Independent Test: Can be tested by having Nimlogix upload proof documents and verifying sponsors/organisers can view, approve, or reject them with reasons. Delivers value by enabling final sign-off.

Acceptance Scenarios:

Given Nimlogix uploads a proof document, When the sponsor views their artwork, Then they see the proof is available for review
Given a sponsor is reviewing a proof, When they approve it, Then Nimlogix receives a webhook notification of the approval
Given a sponsor is reviewing a proof, When they reject it, Then they must enter a rejection reason before submitting
Given an organiser has proof approval enabled for an event with sponsor-first sequence, When a sponsor approves a proof, Then the organiser receives a notification to review and approve
Given an organiser has proof approval enabled with organiser-first sequence, When Nimlogix uploads a proof, Then the organiser must approve before sponsor can review
Given an organiser has proof approval enabled with parallel sequence, When Nimlogix uploads a proof, Then both sponsor and organiser can approve in any order
Given both sponsor and organiser must approve, When both parties have approved the proof according to the configured sequence, Then Nimlogix receives the final approval notification

User Story 4 - Track Artwork Progress (Priority: P2)

As a sponsor or organiser, I need to see the status of all artwork items so that I can track progress and identify any blockers.

Why this priority: This provides visibility and helps users manage their workflow, but the system can function without it. It enhances user experience rather than enabling core functionality.

Independent Test: Can be tested by viewing artwork lists with various statuses (pending upload, submitted, rejected, approved, proof pending, proof approved) and verifying status displays are accurate.

Acceptance Scenarios:

Given a sponsor has multiple artwork items, When they view their artwork dashboard, Then they see the status of each item (not uploaded, submitted, rejected, approved, proof pending, proof approved)
Given an organiser is viewing an event, When they view the artwork overview, Then they see a summary of all sponsors' artwork progress
Given artwork has been rejected, When a user views the artwork history, Then they can see all previous submissions and rejection reasons

Edge Cases

What happens when a sponsor uploads a file in an unsupported format (not PDF)?
How does the system handle Nimlogix webhook failures or timeouts?
What happens if a sponsor tries to upload artwork before their stand configuration is complete?
How does the system handle simultaneous proof approvals by sponsor and organiser?
What happens when a sponsor uploads a new artwork version while the previous version is still being reviewed by Nimlogix?
How does the system handle file uploads that are interrupted multiple times?
What happens if organiser approval is disabled after a proof is already pending organiser review?
What happens when Nimlogix uploads a proof for artwork that was subsequently rejected?

Requirements

Functional Requirements

FR-001: System MUST allow Nimlogix to create artwork requirements via API after stand configuration
FR-002: System MUST store and display artwork specification documents (typically PDF) for each required artwork item
FR-003: System MUST support file uploads up to 1GB for artwork files
FR-004: System MUST use chunked upload mechanism to handle connection interruptions gracefully
FR-005: System MUST support PDF format only for artwork uploads
FR-006: System MUST send webhook notification to Nimlogix when artwork is uploaded
FR-007: System MUST receive webhook from Nimlogix containing approval or rejection status with reason
FR-008: System MUST notify sponsors when their artwork is rejected with the rejection reason via both in-app notification and email
FR-009: System MUST allow sponsors to upload corrected artwork files after rejection
FR-010: System MUST retain version history of all uploaded artwork files for the event lifecycle plus 3 years post-event
FR-011: System MUST allow Nimlogix to upload proof documents via API
FR-012: System MUST display proof documents to sponsors for review
FR-013: System MUST allow sponsors to approve or reject proofs
FR-014: System MUST require sponsors to provide a reason when rejecting a proof
FR-015: System MUST send webhook notification to Nimlogix when proof is approved
FR-016: System MUST support optional organiser approval of proofs based on event configuration, including configurable approval sequence (sponsor-first, organiser-first, or parallel)
FR-017: System MUST display artwork specification documents to sponsors before upload
FR-018: System MUST track status of each artwork item through the workflow (not uploaded, submitted, under review, rejected, approved, proof pending, proof approved)
FR-019: System MUST prevent artwork upload if stand configuration is incomplete
FR-020: System MUST validate file size before accepting uploads
FR-021: System MUST validate file format and reject non-PDF uploads with clear error message
FR-022: System MUST handle Nimlogix webhook failures with automatic retry logic (3 attempts with exponential backoff over 30 minutes) and send email notification to administrators on final failure
FR-023: System MUST automatically archive or purge artwork version history 3 years after event completion date

Key Entities

Artwork Requirement: Represents a single artwork item needed for a stand, created by Nimlogix via API. Contains artwork specifications (typically PDF), status, and metadata
Artwork Submission: Represents an uploaded artwork file from a sponsor. Contains file reference, upload timestamp, version number, and approval status. Related to an Artwork Requirement
Artwork Specification Document: PDF or document provided by Nimlogix that guides sponsors on artwork requirements. Associated with an Artwork Requirement
Artwork Proof: Final proof document uploaded by Nimlogix for sponsor and optional organiser approval. Contains file reference, approval status by sponsor, approval status by organiser (if required)
Artwork Version History: Historical record of all submissions for an Artwork Requirement, including rejected versions with rejection reasons

Success Criteria

Measurable Outcomes

SC-001: Sponsors can successfully upload files up to 1GB without connection failures
SC-002: Artwork upload process resumes automatically after connection interruption without data loss
SC-003: Nimlogix receives webhook notifications within 5 seconds of artwork upload or proof approval
SC-004: Sponsors receive rejection notifications (both in-app and email) within 1 minute of Nimlogix webhook callback
SC-005: 95% of sponsors can complete the artwork upload process without requiring support assistance
SC-006: Sponsors can view complete history of all artwork submissions and status changes
SC-007: Proof approval workflow (when organiser approval required) completes within defined business timeline
SC-008: System handles concurrent uploads and approvals without data corruption or race conditions

Assumptions

Chunked upload mechanism will use industry-standard approaches (e.g., multipart uploads with resume capability)
Nimlogix API provides reliable webhook endpoints with reasonable timeout thresholds (assumed 30 seconds)
Proof documents are typically PDF format
Sponsors must convert all artwork to PDF format before upload (simplifies validation and processing)
Artwork specification documents are static once created by Nimlogix
Stand configuration must be in "approved" or "complete" status before artwork requirements are generated
Webhook authentication will use standard approaches (e.g., HMAC signatures, API keys)
File storage will use secure, scalable object storage (consistent with existing infrastructure)
Maximum of 20 artwork items per stand (based on typical exhibition requirements)
Nimlogix webhooks will be idempotent (can be safely retried)
Organiser approval requirement and approval sequence (sponsor-first, organiser-first, or parallel) are both configured at event level, not per artwork item
Webhook retry mechanism uses exponential backoff (e.g., retry after 1 min, 5 min, 15 min)
Administrator email notifications are sent via existing notification system
Artwork version history retained for 3 years post-event for business records compliance

Dependencies

Stand configuration feature must be complete (006-stand-configuration)
Nimlogix API integration for creating artwork requirements
Nimlogix webhook endpoints for artwork upload and proof approval notifications
Nimlogix webhook callbacks for approval/rejection responses
File storage infrastructure for large file handling
User notification system for rejection alerts
Email notification system for administrator alerts on webhook failures
Event management configuration for organiser approval settings (enabled/disabled, approval sequence preference)

Constraints

Maximum file size: 1GB per artwork file
Upload mechanism must be resilient to network interruptions
Webhook delivery must be reliable with appropriate retry mechanisms
File storage must be secure and access-controlled
Version history must be maintained for audit purposes (retained for event lifecycle + 3 years)
System must handle concurrent proof approvals by multiple parties
Proof rejection reasons must be captured and stored