changed files

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/<plugin>/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/<YYYY>/<MM>/<DD>/`, are persisted by Docker volume, and accessible via `/media/files/<path>`.
+   * 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**
+

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 `<input type="file" multiple name="images">`.
+   * Save uploads under:
+
+     * `static/uploads/<user_id>/<plant_id>/<uuid>.<ext>`
+     * `static/uploads/<user_id>/growlogs/<plant_id>/<update_id>/<uuid>.<ext>`
+   * 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 `<username>_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 `<username>_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.
+