81 lines
5.5 KiB
Markdown
81 lines
5.5 KiB
Markdown
# Requirements Document
|
|
|
|
## Introduction
|
|
|
|
This feature will complete the Shopify Price Updater TUI by implementing the three missing screens: Scheduling, View Logs, and Tag Analysis. Currently, these screens show "coming soon" placeholders, but users need functional interfaces to schedule operations, view historical logs, and analyze product tags before running operations.
|
|
|
|
## Requirements
|
|
|
|
### Requirement 1: Scheduling Screen
|
|
|
|
**User Story:** As a store owner, I want to schedule price update operations to run automatically at specific times, so that I can manage promotional pricing without manual intervention.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN the user navigates to the Scheduling screen THEN the system SHALL display a list of scheduled operations
|
|
2. WHEN the user selects "Add New Schedule" THEN the system SHALL provide a form to create a new scheduled operation
|
|
3. WHEN creating a schedule THEN the system SHALL allow selection of operation type (update/rollback)
|
|
4. WHEN creating a schedule THEN the system SHALL allow setting of date and time for execution
|
|
5. WHEN creating a schedule THEN the system SHALL allow selection of recurrence pattern (once, daily, weekly, monthly)
|
|
6. WHEN the user saves a schedule THEN the system SHALL persist it to a schedules.json file
|
|
7. WHEN viewing schedules THEN the system SHALL show status (pending, completed, failed) for each scheduled operation
|
|
8. WHEN the user selects a schedule THEN the system SHALL allow editing or deleting the schedule
|
|
9. IF a schedule is set to run THEN the system SHALL provide instructions on how to enable automatic execution
|
|
|
|
### Requirement 2: View Logs Screen
|
|
|
|
**User Story:** As a store owner, I want to view historical operation logs in the TUI, so that I can review past price updates and troubleshoot issues without leaving the interface.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN the user navigates to the View Logs screen THEN the system SHALL display a list of available log files
|
|
2. WHEN the user selects a log file THEN the system SHALL display the log contents with syntax highlighting
|
|
3. WHEN viewing logs THEN the system SHALL provide filtering options (date range, operation type, status)
|
|
4. WHEN viewing logs THEN the system SHALL show pagination for large log files
|
|
5. WHEN viewing logs THEN the system SHALL highlight important information (errors, warnings, success messages)
|
|
6. WHEN the user presses a key THEN the system SHALL allow scrolling through log content
|
|
7. WHEN no logs exist THEN the system SHALL display a helpful message explaining how logs are created
|
|
8. WHEN viewing logs THEN the system SHALL show log metadata (file size, creation date, operation count)
|
|
|
|
### Requirement 3: Tag Analysis Screen
|
|
|
|
**User Story:** As a store owner, I want to analyze product tags in my store through the TUI, so that I can understand my product organization and make informed decisions about which tags to target for price updates.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN the user navigates to the Tag Analysis screen THEN the system SHALL fetch and display all product tags from the store
|
|
2. WHEN displaying tags THEN the system SHALL show the count of products for each tag
|
|
3. WHEN displaying tags THEN the system SHALL show the count of variants for each tag
|
|
4. WHEN displaying tags THEN the system SHALL calculate and show total value of products for each tag
|
|
5. WHEN the user selects a tag THEN the system SHALL display detailed information about products with that tag
|
|
6. WHEN viewing tag details THEN the system SHALL show product names, prices, and variant counts
|
|
7. WHEN analyzing tags THEN the system SHALL provide search/filter functionality to find specific tags
|
|
8. WHEN the analysis is complete THEN the system SHALL allow the user to select a tag for immediate use in configuration
|
|
9. IF the API connection fails THEN the system SHALL display appropriate error messages with troubleshooting guidance
|
|
|
|
### Requirement 4: Navigation and User Experience
|
|
|
|
**User Story:** As a user, I want consistent navigation and user experience across all TUI screens, so that I can efficiently use all features without confusion.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN the user is on any new screen THEN the system SHALL provide consistent keyboard navigation (↑/↓ arrows, Enter, Esc)
|
|
2. WHEN the user presses Esc THEN the system SHALL return to the main menu from any screen
|
|
3. WHEN displaying data THEN the system SHALL use consistent styling and colors across all screens
|
|
4. WHEN operations are in progress THEN the system SHALL show consistent loading indicators and progress bars
|
|
5. WHEN errors occur THEN the system SHALL display consistent error messages with helpful guidance
|
|
6. WHEN the user navigates between screens THEN the system SHALL maintain state appropriately (remember selections, preserve data)
|
|
|
|
### Requirement 5: Data Persistence and Integration
|
|
|
|
**User Story:** As a user, I want the new TUI screens to integrate seamlessly with existing functionality, so that all features work together cohesively.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN schedules are created THEN the system SHALL store them in a JSON file in the project directory
|
|
2. WHEN viewing logs THEN the system SHALL read from the same Progress.md file used by CLI operations
|
|
3. WHEN analyzing tags THEN the system SHALL use the same Shopify API services as other operations
|
|
4. WHEN configuration changes are made THEN the system SHALL reflect those changes in all relevant screens
|
|
5. WHEN the user selects a tag from analysis THEN the system SHALL allow updating the configuration with that tag
|
|
6. WHEN schedules are executed THEN the system SHALL log results to the same logging system used by manual operations
|