diff --git a/files.zip b/files.zip deleted file mode 100644 index 6eee0a8..0000000 Binary files a/files.zip and /dev/null differ diff --git a/main-app.txt b/main-app.txt new file mode 100644 index 0000000..1264277 --- /dev/null +++ b/main-app.txt @@ -0,0 +1,68 @@ +**Full Development Prompt for Nature in Pots** + +**Context:** +You are ChatGPT, assisting with the continued development of the "Nature in Pots" Flask web application. The app uses MySQL, Neo4j, SQLAlchemy, Flask-Migrate, and a plugin structure. You will be provided a ZIP file containing the entire codebase. Your task is to: + +1. **Review Every File in the ZIP** + + * **Scan every single line and file** without exceptions or omissions. + * Only use code present in the ZIP as source of truth. Do **not** assume or generate context beyond what the files contain. + * Persistently store the reviewed code in memory for reference in all subsequent responses. + +2. **Incorporate All Historical Changes & Conversations** + + * The code you see may already include modifications from earlier prompts (media plugin, submissions plugin, vendor affiliation, image voting, vendor claims, etc.). When generating any new code, **explicitly reference existing code** structures, naming conventions, imports, and file placements from the ZIP. + * Integrate **all features and rules** we have specified so far, including but not limited to: + + * **Authentication & Core Models**: `User`, `Role`, `user_roles` many-to-many, `has_role()`, hashed passwords, Flask-Login user\_loader, CSRF on auth forms. + * **Media Plugin**: `Media`, `ImageHeart` model (likes/dislikes), `FeaturedImage`, image filename randomization, EXIF stripping, storage under `/static/uploads`, AJAX endpoints for voting, batch job every 12 hours to select top-voted image per species, exclude logos/avatars from voting, `net_votes` column on `Media`. + * **Submissions Plugin**: Submission types (`market_price`, `name_correction`, `new_plant`, `mutation`, `vendor_rating`, `vendor_alias`), `Submission.plant_id`, vendor fields (`vendor_id`, `old_vendor_id`, `new_vendor_id`), form logic for conditional fields, CSRF, redirect `/submission/` to `/submission/new`, list and view routes filtered by user role, image uploads, preventing self-ratings, ex-affiliate flags, vendor alias community voting with `VendorAliasVote` model, thresholds, vendor appeals via `VendorAliasAppeal`, admin override, redirect behaviors. + * **Vendor Profiles & Affiliations**: `VendorProfile` (`owner_id`, `business_name`, `description`, `logo_url`, `is_active`, `unclaimed` logic), `VendorMember` (`joined_at`, `left_at`, `left_reason`), `VendorAffiliationRequest` (user-initiated or owner-initiated), owner or admin can approve/reject, owner can forcibly remove members, store affiliation history, prevent self-voting by active members, allow ex-affiliate rating flagged, claims: `VendorClaimRequest` to claim unclaimed vendors, admin review, set `is_active=True`, assign `owner_id`. + * **Grow-Log Plugin**: `PlantUpdate` and `UpdateImage` models, BigInteger IDs, `is_public` flag, share-by-key mechanism, personal vs. vendor context (`vendor_id` on `PlantUpdate`), image uploads use shared `Media` table, only public images eligible for voting, owners choose a personal featured image per plant instance. + * **Ownership & Transfers Plugin**: `TransferRequest`, `PlantOwnershipLog` extended with `date_released` and `transfer_note`, `Plant` has `owner_id` (user or vendor) and `vendor_id` (nullable), standard transfer flows (owner-to-owner), purchase-proof transfers (invoice upload, admin/moderator approval), migrations, CSRF, role checks. + * **Search Plugin**: AJAX autocomplete on common/scientific names, search results page, navbar integration with JS snippet, templates. + * **Trait & Health Events Plugin**: `Trait` and `HealthEvent` models, image attachments, admin approval queue, display under "Health & Traits" tab, optional standardized `PestType` and `CareType` lookup tables. + * **Vendor Dashboard & Inventory**: `VendorProfile` and `VendorMember`, unclaimed vs. active vendors, claim workflow, owner and member management, plant inventory management (assign `plant.vendor_id` or personal), multiple vendor profiles per user, pending transfer requests within vendor context. + * **Admin Dashboard**: Queues for all pending items (Submissions, Traits, HealthEvents, TransferRequests, VendorClaimRequests, VendorAffiliationRequests, VendorAliasAppeals), user management (role assignment, cannot demote super admin), ability to override community featured images (`Plant.override_featured_media_id`), CSV exports, ERD viewer. + * **Marketplace & Analytics**: `Listing` and `PriceHistory` models, listing CRUD, price-trend charts (Recharts), analytics metrics (top-selling plants, vendor performance, marketplace price distributions). + * **PWA & Offline Support**: `manifest.json`, `service-worker.js`, caching strategies, responsive design, offline GrowLog drafts. + +3. **Include All Recent Changes & Rules** + + * Vendors cannot vote on images "as a vendor"; votes are always tied to the user account. + * Community may add unclaimed vendors when adding a plant or purchase-based submission; vendors later claim their profile via `VendorClaimRequest`. + * Prevent a user from rating a vendor they currently own or belong to (active `VendorMember`). Ex-affiliate ratings are allowed but flagged. + * Vendor alias submissions: approval paths are vendor self (if active member of both), admin, or community voting (threshold); vendors can appeal alias, admin or community may reject based on votes. + * Image voting logic: likes/dislikes stored in `ImageHeart`; toggling vote nullifies prior vote; update `Media.net_votes`; exclude logos and avatars. + * Batch job every 12 hrs updates `Plant.featured_media_id` based on highest `net_votes` among `media.is_public=True`. + * Vendor affiliations: multiple users per vendor; track `joined_at`, `left_at`, `left_reason`; affiliation requests and approvals; owner can remove members unilaterally. + * Plant-addition form: prepopulate vendors dropdown; if user chooses "Add New Vendor", show inline minimal vendor fields (name, URL); create unclaimed vendor in background. + * Purchase-proof transfers: user requests a transfer by submitting invoice; vendor or moderator/admin approves; then proceed with standard transfer logs. + +4. **When Generating New Code or Modifications** + + * Always reference existing file paths, blueprints, model names, import statements, migrations, templates, and static assets from the ZIP. E.g., if adding a new model, follow the existing pattern in `plugins//models.py`. + * For every new or updated file, provide the full file contents including imports, class definitions, blueprint registration, and template code as necessary—**never partial snippets**. + * If migrations are needed, supply a complete Alembic revision file with `upgrade()`/`downgrade()` including all column/table changes; name the revision descriptively (e.g., `phase3_growlog_models_added`). + * When modifying templates, show the full Jinja2 file, include `{% csrf_token() %}` in forms, ensure blocks match `base.html` inheritance. + * For static content (CSS/JS), reference existing asset locations; if adding new JS for AJAX voting or dynamic form field toggling, place it under the same `static/js/` directory and update `base.html` or relevant templates to include the script. + +5. **Testing & Verification** + + * After each phase’s changes, describe how to manually test: e.g., "Log in as a user with Vendor role, navigate to /vendor/dashboard, click 'Add Plant', verify vendor dropdown and inline vendor creation, submit Plant, check DB record, attempt image vote, etc.". + * Provide instructions for verifying image storage: ensure uploaded files appear under `static/uploads///
/`, are persisted by Docker volume, and accessible via `/media/files/`. + * Show how to test purchase-proof transfer: as a member, buy from an existing vendor, upload invoice, check that a `TransferRequest` is created; log in as vendor owner, approve, confirm `Plant.owner_id` changes. + * Demonstrate vendor-affiliation flows: a normal user requests to join vendor, vendor owner approves, record `VendorMember` created; if removed, `left_at` set and voting blocked. + +6. **Final Instructions** + + * **Only modify code under** `app/` and `plugins/` directories—do not create files elsewhere. + * Keep plugin discovery and blueprint registration intact (e.g., ensure each plugin has `plugin.json` with correct metadata). Do not remove any existing plugin scaffolding files. + * Include any adjustments necessary to `app/__init__.py` (e.g., blueprint imports, CLI registration) if new plugins or routes are added. + * For Docker setup: ensure `docker-compose.yml` still maps `./static/uploads` as a volume so that image files persist outside the container. + * When providing a response, indicate which files were added or changed by listing their relative paths and giving full contents. + * Always include a brief summary of that phase’s changes and a manual testing plan. + * **Wait for a new ZIP upload** before implementing changes. After reviewing the ZIP, return a short acknowledgement: "Got it, ready to review." then proceed phase by phase. + +**End of Prompt** + diff --git a/main-app.zip b/main-app.zip new file mode 100644 index 0000000..1fea40a Binary files /dev/null and b/main-app.zip differ diff --git a/subapp.txt b/subapp.txt new file mode 100644 index 0000000..a928b28 --- /dev/null +++ b/subapp.txt @@ -0,0 +1,119 @@ +You are ChatGPT, an expert Flask developer. I will upload two ZIP files: + +* **plant-scan-main.zip** (the standalone sub-app) +* **natureinpots\_main.zip** (the main app with its importer plugin) + +When I upload them, **immediately reply**: + +> Got it, ready to review both codebases. + +Then, following the exact file structures in those ZIPs, **implement** all of the following changes—listing every modified or new file by its relative path and providing its **complete** updated contents: + +--- + +## 1. FULL-CODE REVIEW + +* Scan **every file and every line** in both ZIPs—no exceptions, no assumptions. +* Keep all code in memory to reference original imports, blueprints, models, routes, and templates. + +--- + +## 2. SUB-APP ENHANCEMENTS (Plant Scan) + +1. **Authentication & CSRF** + + * Add Flask-Login with a `User(id, email, password_hash, created_at)` model. + * Implement **register**, **login**, **logout** routes and templates; protect all forms with CSRF. + * Scope all queries so users only see their own data (`Plant.user_id == current_user.id`, `GrowLog.user_id == current_user.id`). + +2. **Image Upload Support** + + * Modify plant-create/edit and grow-log forms to accept ``. + * Save uploads under: + + * `static/uploads///.` + * `static/uploads//growlogs///.` + * Strip EXIF, record `original_filename` and `uploaded_at` in a `Media` model. + +3. **Export My Data** + + * Add a login-required `/export` route and button. + * Generate `_export.zip` containing: + + * **plants.csv** (headers exactly): + + ``` + plant_id,common_name,scientific_name,genus,vendor_name,price,notes,created_at + ``` + * **media.csv** (headers exactly): + + ``` + plant_id,image_path,uploaded_at,source_type + ``` + * **images/** folder mirroring the upload paths. + * A hidden **export\_id** (UUID + timestamp) in a metadata file or CSV header. + * Only include the exporting user’s records and images; exclude all other assets. + +4. **Manual Testing (Sub-App)** + + * Register two users; verify isolation of plant and grow-log lists. + * Upload multiple images; confirm storage paths and DB entries. + * Export each user; unzip and verify CSV headers, rows, `images/`, and unique `export_id`. + +--- + +## 3. MAIN-APP IMPORTER REFACTOR (“Nature in Pots”) + +1. **Web-Based ZIP Upload** + + * Change the importer form to accept a `.zip` file. + * On upload, unzip into a temp directory expecting `plants.csv`, `media.csv`, and `images/`. + * If only a CSV is uploaded, process it but skip media. + +2. **CSV Header Validation** + + * Abort with a clear error if **plants.csv** does not have exactly: + + ``` + plant_id,common_name,scientific_name,genus,vendor_name,price,notes,created_at + ``` + * Abort if **media.csv** does not have exactly: + + ``` + plant_id,image_path,uploaded_at,source_type + ``` + +3. **Import Logic & Collision Avoidance** + + * For each row in `plants.csv`, create a new `Plant`. + * For each row in `media.csv`, locate the file under `images/...`, copy it into the main app’s `static/uploads` using a UUID filename if needed to avoid conflicts, and create a `Media` record with `uploaded_at` and `source_type`. + * Read `export_id` and store it in an `ImportBatch(export_id, user_id, imported_at)` table; if the same `export_id` has already been processed for that user, **skip the import** and notify the user. + +4. **Ownership Attribution** + + * Attribute all imported `Plant` and `Media` entries to **the currently logged-in main-app user**. + +5. **Schema & Neo4j** + + * Supply defaults for any non-nullable fields missing from `plants.csv`. + * Pass all imported fields (e.g. `vendor_name`) into the existing Neo4j handler when creating/updating nodes. + +6. **Manual Testing (Importer)** + + * As a main-app user, upload the `_export.zip`; confirm no duplicates on re-upload. + * Verify `Plant`, `Media`, and `PlantOwnershipLog` tables contain correct data and timestamps. + * View plant detail pages to ensure images load correctly. + * Inspect Neo4j for the new or updated plant nodes. + +--- + +## 4. DELIVERY & CONSTRAINTS + +* For **every** changed or new file, list its **relative path** and include its **entire** file contents. +* **CSV headers must match exactly**—no deviations. +* Use **UUID filenames** to guarantee no file collisions on import. +* All routes and forms must enforce **authentication** and **CSRF**. +* **Only modify** code under `app/` or `plugins/`; **do not delete** any existing files. + +Once you’ve implemented all of the above, provide a summary of the changes and confirm the manual testing results. +