Remove emojis from all markdown docs, add consolidation plan
- Strip emojis from 47 markdown files across docs/, sql/, and root - Add docs/DOCS_CONSOLIDATION_PLAN.md with plan to reduce 45 docs to 8 - Establish no-emoji rule for documentation going forward 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
cproudlock
@@ -458,7 +458,7 @@ FLUSH PRIVILEGES;
|
||||
|
||||
## Security Notes
|
||||
|
||||
⚠️ **Development Environment Only**
|
||||
**Development Environment Only**
|
||||
|
||||
These credentials are for DEVELOPMENT:
|
||||
- User: 570005354
|
||||
|
||||
@@ -106,10 +106,10 @@ All views currently using the `pc` table will be updated to use `machines` with
|
||||
### Phase 1: Infrastructure Setup (Scripts 01-04)
|
||||
**Reversible**: Yes
|
||||
|
||||
1. ✅ Script 01: Create communications infrastructure
|
||||
2. ✅ Script 02: Extend machines table
|
||||
3. ✅ Script 03: Create PC machine types
|
||||
4. ✅ Script 04: Create warranty infrastructure
|
||||
1. Script 01: Create communications infrastructure
|
||||
2. Script 02: Extend machines table
|
||||
3. Script 03: Create PC machine types
|
||||
4. Script 04: Create warranty infrastructure
|
||||
|
||||
**Production Deployment**: Run during maintenance window
|
||||
**Estimated Time**: 15 minutes
|
||||
@@ -118,10 +118,10 @@ All views currently using the `pc` table will be updated to use `machines` with
|
||||
### Phase 2: Data Migration (Scripts 05-08)
|
||||
**Reversible**: Yes (with backups)
|
||||
|
||||
5. ⏳ Script 05: Migrate PC data to machines
|
||||
6. ⏳ Script 06: Migrate communication data
|
||||
7. ⏳ Script 07: Migrate warranty data
|
||||
8. ⏳ Script 08: Update relationship tables
|
||||
5. Script 05: Migrate PC data to machines
|
||||
6. Script 06: Migrate communication data
|
||||
7. Script 07: Migrate warranty data
|
||||
8. Script 08: Update relationship tables
|
||||
|
||||
**Production Deployment**: Run during maintenance window
|
||||
**Estimated Time**: 30-45 minutes
|
||||
@@ -130,11 +130,11 @@ All views currently using the `pc` table will be updated to use `machines` with
|
||||
### Phase 3: Application Updates (Manual)
|
||||
**Reversible**: Yes (via version control)
|
||||
|
||||
9. ⏳ Update 19 database views
|
||||
10. ⏳ Create compatibility views
|
||||
11. ⏳ Update 10 ASP files (direct queries)
|
||||
12. ⏳ Update 30 ASP files (pc fields/views)
|
||||
13. ⏳ Test all functionality
|
||||
9. Update 19 database views
|
||||
10. Create compatibility views
|
||||
11. Update 10 ASP files (direct queries)
|
||||
12. Update 30 ASP files (pc fields/views)
|
||||
13. Test all functionality
|
||||
|
||||
**Production Deployment**: Deploy with application
|
||||
**Estimated Time**: 2-3 weeks development + testing
|
||||
@@ -143,11 +143,11 @@ All views currently using the `pc` table will be updated to use `machines` with
|
||||
### Phase 4: Cleanup (After 30 days)
|
||||
**Reversible**: No - PERMANENT
|
||||
|
||||
14. ⏳ Drop pc table
|
||||
15. ⏳ Drop pc_comm_config table
|
||||
16. ⏳ Drop pc_network_interfaces table
|
||||
17. ⏳ Drop compatibility views
|
||||
18. ⏳ Remove deprecated columns
|
||||
14. Drop pc table
|
||||
15. Drop pc_comm_config table
|
||||
16. Drop pc_network_interfaces table
|
||||
17. Drop compatibility views
|
||||
18. Remove deprecated columns
|
||||
|
||||
**Production Deployment**: Final cleanup
|
||||
**Estimated Time**: 15 minutes
|
||||
@@ -186,37 +186,37 @@ All views currently using the `pc` table will be updated to use `machines` with
|
||||
### Before Refactoring
|
||||
|
||||
**Data Model**:
|
||||
- ❌ Machines and PCs tracked separately
|
||||
- ❌ Warranty data scattered across PC records
|
||||
- ❌ Communication data in PC-specific tables
|
||||
- ❌ Multiple machines types systems (machines.machinetypeid, pc.pctypeid)
|
||||
- ❌ Rigid communication tracking
|
||||
- ❌ No warranty history
|
||||
- ❌ Limited to one warranty per PC
|
||||
- Machines and PCs tracked separately
|
||||
- Warranty data scattered across PC records
|
||||
- Communication data in PC-specific tables
|
||||
- Multiple machines types systems (machines.machinetypeid, pc.pctypeid)
|
||||
- Rigid communication tracking
|
||||
- No warranty history
|
||||
- Limited to one warranty per PC
|
||||
|
||||
**Code**:
|
||||
- ❌ Duplicate logic for machines vs PCs
|
||||
- ❌ Complex joins across pc/machines
|
||||
- ❌ PC-specific ASP files
|
||||
- ❌ Warranty tracking only for PCs
|
||||
- Duplicate logic for machines vs PCs
|
||||
- Complex joins across pc/machines
|
||||
- PC-specific ASP files
|
||||
- Warranty tracking only for PCs
|
||||
|
||||
### After Refactoring
|
||||
|
||||
**Data Model**:
|
||||
- ✅ Unified machine tracking (all assets)
|
||||
- ✅ Professional warranty management
|
||||
- ✅ Generic communication infrastructure
|
||||
- ✅ Single machine type system
|
||||
- ✅ Extensible for new communication types
|
||||
- ✅ Complete warranty audit trail
|
||||
- ✅ Multiple warranties per machine
|
||||
- Unified machine tracking (all assets)
|
||||
- Professional warranty management
|
||||
- Generic communication infrastructure
|
||||
- Single machine type system
|
||||
- Extensible for new communication types
|
||||
- Complete warranty audit trail
|
||||
- Multiple warranties per machine
|
||||
|
||||
**Code**:
|
||||
- ✅ Single codebase for all machines
|
||||
- ✅ Simpler queries
|
||||
- ✅ Unified ASP files
|
||||
- ✅ Warranty tracking for ALL machines
|
||||
- ✅ Better reporting capabilities
|
||||
- Single codebase for all machines
|
||||
- Simpler queries
|
||||
- Unified ASP files
|
||||
- Warranty tracking for ALL machines
|
||||
- Better reporting capabilities
|
||||
|
||||
---
|
||||
|
||||
@@ -237,15 +237,15 @@ All views currently using the `pc` table will be updated to use `machines` with
|
||||
|
||||
| Phase | Duration | Resources |
|
||||
|-------|----------|-----------|
|
||||
| Design & Review | 1-2 days | ✅ COMPLETE |
|
||||
| SQL Script Development | 3-5 days | ⏳ In Progress |
|
||||
| Dev Environment Testing | 3-5 days | ⏳ Pending |
|
||||
| ASP File Updates | 5-7 days | ⏳ Pending |
|
||||
| Integration Testing | 3-5 days | ⏳ Pending |
|
||||
| User Acceptance Testing | 2-3 days | ⏳ Pending |
|
||||
| Production Deployment | 1 day | ⏳ Pending |
|
||||
| Monitoring Period | 30 days | ⏳ Pending |
|
||||
| Final Cleanup | 1 day | ⏳ Pending |
|
||||
| Design & Review | 1-2 days | COMPLETE |
|
||||
| SQL Script Development | 3-5 days | In Progress |
|
||||
| Dev Environment Testing | 3-5 days | Pending |
|
||||
| ASP File Updates | 5-7 days | Pending |
|
||||
| Integration Testing | 3-5 days | Pending |
|
||||
| User Acceptance Testing | 2-3 days | Pending |
|
||||
| Production Deployment | 1 day | Pending |
|
||||
| Monitoring Period | 30 days | Pending |
|
||||
| Final Cleanup | 1 day | Pending |
|
||||
| **TOTAL** | **20-35 days** | |
|
||||
|
||||
---
|
||||
@@ -348,7 +348,7 @@ All views currently using the `pc` table will be updated to use `machines` with
|
||||
|
||||
---
|
||||
|
||||
**Status**: DESIGN PHASE COMPLETE ✅
|
||||
**Status**: DESIGN PHASE COMPLETE
|
||||
**Next Step**: Create migration scripts (scripts 05-08)
|
||||
**Target Deployment**: TBD
|
||||
|
||||
|
||||
@@ -17,10 +17,10 @@ This document outlines the finalized database migration plan that:
|
||||
6. Implements machine relationships tracking (dualpath, controller associations)
|
||||
|
||||
**Key Design Principles:**
|
||||
- ✅ Simplicity over complexity
|
||||
- ✅ Generic/flexible structures (address field in communications)
|
||||
- ✅ Leverage existing tables (vendors for third-party management)
|
||||
- ✅ Minimal columns (remove unnecessary audit fields)
|
||||
- Simplicity over complexity
|
||||
- Generic/flexible structures (address field in communications)
|
||||
- Leverage existing tables (vendors for third-party management)
|
||||
- Minimal columns (remove unnecessary audit fields)
|
||||
|
||||
---
|
||||
|
||||
@@ -374,11 +374,11 @@ ADD CONSTRAINT fk_machines_machinestatusid FOREIGN KEY (machinestatusid) REFEREN
|
||||
| 21 | dateadded | DATETIME | **NEW** - Date added |
|
||||
|
||||
**REMOVED FIELDS (after migration):**
|
||||
- ❌ `pctypeid` - No longer needed (use machinetypeid)
|
||||
- ❌ `isvnc` - Tracked in communications table
|
||||
- ❌ `requires_manual_machine_config` - Not needed
|
||||
- ❌ `ipaddress1` - Migrated to communications
|
||||
- ❌ `ipaddress2` - Migrated to communications
|
||||
- `pctypeid` - No longer needed (use machinetypeid)
|
||||
- `isvnc` - Tracked in communications table
|
||||
- `requires_manual_machine_config` - Not needed
|
||||
- `ipaddress1` - Migrated to communications
|
||||
- `ipaddress2` - Migrated to communications
|
||||
|
||||
---
|
||||
|
||||
@@ -586,35 +586,35 @@ WHERE configtype = 'IP';
|
||||
|
||||
## KEY DESIGN DECISIONS
|
||||
|
||||
### ✅ Generic `address` Field
|
||||
### Generic `address` Field
|
||||
**Decision:** Use single `address` field in communications instead of separate ipaddress/portname/etc fields.
|
||||
**Benefit:** Flexible, extensible, no unused columns per row.
|
||||
|
||||
### ✅ Simplified Warranties
|
||||
### Simplified Warranties
|
||||
**Decision:** Just warrantyname and enddate. No complex vendor/type/cost tracking.
|
||||
**Benefit:** Easy to use, easy to maintain, covers 90% of use cases.
|
||||
|
||||
### ✅ Liaison in BusinessUnits
|
||||
### Liaison in BusinessUnits
|
||||
**Decision:** Add liaison fields directly to businessunits instead of separate table.
|
||||
**Benefit:** Simpler structure, one less JOIN, appropriate granularity.
|
||||
|
||||
### ✅ Unified Machine Types
|
||||
### Unified Machine Types
|
||||
**Decision:** Add PC types as entries in machinetypes instead of separate pctype system.
|
||||
**Benefit:** Single source of truth, eliminates pctypeid column.
|
||||
|
||||
### ✅ Vendor FK for Third-Party Management
|
||||
### Vendor FK for Third-Party Management
|
||||
**Decision:** Use vendorid FK in compliance.managedbyvendorid instead of text field.
|
||||
**Benefit:** Normalized, prevents typos, enables vendor-based queries.
|
||||
|
||||
### ✅ JSON Settings Field
|
||||
### JSON Settings Field
|
||||
**Decision:** Use JSON for type-specific config in communications.
|
||||
**Benefit:** Flexible, no table bloat, easy to extend.
|
||||
|
||||
### ✅ Minimal Audit Fields
|
||||
### Minimal Audit Fields
|
||||
**Decision:** Removed dateadded/lastupdated from warranties and communications.
|
||||
**Benefit:** Simpler, only track audit fields where truly needed.
|
||||
|
||||
### ✅ Machine Relationships Table
|
||||
### Machine Relationships Table
|
||||
**Decision:** Generic relationship table instead of specific PC-to-machine or dualpath-only tables.
|
||||
**Benefit:** Flexible, extensible, supports bidirectional and directional relationships, future-proof for clusters/backup systems.
|
||||
|
||||
@@ -625,14 +625,14 @@ WHERE configtype = 'IP';
|
||||
### Phase 1: Infrastructure Setup (Scripts 01-08)
|
||||
**Status:** Ready to create SQL scripts
|
||||
|
||||
1. ✅ Script 01: Create communications infrastructure (comstypes, communications)
|
||||
2. ✅ Script 02: Extend machines table (+9 columns)
|
||||
3. ✅ Script 03: Create PC machine types in machinetypes
|
||||
4. ✅ Script 04: Create warranty infrastructure (warranties)
|
||||
5. ✅ Script 05: Create compliance infrastructure (compliance, compliancescans)
|
||||
6. ✅ Script 06: Extend businessunits table (+2 liaison fields)
|
||||
7. ✅ Script 07: Rename pcstatus to machinestatus
|
||||
8. ✅ Script 08: Create machine relationships infrastructure (relationshiptypes, machinerelationships)
|
||||
1. Script 01: Create communications infrastructure (comstypes, communications)
|
||||
2. Script 02: Extend machines table (+9 columns)
|
||||
3. Script 03: Create PC machine types in machinetypes
|
||||
4. Script 04: Create warranty infrastructure (warranties)
|
||||
5. Script 05: Create compliance infrastructure (compliance, compliancescans)
|
||||
6. Script 06: Extend businessunits table (+2 liaison fields)
|
||||
7. Script 07: Rename pcstatus to machinestatus
|
||||
8. Script 08: Create machine relationships infrastructure (relationshiptypes, machinerelationships)
|
||||
|
||||
**Estimated Time:** 25 minutes
|
||||
**Reversible:** Yes (rollback scripts provided)
|
||||
@@ -640,10 +640,10 @@ WHERE configtype = 'IP';
|
||||
### Phase 2: Data Migration (Scripts 09-12)
|
||||
**Status:** Design complete, scripts pending
|
||||
|
||||
1. ⏳ Script 09: Migrate PC data to machines
|
||||
2. ⏳ Script 10: Migrate communication data (ipaddress1/2, pc_network_interfaces, pc_comm_config)
|
||||
3. ⏳ Script 11: Migrate warranty data
|
||||
4. ⏳ Script 12: Populate machine relationships (dualpath, controller associations)
|
||||
1. Script 09: Migrate PC data to machines
|
||||
2. Script 10: Migrate communication data (ipaddress1/2, pc_network_interfaces, pc_comm_config)
|
||||
3. Script 11: Migrate warranty data
|
||||
4. Script 12: Populate machine relationships (dualpath, controller associations)
|
||||
|
||||
**Estimated Time:** 30-45 minutes
|
||||
**Reversible:** Yes (with backups)
|
||||
@@ -651,32 +651,32 @@ WHERE configtype = 'IP';
|
||||
### Phase 3: Application Updates
|
||||
**Status:** Pending
|
||||
|
||||
1. ⏳ Update 19 database views
|
||||
2. ⏳ Create compatibility views
|
||||
3. ⏳ Update ASP files
|
||||
4. ⏳ Test all functionality
|
||||
1. Update 19 database views
|
||||
2. Create compatibility views
|
||||
3. Update ASP files
|
||||
4. Test all functionality
|
||||
|
||||
**Estimated Time:** 2-3 weeks
|
||||
|
||||
### Phase 4: Cleanup (After 30 days)
|
||||
**Status:** Pending
|
||||
|
||||
1. ⏳ Drop pc table
|
||||
2. ⏳ Drop pc_comm_config, pc_network_interfaces
|
||||
3. ⏳ Drop pctype table
|
||||
4. ⏳ Drop compatibility views
|
||||
5. ⏳ Drop machines.ipaddress1, machines.ipaddress2
|
||||
1. Drop pc table
|
||||
2. Drop pc_comm_config, pc_network_interfaces
|
||||
3. Drop pctype table
|
||||
4. Drop compatibility views
|
||||
5. Drop machines.ipaddress1, machines.ipaddress2
|
||||
|
||||
---
|
||||
|
||||
## RISK MITIGATION
|
||||
|
||||
**Critical Success Factors:**
|
||||
- ✅ Full database backup before any changes
|
||||
- ✅ Test all scripts on dev environment first
|
||||
- ✅ Rollback scripts for Phase 1
|
||||
- ✅ 30-day verification period before dropping old tables
|
||||
- ✅ Compatibility views to support gradual application migration
|
||||
- Full database backup before any changes
|
||||
- Test all scripts on dev environment first
|
||||
- Rollback scripts for Phase 1
|
||||
- 30-day verification period before dropping old tables
|
||||
- Compatibility views to support gradual application migration
|
||||
|
||||
**Rollback Strategy:**
|
||||
- Phase 1: Run rollback scripts (drop new tables, revert ALTER TABLEs)
|
||||
|
||||
@@ -425,7 +425,7 @@ The codebase uses TWO approaches (needs standardization):
|
||||
strSQL = "SELECT * FROM machines WHERE machineid = ?"
|
||||
Set rs = objConn.Execute(strSQL)
|
||||
```
|
||||
⚠️ **Security Issue:** Not properly parameterized!
|
||||
**Security Issue:** Not properly parameterized!
|
||||
|
||||
**Modern pattern (with parameterization):**
|
||||
```vbscript
|
||||
|
||||
168
docs/DOCS_CONSOLIDATION_PLAN.md
Normal file
168
docs/DOCS_CONSOLIDATION_PLAN.md
Normal file
@@ -0,0 +1,168 @@
|
||||
# ShopDB Documentation Consolidation Plan
|
||||
|
||||
**Created:** 2025-12-11
|
||||
**Total Files:** 45 markdown files (25 in `/docs/`, 20 in root)
|
||||
**Total Lines:** ~19,400 lines
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
The documentation has grown organically during the Phase 1-3 migration work. Many files are now historical/completed and can be archived. The goal is to have **6-8 essential docs** that developers actually need.
|
||||
|
||||
---
|
||||
|
||||
## Proposed Structure
|
||||
|
||||
```
|
||||
shopdb/
|
||||
├── CLAUDE.md # KEEP - Claude Code instructions
|
||||
├── TODO.md # KEEP - Active task list
|
||||
│
|
||||
└── docs/
|
||||
├── README.md # REWRITE - Main index/getting started
|
||||
├── DEVELOPMENT.md # MERGE - Dev setup + patterns (from ASP_DEVELOPMENT_GUIDE + STANDARDS)
|
||||
├── DATABASE.md # NEW - Current schema + common queries
|
||||
├── API.md # RENAME - API documentation (from API_ASP_DOCUMENTATION)
|
||||
├── QUICK_REFERENCE.md # UPDATE - Cheat sheet
|
||||
│
|
||||
└── archive/ # NEW - Historical docs
|
||||
└── [completed work]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Action Plan
|
||||
|
||||
### 1. KEEP AS-IS (Root)
|
||||
|
||||
| File | Reason |
|
||||
|------|--------|
|
||||
| `CLAUDE.md` | Active - Claude Code instructions |
|
||||
| `TODO.md` | Active - Task tracking |
|
||||
|
||||
### 2. KEEP & UPDATE (docs/)
|
||||
|
||||
| File | Action |
|
||||
|------|--------|
|
||||
| `README.md` | Rewrite as simple getting-started guide |
|
||||
| `QUICK_REFERENCE.md` | Update with current info, trim fat |
|
||||
|
||||
### 3. MERGE INTO NEW FILES
|
||||
|
||||
#### → `docs/DEVELOPMENT.md` (merge these):
|
||||
| Source File | Lines | Take From |
|
||||
|-------------|-------|-----------|
|
||||
| `docs/ASP_DEVELOPMENT_GUIDE.md` | 586 | Dev setup, workflow, patterns |
|
||||
| `docs/STANDARDS.md` | 1232 | Coding standards (trim to essentials) |
|
||||
| `docs/NESTED_ENTITY_CREATION.md` | 218 | Complex form patterns |
|
||||
| `CLAUDE_PROJECT_INSTRUCTIONS.md` | 76 | VBScript rules |
|
||||
| `CLAUDE_REFERENCE.md` | 198 | Code patterns |
|
||||
|
||||
#### → `docs/DATABASE.md` (merge these):
|
||||
| Source File | Lines | Take From |
|
||||
|-------------|-------|-----------|
|
||||
| `docs/MIGRATION_STATUS_SUMMARY.md` | 166 | Current architecture |
|
||||
| `docs/MIGRATION_QUICK_REFERENCE.md` | 197 | Key queries |
|
||||
| `docs/INVENTORY_COLUMN_MAPPING.md` | 214 | Column reference |
|
||||
| `MACHINE_QUICK_REFERENCE.md` | 337 | Machine queries |
|
||||
|
||||
#### → `docs/API.md` (rename/move):
|
||||
| Source File | Lines | Action |
|
||||
|-------------|-------|--------|
|
||||
| `API_ASP_DOCUMENTATION.md` | 827 | Move to docs/API.md |
|
||||
|
||||
### 4. ARCHIVE (Historical - Completed Work)
|
||||
|
||||
Move to `docs/archive/`:
|
||||
|
||||
| File | Lines | Reason |
|
||||
|------|-------|--------|
|
||||
| `docs/DATABASE_MIGRATION_FINAL_DESIGN.md` | 696 | Phase 1 complete |
|
||||
| `docs/PC_MACHINES_CONSOLIDATION_PLAN.md` | 780 | Phase 2 complete |
|
||||
| `docs/PHASE3_NETWORK_DEVICES_MIGRATION_PLAN.md` | 489 | Phase 3 complete |
|
||||
| `docs/DEEP_DIVE_REPORT.md` | 1153 | Outdated - replace with DATABASE.md |
|
||||
| `docs/COMPLETE_REFACTORING_SUMMARY.md` | 357 | Completed work |
|
||||
| `docs/MACHINE_RELATIONSHIPS_EXAMPLES.md` | 342 | Merge into DATABASE.md |
|
||||
| `docs/INFRASTRUCTURE_*.md` (4 files) | ~1800 | Design docs - completed |
|
||||
| `docs/VENDOR_*.md` (2 files) | ~996 | Refactoring - completed |
|
||||
| `docs/PRINTER_MAP_MIGRATION_REPORT.md` | 593 | Completed |
|
||||
| `docs/WARRANTY_MANAGEMENT_DESIGN.md` | 516 | Design doc |
|
||||
| `docs/NETWORK_DEVICES_UNIFIED_DESIGN.md` | 740 | Design doc |
|
||||
|
||||
Move to `docs/archive/sessions/`:
|
||||
|
||||
| File | Lines | Reason |
|
||||
|------|-------|--------|
|
||||
| `SESSION_SUMMARY_2025-11-10.md` | 417 | Historical |
|
||||
| `SESSION_SUMMARY_2025-11-13.md` | 686 | Historical |
|
||||
| `PHASE2_*.md` (3 files) | ~1400 | Completed work |
|
||||
| `MACHINE_*.md` (4 files) | ~1700 | Completed work |
|
||||
| `DISPLAY_PAGES_UPDATE_SUMMARY.md` | 469 | Completed |
|
||||
| `ADD_EDIT_MACHINE_UPDATES.md` | 433 | Completed |
|
||||
| `BUG_FIXES_2025-11-14.md` | 455 | Historical |
|
||||
| `PRINTER_*.md` (2 files) | ~500 | Completed |
|
||||
| `SCHEMA_COMPARISON_REPORT_2025-11-20.md` | 291 | Historical |
|
||||
|
||||
### 5. DELETE (Redundant)
|
||||
|
||||
| File | Reason |
|
||||
|------|--------|
|
||||
| `CLAUDE_PROJECT_INSTRUCTIONS.md` | Merged into DEVELOPMENT.md |
|
||||
| `CLAUDE_REFERENCE.md` | Merged into DEVELOPMENT.md + DATABASE.md |
|
||||
|
||||
---
|
||||
|
||||
## Final Result
|
||||
|
||||
### Essential Docs (6 files):
|
||||
```
|
||||
docs/
|
||||
├── README.md (~100 lines) - Getting started, links
|
||||
├── DEVELOPMENT.md (~400 lines) - Setup, standards, patterns
|
||||
├── DATABASE.md (~300 lines) - Schema, queries, architecture
|
||||
├── API.md (~500 lines) - API endpoints
|
||||
├── QUICK_REFERENCE.md (~200 lines) - Cheat sheet
|
||||
└── archive/ - Historical docs (for reference)
|
||||
```
|
||||
|
||||
### Root Files (2 files):
|
||||
```
|
||||
shopdb/
|
||||
├── CLAUDE.md - Claude Code instructions
|
||||
└── TODO.md - Active tasks
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Style Rules for New Docs
|
||||
|
||||
- **No emojis** - Use text markers instead (e.g., `[OK]`, `[FAIL]`, `NOTE:`, `WARNING:`)
|
||||
- Plain markdown formatting only
|
||||
- Consistent heading hierarchy
|
||||
|
||||
---
|
||||
|
||||
## Execution Order
|
||||
|
||||
1. Create `docs/archive/` and `docs/archive/sessions/` directories
|
||||
2. Move historical files to archive
|
||||
3. Create new `docs/DATABASE.md` (consolidate schema info)
|
||||
4. Create new `docs/DEVELOPMENT.md` (consolidate dev guides)
|
||||
5. Move `API_ASP_DOCUMENTATION.md` → `docs/API.md`
|
||||
6. Rewrite `docs/README.md` as simple index
|
||||
7. Update `docs/QUICK_REFERENCE.md`
|
||||
8. Delete redundant files
|
||||
9. Update `CLAUDE.md` to reference new structure
|
||||
|
||||
---
|
||||
|
||||
## Space Savings
|
||||
|
||||
- **Before:** 45 files, ~19,400 lines
|
||||
- **After:** 8 active files, ~1,500 lines + archive
|
||||
- **Reduction:** ~90% in active documentation
|
||||
|
||||
---
|
||||
|
||||
**Ready to execute?**
|
||||
@@ -23,9 +23,9 @@ idfs:
|
||||
cameras:
|
||||
- cameraid INT(11) PK
|
||||
- modelid INT(11) → models.modelnumberid → vendors
|
||||
- idfid INT(11) → idfs.idfid ✅ Already has parent!
|
||||
- idfid INT(11) → idfs.idfid Already has parent!
|
||||
- serialnumber VARCHAR(100)
|
||||
- macaddress VARCHAR(17) ✅ Camera-specific
|
||||
- macaddress VARCHAR(17) Camera-specific
|
||||
- ipaddress VARCHAR(45)
|
||||
- description VARCHAR(255)
|
||||
- maptop, mapleft INT(11)
|
||||
@@ -382,13 +382,13 @@ Response.Write("];")
|
||||
|
||||
## Summary: Why This Approach?
|
||||
|
||||
✅ **Hierarchical relationships** - Cameras/switches belong to IDFs
|
||||
✅ **Type-specific fields** - MAC address for cameras, idfname for IDFs
|
||||
✅ **Flexible** - Can add more fields per type later
|
||||
✅ **Clean data model** - Proper normalization
|
||||
✅ **Unified list view** - See all infrastructure in one place
|
||||
✅ **Type-specific edit** - Appropriate fields per device type
|
||||
✅ **Map integration** - All devices can be mapped
|
||||
**Hierarchical relationships** - Cameras/switches belong to IDFs
|
||||
**Type-specific fields** - MAC address for cameras, idfname for IDFs
|
||||
**Flexible** - Can add more fields per type later
|
||||
**Clean data model** - Proper normalization
|
||||
**Unified list view** - See all infrastructure in one place
|
||||
**Type-specific edit** - Appropriate fields per device type
|
||||
**Map integration** - All devices can be mapped
|
||||
|
||||
**Total Files:** 7 ASP files (1 list + 4 detail + 1 add + 1 save)
|
||||
|
||||
|
||||
@@ -23,9 +23,9 @@ idfs:
|
||||
cameras:
|
||||
- cameraid INT(11) PK
|
||||
- modelid INT(11) → models → vendors
|
||||
- idfid INT(11) → idfs.idfid ✅ (already exists!)
|
||||
- idfid INT(11) → idfs.idfid (already exists!)
|
||||
- serialnumber VARCHAR(100)
|
||||
- macaddress VARCHAR(17) ✅ (already exists!)
|
||||
- macaddress VARCHAR(17) (already exists!)
|
||||
- ipaddress VARCHAR(45)
|
||||
- description VARCHAR(255)
|
||||
- maptop, mapleft INT(11)
|
||||
@@ -72,10 +72,10 @@ This adds `modelid` to servers/switches/cameras (if not already present).
|
||||
|
||||
| Device | Unique Fields | Needs Custom Page? |
|
||||
|--------|---------------|-------------------|
|
||||
| **IDF** | idfname (no model/vendor) | ✅ YES - different structure |
|
||||
| **Camera** | idfid dropdown, macaddress | ✅ YES - has IDF + MAC |
|
||||
| **Server** | Standard fields only | ❌ NO - same as switch |
|
||||
| **Switch** | Standard fields only | ❌ NO - same as server |
|
||||
| **IDF** | idfname (no model/vendor) | YES - different structure |
|
||||
| **Camera** | idfid dropdown, macaddress | YES - has IDF + MAC |
|
||||
| **Server** | Standard fields only | NO - same as switch |
|
||||
| **Switch** | Standard fields only | NO - same as server |
|
||||
|
||||
### Optimization: Combine Server/Switch Edit
|
||||
|
||||
@@ -304,14 +304,14 @@ Or use the existing approach with type selector in add_network_device.asp.
|
||||
|
||||
| Field | IDF | Server | Switch | Camera |
|
||||
|-------|-----|--------|--------|--------|
|
||||
| idfname | ✅ | ❌ | ❌ | ❌ |
|
||||
| modelid | ❌ | ✅ | ✅ | ✅ |
|
||||
| idfid (parent) | ❌ | ❌ | ❌ | ✅ |
|
||||
| macaddress | ❌ | ❌ | ❌ | ✅ |
|
||||
| serialnumber | ❌ | ✅ | ✅ | ✅ |
|
||||
| ipaddress | ❌ | ✅ | ✅ | ✅ |
|
||||
| description | ✅ | ✅ | ✅ | ✅ |
|
||||
| maptop, mapleft | ✅ | ✅ | ✅ | ✅ |
|
||||
| idfname | | | | |
|
||||
| modelid | | | | |
|
||||
| idfid (parent) | | | | |
|
||||
| macaddress | | | | |
|
||||
| serialnumber | | | | |
|
||||
| ipaddress | | | | |
|
||||
| description | | | | |
|
||||
| maptop, mapleft | | | | |
|
||||
|
||||
### Pages Needed
|
||||
|
||||
@@ -355,9 +355,9 @@ Or use the existing approach with type selector in add_network_device.asp.
|
||||
- Creates `vw_network_devices` view
|
||||
|
||||
**What we DON'T need:**
|
||||
- ❌ Add `idfid` to switches (not tracking)
|
||||
- ❌ Add `idfid` to servers (not tracking)
|
||||
- ✅ Cameras already have `idfid` and `macaddress`
|
||||
- Add `idfid` to switches (not tracking)
|
||||
- Add `idfid` to servers (not tracking)
|
||||
- Cameras already have `idfid` and `macaddress`
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -10,19 +10,19 @@
|
||||
|
||||
**Goal:** Extend the existing vendor/model system (currently used for PCs, Printers, and Machines) to also support infrastructure devices (Servers, Switches, Cameras).
|
||||
|
||||
**Decision:** ✅ **Vendor types ABANDONED** - Keeping the simple vendors table as-is. No boolean flag refactoring needed.
|
||||
**Decision:** **Vendor types ABANDONED** - Keeping the simple vendors table as-is. No boolean flag refactoring needed.
|
||||
|
||||
### What We're Building
|
||||
|
||||
| Feature | Status | Impact |
|
||||
|---------|--------|--------|
|
||||
| Add `modelid` to servers/switches/cameras | ✅ Script ready | Database schema |
|
||||
| Create `vw_network_devices` view | ✅ Script ready | Unified infrastructure query |
|
||||
| Create server CRUD pages | ❌ New development | 4 files |
|
||||
| Create switch CRUD pages | ❌ New development | 4 files |
|
||||
| Create camera CRUD pages | ❌ New development | 4 files |
|
||||
| Update navigation | ❌ New development | Menu items |
|
||||
| Update network map | 🟡 Optional | Display vendor/model |
|
||||
| Add `modelid` to servers/switches/cameras | Script ready | Database schema |
|
||||
| Create `vw_network_devices` view | Script ready | Unified infrastructure query |
|
||||
| Create server CRUD pages | New development | 4 files |
|
||||
| Create switch CRUD pages | New development | 4 files |
|
||||
| Create camera CRUD pages | New development | 4 files |
|
||||
| Update navigation | New development | Menu items |
|
||||
| Update network map | Optional | Display vendor/model |
|
||||
|
||||
**Total New Files:** 12 ASP pages + nav updates
|
||||
**Total Modified Files:** ~2-3 (navigation, possibly network_map.asp)
|
||||
@@ -522,22 +522,22 @@ If issues arise:
|
||||
|
||||
## Part 10: Success Criteria
|
||||
|
||||
✅ **Database:**
|
||||
**Database:**
|
||||
- All 3 tables have modelid column with FK to models
|
||||
- vw_network_devices view returns data from all 3 tables
|
||||
|
||||
✅ **Functionality:**
|
||||
**Functionality:**
|
||||
- Can add/edit/view/delete servers, switches, cameras
|
||||
- Vendor/model information displays correctly
|
||||
- Forms validate inputs properly
|
||||
- No SQL errors
|
||||
|
||||
✅ **User Experience:**
|
||||
**User Experience:**
|
||||
- Navigation easy to find
|
||||
- Forms intuitive (like printer/machine forms)
|
||||
- List views show relevant info at a glance
|
||||
|
||||
✅ **Code Quality:**
|
||||
**Code Quality:**
|
||||
- Follows existing coding standards (STANDARDS.md)
|
||||
- Uses parameterized queries (no SQL injection)
|
||||
- Proper error handling
|
||||
|
||||
@@ -195,7 +195,7 @@ GROUP BY m.machineid;
|
||||
|
||||
## Coverage Summary
|
||||
|
||||
✅ **100% Coverage** - All 35 inventory columns mapped to database
|
||||
**100% Coverage** - All 35 inventory columns mapped to database
|
||||
|
||||
**Storage Distribution:**
|
||||
- `machines` table: 11 columns
|
||||
@@ -207,8 +207,8 @@ GROUP BY m.machineid;
|
||||
- Various lookup tables: 3 columns
|
||||
|
||||
**Design Benefits:**
|
||||
- ✅ Normalized structure (no redundancy)
|
||||
- ✅ Flexible relationships (dualpath, controller associations)
|
||||
- ✅ Extensible (easy to add new fields/types)
|
||||
- ✅ Complete audit trail
|
||||
- ✅ Single source of truth
|
||||
- Normalized structure (no redundancy)
|
||||
- Flexible relationships (dualpath, controller associations)
|
||||
- Extensible (easy to add new fields/types)
|
||||
- Complete audit trail
|
||||
- Single source of truth
|
||||
|
||||
@@ -318,13 +318,13 @@ End If
|
||||
|
||||
## Benefits of This Design
|
||||
|
||||
✅ **Flexible** - Any machine can relate to any other machine
|
||||
✅ **Bidirectional** - Dualpath works both ways automatically
|
||||
✅ **Directional** - "Controlled By" has clear direction
|
||||
✅ **Extensible** - Easy to add new relationship types
|
||||
✅ **Query-friendly** - Simple JOINs to get related machines
|
||||
✅ **Unified** - PCs are machines too, so PC-to-machine relationships use same table
|
||||
✅ **Future-proof** - Supports clusters, backups, master-slave, etc.
|
||||
**Flexible** - Any machine can relate to any other machine
|
||||
**Bidirectional** - Dualpath works both ways automatically
|
||||
**Directional** - "Controlled By" has clear direction
|
||||
**Extensible** - Easy to add new relationship types
|
||||
**Query-friendly** - Simple JOINs to get related machines
|
||||
**Unified** - PCs are machines too, so PC-to-machine relationships use same table
|
||||
**Future-proof** - Supports clusters, backups, master-slave, etc.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -48,13 +48,13 @@ Drop after 30-day testing:
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
✅ **Generic `address` field** - One field for IP/COM/USB/etc (determined by comstypeid)
|
||||
✅ **Simplified warranties** - Just name + expiration date
|
||||
✅ **Liaison in businessunits** - No separate liaisons table
|
||||
✅ **Unified machine types** - PC types added to machinetypes
|
||||
✅ **Vendor FK** - compliance.managedbyvendorid → vendors table
|
||||
✅ **Minimal audit** - Removed unnecessary dateadded/lastupdated fields
|
||||
✅ **Machine relationships** - Generic table for dualpath, PC-to-machine control, future clusters
|
||||
**Generic `address` field** - One field for IP/COM/USB/etc (determined by comstypeid)
|
||||
**Simplified warranties** - Just name + expiration date
|
||||
**Liaison in businessunits** - No separate liaisons table
|
||||
**Unified machine types** - PC types added to machinetypes
|
||||
**Vendor FK** - compliance.managedbyvendorid → vendors table
|
||||
**Minimal audit** - Removed unnecessary dateadded/lastupdated fields
|
||||
**Machine relationships** - Generic table for dualpath, PC-to-machine control, future clusters
|
||||
|
||||
---
|
||||
|
||||
@@ -190,7 +190,7 @@ Drop after 30-day testing:
|
||||
|
||||
## Next Step
|
||||
|
||||
✅ **Create Phase 1 SQL Scripts** (8 scripts + 8 rollback scripts)
|
||||
**Create Phase 1 SQL Scripts** (8 scripts + 8 rollback scripts)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -9,11 +9,11 @@
|
||||
## Concept: One Page to Rule Them All
|
||||
|
||||
Instead of separate pages per device type, create a unified **Network Devices** page that shows:
|
||||
- 🖥️ Servers
|
||||
- 🔌 Switches
|
||||
- Servers
|
||||
- Switches
|
||||
- 📹 Cameras
|
||||
- 📡 Access Points (if you add them later)
|
||||
- 📦 IDFs (Intermediate Distribution Frames)
|
||||
- Access Points (if you add them later)
|
||||
- IDFs (Intermediate Distribution Frames)
|
||||
|
||||
**User Experience:**
|
||||
- Click "Network Devices" → See ALL devices in one table
|
||||
@@ -725,14 +725,14 @@ To add **Access Points** or **IDFs** later:
|
||||
|
||||
## Summary: Why This Is Better
|
||||
|
||||
✅ **Single source of truth** - One page for all infrastructure
|
||||
✅ **Easy filtering** - Tabs to view by type or see all
|
||||
✅ **Consistent UX** - Same interface for all device types
|
||||
✅ **Uses existing view** - `vw_network_devices` already unifies them
|
||||
✅ **Only 4 files** - vs 12 separate files
|
||||
✅ **Easy to extend** - Add new device types without file duplication
|
||||
✅ **Matches mental model** - "Network Devices" is how users think
|
||||
✅ **Search/filter across all** - Find any device in one place
|
||||
**Single source of truth** - One page for all infrastructure
|
||||
**Easy filtering** - Tabs to view by type or see all
|
||||
**Consistent UX** - Same interface for all device types
|
||||
**Uses existing view** - `vw_network_devices` already unifies them
|
||||
**Only 4 files** - vs 12 separate files
|
||||
**Easy to extend** - Add new device types without file duplication
|
||||
**Matches mental model** - "Network Devices" is how users think
|
||||
**Search/filter across all** - Find any device in one place
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**Date Created**: 2025-11-06
|
||||
**Status**: DESIGN PHASE
|
||||
**Complexity**: ⚠️ **CRITICAL - MASSIVE REFACTORING**
|
||||
**Complexity**: **CRITICAL - MASSIVE REFACTORING**
|
||||
**Production Deployment**: All SQL changes must be tracked
|
||||
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Phase 3: Network Devices Migration to machines Table
|
||||
|
||||
**Date:** 2025-11-10
|
||||
**Status:** 📋 PLANNING
|
||||
**Status:** PLANNING
|
||||
**Follows:** Phase 2 (PC Migration - Completed)
|
||||
|
||||
---
|
||||
@@ -14,7 +14,7 @@ Consolidate all network infrastructure devices (servers, switches, cameras, acce
|
||||
|
||||
## Scope
|
||||
|
||||
### ✅ Migrate INTO machines Table:
|
||||
### Migrate INTO machines Table:
|
||||
- **Servers** → machinetypeid 30
|
||||
- **Switches** → machinetypeid 31
|
||||
- **Cameras** → machinetypeid 32
|
||||
@@ -23,7 +23,7 @@ Consolidate all network infrastructure devices (servers, switches, cameras, acce
|
||||
- **Routers** → machinetypeid 35 (if exists)
|
||||
- **Firewalls** → machinetypeid 36 (if exists)
|
||||
|
||||
### ❌ Keep SEPARATE:
|
||||
### Keep SEPARATE:
|
||||
- **Printers** → Stay in `printers` table (unique fields, workflows, APIs)
|
||||
|
||||
---
|
||||
@@ -38,12 +38,12 @@ Consolidate all network infrastructure devices (servers, switches, cameras, acce
|
||||
5. **Inconsistent UI/UX:** Different interfaces for similar devices
|
||||
|
||||
### After Migration:
|
||||
1. ✅ **Single Source of Truth:** All infrastructure in `machines` table
|
||||
2. ✅ **Unified Relationships:** Camera → Switch → IDF using `machinerelationships`
|
||||
3. ✅ **Unified Communications:** All IPs in `communications` table
|
||||
4. ✅ **Consistent UI:** One set of pages for all devices
|
||||
5. ✅ **Powerful Queries:** Cross-device reports and topology mapping
|
||||
6. ✅ **Better Compliance:** All devices tracked in one place
|
||||
1. **Single Source of Truth:** All infrastructure in `machines` table
|
||||
2. **Unified Relationships:** Camera → Switch → IDF using `machinerelationships`
|
||||
3. **Unified Communications:** All IPs in `communications` table
|
||||
4. **Consistent UI:** One set of pages for all devices
|
||||
5. **Powerful Queries:** Cross-device reports and topology mapping
|
||||
6. **Better Compliance:** All devices tracked in one place
|
||||
|
||||
---
|
||||
|
||||
@@ -233,10 +233,10 @@ INSERT INTO relationshiptypes (relationshiptype, description, isbidirectional) V
|
||||
## Migration Order
|
||||
|
||||
### Pre-Migration:
|
||||
1. ✅ **Backup database**
|
||||
2. ✅ **Verify Phase 2 is stable**
|
||||
3. ✅ **Document current table structures**
|
||||
4. ✅ **Count records in each table**
|
||||
1. **Backup database**
|
||||
2. **Verify Phase 2 is stable**
|
||||
3. **Document current table structures**
|
||||
4. **Count records in each table**
|
||||
|
||||
### Migration Steps:
|
||||
1. **Create new machinetypes** (30-36)
|
||||
@@ -263,16 +263,16 @@ INSERT INTO relationshiptypes (relationshiptype, description, isbidirectional) V
|
||||
## Code Updates Required
|
||||
|
||||
### Pages to Update:
|
||||
1. ✅ **displaymachines.asp** - Add filter tabs for network devices
|
||||
2. ✅ **displaymachine.asp** - Already supports all types via machinetypeid
|
||||
3. ✅ **machine_edit.asp** - Already supports all types
|
||||
4. ✅ **adddevice.asp** - Update to include network device types
|
||||
1. **displaymachines.asp** - Add filter tabs for network devices
|
||||
2. **displaymachine.asp** - Already supports all types via machinetypeid
|
||||
3. **machine_edit.asp** - Already supports all types
|
||||
4. **adddevice.asp** - Update to include network device types
|
||||
|
||||
### Pages to Deprecate:
|
||||
1. ❌ **displayservers.asp** → Redirect to displaymachines.asp?type=server
|
||||
2. ❌ **displayswitches.asp** → Redirect to displaymachines.asp?type=switch
|
||||
3. ❌ **displaycameras.asp** → Redirect to displaymachines.asp?type=camera
|
||||
4. ❌ **network_devices.asp** → Redirect to displaymachines.asp?category=network
|
||||
1. **displayservers.asp** → Redirect to displaymachines.asp?type=server
|
||||
2. **displayswitches.asp** → Redirect to displaymachines.asp?type=switch
|
||||
3. **displaycameras.asp** → Redirect to displaymachines.asp?type=camera
|
||||
4. **network_devices.asp** → Redirect to displaymachines.asp?category=network
|
||||
|
||||
### Views to Update:
|
||||
```sql
|
||||
@@ -389,7 +389,7 @@ SELECT COUNT(*) FROM cameras;
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### ✅ Migration Successful If:
|
||||
### Migration Successful If:
|
||||
1. All records migrated (counts match)
|
||||
2. All IP addresses migrated to communications
|
||||
3. All relationships preserved
|
||||
@@ -417,55 +417,55 @@ SELECT COUNT(*) FROM cameras;
|
||||
## Risk Assessment
|
||||
|
||||
### Low Risk:
|
||||
- ✅ Pattern proven with Phase 2 PC migration
|
||||
- ✅ Can be rolled back easily
|
||||
- ✅ Old tables kept temporarily
|
||||
- ✅ Comprehensive verification
|
||||
- Pattern proven with Phase 2 PC migration
|
||||
- Can be rolled back easily
|
||||
- Old tables kept temporarily
|
||||
- Comprehensive verification
|
||||
|
||||
### Medium Risk:
|
||||
- ⚠️ Multiple tables being migrated
|
||||
- ⚠️ Code references to update
|
||||
- ⚠️ Testing required for all device types
|
||||
- Multiple tables being migrated
|
||||
- Code references to update
|
||||
- Testing required for all device types
|
||||
|
||||
### Mitigation:
|
||||
- ✅ **Test on backup database first**
|
||||
- ✅ **Migrate one device type at a time**
|
||||
- ✅ **Verify after each migration**
|
||||
- ✅ **Keep old tables for 30 days**
|
||||
- ✅ **Update code incrementally**
|
||||
- **Test on backup database first**
|
||||
- **Migrate one device type at a time**
|
||||
- **Verify after each migration**
|
||||
- **Keep old tables for 30 days**
|
||||
- **Update code incrementally**
|
||||
|
||||
---
|
||||
|
||||
## Benefits After Completion
|
||||
|
||||
### Immediate:
|
||||
1. ✅ Single query for all infrastructure
|
||||
2. ✅ Unified relationship management
|
||||
3. ✅ Camera → IDF relationships work
|
||||
4. ✅ Consistent UI across all devices
|
||||
5. ✅ Better network topology visibility
|
||||
1. Single query for all infrastructure
|
||||
2. Unified relationship management
|
||||
3. Camera → IDF relationships work
|
||||
4. Consistent UI across all devices
|
||||
5. Better network topology visibility
|
||||
|
||||
### Long-Term:
|
||||
1. ✅ Easier to add new device types
|
||||
2. ✅ Less code duplication
|
||||
3. ✅ Better reporting capabilities
|
||||
4. ✅ Simplified maintenance
|
||||
5. ✅ CMDB-style asset management
|
||||
6. ✅ Better compliance tracking
|
||||
1. Easier to add new device types
|
||||
2. Less code duplication
|
||||
3. Better reporting capabilities
|
||||
4. Simplified maintenance
|
||||
5. CMDB-style asset management
|
||||
6. Better compliance tracking
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. ✅ **Create migration SQL scripts**
|
||||
2. ✅ **Create verification scripts**
|
||||
3. ✅ **Create rollback scripts**
|
||||
4. ✅ **Test on backup database**
|
||||
5. ✅ **Review and approve plan**
|
||||
6. ✅ **Schedule migration window**
|
||||
7. ✅ **Execute migration**
|
||||
8. ✅ **Update code**
|
||||
9. ✅ **Monitor and verify**
|
||||
1. **Create migration SQL scripts**
|
||||
2. **Create verification scripts**
|
||||
3. **Create rollback scripts**
|
||||
4. **Test on backup database**
|
||||
5. **Review and approve plan**
|
||||
6. **Schedule migration window**
|
||||
7. **Execute migration**
|
||||
8. **Update code**
|
||||
9. **Monitor and verify**
|
||||
|
||||
---
|
||||
|
||||
@@ -478,11 +478,11 @@ SELECT COUNT(*) FROM cameras;
|
||||
|
||||
## Questions to Answer Before Migration
|
||||
|
||||
1. ✅ Do accesspoints and idfs tables exist?
|
||||
2. ✅ Are there any custom fields in device tables we need to preserve?
|
||||
3. ✅ Are there any foreign key constraints to old tables?
|
||||
4. ✅ What's the maintenance window schedule?
|
||||
5. ✅ Should we create camera → IDF relationships during migration or manually after?
|
||||
1. Do accesspoints and idfs tables exist?
|
||||
2. Are there any custom fields in device tables we need to preserve?
|
||||
3. Are there any foreign key constraints to old tables?
|
||||
4. What's the maintenance window schedule?
|
||||
5. Should we create camera → IDF relationships during migration or manually after?
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
The `printers` table now has `maptop` and `mapleft` columns added for direct printer location mapping on the shop floor map. This migration report outlines the necessary code changes to transition from machine-based printer positioning to direct printer positioning.
|
||||
|
||||
### Database Changes Completed ✅
|
||||
### Database Changes Completed
|
||||
- Added `maptop INT(11)` column to `printers` table
|
||||
- Added `mapleft INT(11)` column to `printers` table
|
||||
- Both columns are nullable (default NULL)
|
||||
@@ -52,9 +52,9 @@ end if
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- ❌ Printers without machine assignment (`machineid=1`) are excluded from map
|
||||
- ❌ Multiple printers at same machine appear stacked on same coordinate
|
||||
- ❌ Cannot position printer independently of machine
|
||||
- Printers without machine assignment (`machineid=1`) are excluded from map
|
||||
- Multiple printers at same machine appear stacked on same coordinate
|
||||
- Cannot position printer independently of machine
|
||||
|
||||
---
|
||||
|
||||
@@ -78,9 +78,9 @@ end if
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- ❌ No way to set `maptop`/`mapleft` during printer creation
|
||||
- ❌ Printer position tied to machine selection
|
||||
- ❌ Cannot add printer without machine assignment
|
||||
- No way to set `maptop`/`mapleft` during printer creation
|
||||
- Printer position tied to machine selection
|
||||
- Cannot add printer without machine assignment
|
||||
|
||||
---
|
||||
|
||||
@@ -98,8 +98,8 @@ strSQL = "INSERT INTO printers (modelid, serialnumber, ipaddress, fqdn,
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- ❌ Does not insert `maptop`/`mapleft` values
|
||||
- ❌ New printers won't have coordinates
|
||||
- Does not insert `maptop`/`mapleft` values
|
||||
- New printers won't have coordinates
|
||||
|
||||
---
|
||||
|
||||
@@ -111,8 +111,8 @@ strSQL = "INSERT INTO printers (modelid, serialnumber, ipaddress, fqdn,
|
||||
- No map coordinate fields
|
||||
|
||||
**Issues:**
|
||||
- ❌ Cannot edit printer coordinates
|
||||
- ❌ No map picker interface
|
||||
- Cannot edit printer coordinates
|
||||
- No map picker interface
|
||||
|
||||
---
|
||||
|
||||
@@ -136,7 +136,7 @@ strSQL = "UPDATE printers SET " & _
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- ❌ Does not update `maptop`/`mapleft`
|
||||
- Does not update `maptop`/`mapleft`
|
||||
|
||||
---
|
||||
|
||||
@@ -159,8 +159,8 @@ strSQL = "UPDATE printers SET " & _
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- ❌ Still references machine location
|
||||
- ❌ No display of printer's actual map coordinates
|
||||
- Still references machine location
|
||||
- No display of printer's actual map coordinates
|
||||
|
||||
---
|
||||
|
||||
@@ -201,10 +201,10 @@ while not rs.eof
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
- ✅ Uses printer coordinates if available
|
||||
- ✅ Falls back to machine coordinates if printer coordinates not set
|
||||
- ✅ Includes printers without machine assignment (if they have coordinates)
|
||||
- ✅ Backward compatible during migration
|
||||
- Uses printer coordinates if available
|
||||
- Falls back to machine coordinates if printer coordinates not set
|
||||
- Includes printers without machine assignment (if they have coordinates)
|
||||
- Backward compatible during migration
|
||||
|
||||
---
|
||||
|
||||
@@ -482,51 +482,51 @@ ORDER BY p.printerid;
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Core Changes (Day 1)
|
||||
1. ✅ Add maptop/mapleft to printers table (COMPLETE)
|
||||
2. ⬜ Update printermap.asp query
|
||||
3. ⬜ Update saveprinter_direct.asp INSERT
|
||||
4. ⬜ Update saveprinter.asp UPDATE
|
||||
5. ⬜ Run data migration SQL script
|
||||
1. Add maptop/mapleft to printers table (COMPLETE)
|
||||
2. Update printermap.asp query
|
||||
3. Update saveprinter_direct.asp INSERT
|
||||
4. Update saveprinter.asp UPDATE
|
||||
5. Run data migration SQL script
|
||||
|
||||
### Phase 2: Form Updates (Day 2)
|
||||
1. ⬜ Add coordinate fields to addprinter.asp
|
||||
2. ⬜ Add coordinate fields to editprinter.asp
|
||||
3. ⬜ Test printer creation with coordinates
|
||||
4. ⬜ Test printer editing with coordinates
|
||||
1. Add coordinate fields to addprinter.asp
|
||||
2. Add coordinate fields to editprinter.asp
|
||||
3. Test printer creation with coordinates
|
||||
4. Test printer editing with coordinates
|
||||
|
||||
### Phase 3: Enhanced Features (Day 3)
|
||||
1. ⬜ Add map picker button functionality
|
||||
2. ⬜ Create api_machine_coordinates.asp
|
||||
3. ⬜ Update displayprinter.asp to show coordinates
|
||||
4. ⬜ Test full workflow
|
||||
1. Add map picker button functionality
|
||||
2. Create api_machine_coordinates.asp
|
||||
3. Update displayprinter.asp to show coordinates
|
||||
4. Test full workflow
|
||||
|
||||
### Phase 4: Testing & Documentation (Day 4)
|
||||
1. ⬜ Test with various printer scenarios
|
||||
2. ⬜ Update user documentation
|
||||
3. ⬜ Train users on new feature
|
||||
4. ⬜ Monitor for issues
|
||||
1. Test with various printer scenarios
|
||||
2. Update user documentation
|
||||
3. Train users on new feature
|
||||
4. Monitor for issues
|
||||
|
||||
---
|
||||
|
||||
## Testing Checklist
|
||||
|
||||
### Backward Compatibility
|
||||
- ⬜ Existing printers without coordinates still appear on map (using machine location)
|
||||
- ⬜ Machine dropdown still functions
|
||||
- ⬜ Printers assigned to machineid=1 can now have coordinates
|
||||
- Existing printers without coordinates still appear on map (using machine location)
|
||||
- Machine dropdown still functions
|
||||
- Printers assigned to machineid=1 can now have coordinates
|
||||
|
||||
### New Functionality
|
||||
- ⬜ Can add printer with custom coordinates
|
||||
- ⬜ Can edit printer coordinates
|
||||
- ⬜ Can leave coordinates blank (uses machine location)
|
||||
- ⬜ Multiple printers at same machine can have different positions
|
||||
- ⬜ Printers without machine assignment can appear on map
|
||||
- Can add printer with custom coordinates
|
||||
- Can edit printer coordinates
|
||||
- Can leave coordinates blank (uses machine location)
|
||||
- Multiple printers at same machine can have different positions
|
||||
- Printers without machine assignment can appear on map
|
||||
|
||||
### Edge Cases
|
||||
- ⬜ Printer with machineid=1 and no coordinates (should not appear on map)
|
||||
- ⬜ Printer with coordinates but machineid=1 (should appear on map)
|
||||
- ⬜ Invalid coordinate values (should be rejected)
|
||||
- ⬜ Null/empty coordinate values (should use machine location)
|
||||
- Printer with machineid=1 and no coordinates (should not appear on map)
|
||||
- Printer with coordinates but machineid=1 (should appear on map)
|
||||
- Invalid coordinate values (should be rejected)
|
||||
- Null/empty coordinate values (should use machine location)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ objConn.Open
|
||||
|
||||
**MANDATORY:** ALL database queries MUST use parameterization.
|
||||
|
||||
**❌ NEVER DO THIS:**
|
||||
** NEVER DO THIS:**
|
||||
```vbscript
|
||||
' WRONG - SQL Injection vulnerable
|
||||
machineId = Request.QueryString("machineid")
|
||||
@@ -106,7 +106,7 @@ strSQL = "SELECT * FROM machines WHERE machineid = " & machineId
|
||||
Set rs = objConn.Execute(strSQL)
|
||||
```
|
||||
|
||||
**✅ ALWAYS DO THIS:**
|
||||
** ALWAYS DO THIS:**
|
||||
```vbscript
|
||||
' CORRECT - Parameterized query
|
||||
machineId = GetSafeInteger("QS", "machineid", 0, 1, 999999)
|
||||
@@ -272,13 +272,13 @@ function validateForm() {
|
||||
|
||||
**MANDATORY:** ALL user-controlled output MUST be HTML-encoded.
|
||||
|
||||
**❌ NEVER DO THIS:**
|
||||
** NEVER DO THIS:**
|
||||
```vbscript
|
||||
<h5><%=rs("machinename")%></h5>
|
||||
<p><%Response.Write(rs("description"))%></p>
|
||||
```
|
||||
|
||||
**✅ ALWAYS DO THIS:**
|
||||
** ALWAYS DO THIS:**
|
||||
```vbscript
|
||||
<h5><%=Server.HTMLEncode(rs("machinename"))%></h5>
|
||||
<p><%Response.Write(Server.HTMLEncode(rs("description")))%></p>
|
||||
@@ -367,12 +367,12 @@ Call LogError(pageName, Err.Number, Err.Description, Request.ServerVariables("RE
|
||||
|
||||
**MANDATORY:** NEVER expose technical details to users.
|
||||
|
||||
**❌ WRONG:**
|
||||
** WRONG:**
|
||||
```vbscript
|
||||
Response.Write("Error: " & Err.Description)
|
||||
```
|
||||
|
||||
**✅ CORRECT:**
|
||||
** CORRECT:**
|
||||
```vbscript
|
||||
Response.Redirect("error.asp?code=DATABASE_ERROR")
|
||||
```
|
||||
|
||||
@@ -385,31 +385,31 @@ Response.Redirect(listUrl)
|
||||
### Unified Approach (Option 2) - RECOMMENDED
|
||||
|
||||
**Pros:**
|
||||
- ✅ Only 4 files to create (vs 12)
|
||||
- ✅ DRY - no code duplication
|
||||
- ✅ Easy to maintain - fix once, works for all
|
||||
- ✅ Easy to extend - add "UPS" or "Firewall" by just adding cases
|
||||
- ✅ Consistent UI across all infrastructure
|
||||
- ✅ Matches database design (vw_network_devices already unifies them)
|
||||
- Only 4 files to create (vs 12)
|
||||
- DRY - no code duplication
|
||||
- Easy to maintain - fix once, works for all
|
||||
- Easy to extend - add "UPS" or "Firewall" by just adding cases
|
||||
- Consistent UI across all infrastructure
|
||||
- Matches database design (vw_network_devices already unifies them)
|
||||
|
||||
**Cons:**
|
||||
- ⚠️ Slightly more complex logic (Select Case statements)
|
||||
- ⚠️ URLs less intuitive (type parameter required)
|
||||
- ⚠️ Harder to customize one type differently later
|
||||
- Slightly more complex logic (Select Case statements)
|
||||
- URLs less intuitive (type parameter required)
|
||||
- Harder to customize one type differently later
|
||||
|
||||
### Separate Pages Approach (Option 1)
|
||||
|
||||
**Pros:**
|
||||
- ✅ URLs cleaner (displayservers.asp vs displayinfrastructure.asp?type=server)
|
||||
- ✅ Simpler per-file logic (no branching)
|
||||
- ✅ Easy to customize one type differently
|
||||
- ✅ More explicit/clear what page does
|
||||
- URLs cleaner (displayservers.asp vs displayinfrastructure.asp?type=server)
|
||||
- Simpler per-file logic (no branching)
|
||||
- Easy to customize one type differently
|
||||
- More explicit/clear what page does
|
||||
|
||||
**Cons:**
|
||||
- ❌ 12 files instead of 4 (3x code duplication)
|
||||
- ❌ Bug fixes need to be applied 3 times
|
||||
- ❌ UI inconsistencies more likely
|
||||
- ❌ Adding new type = 4 more files
|
||||
- 12 files instead of 4 (3x code duplication)
|
||||
- Bug fixes need to be applied 3 times
|
||||
- UI inconsistencies more likely
|
||||
- Adding new type = 4 more files
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -16,10 +16,10 @@ This audit identifies **all files requiring changes** for two related database m
|
||||
|
||||
| Category | File Count | Priority |
|
||||
|----------|------------|----------|
|
||||
| **Core Data Cache** | 1 file | 🔴 CRITICAL (affects all dropdowns) |
|
||||
| **Vendor Queries** | 30 files | 🟡 HIGH |
|
||||
| **Infrastructure Pages** | 0 files | 🟢 NEW DEVELOPMENT REQUIRED |
|
||||
| **Network/Map Pages** | 3 files | 🟡 MEDIUM (may need infrastructure support) |
|
||||
| **Core Data Cache** | 1 file | CRITICAL (affects all dropdowns) |
|
||||
| **Vendor Queries** | 30 files | HIGH |
|
||||
| **Infrastructure Pages** | 0 files | NEW DEVELOPMENT REQUIRED |
|
||||
| **Network/Map Pages** | 3 files | MEDIUM (may need infrastructure support) |
|
||||
|
||||
**Total Files to Modify:** 31 existing files
|
||||
**New Files to Create:** ~9-12 files (infrastructure CRUD pages)
|
||||
@@ -302,7 +302,7 @@ After migration, use these IDs:
|
||||
## Part 4: Implementation Strategy
|
||||
|
||||
### Phase 1: Database Migration
|
||||
1. ✅ Migration scripts already created
|
||||
1. Migration scripts already created
|
||||
2. Run `add_infrastructure_vendor_model_support.sql`
|
||||
3. Run `refactor_vendor_types.sql`
|
||||
4. Verify both migrations successful
|
||||
@@ -466,17 +466,17 @@ Set rs = ExecuteParameterizedQuery(objConn, strSQL, Array(modelid, serialnumber,
|
||||
|
||||
| Priority | Files | Reason | Est. Hours |
|
||||
|----------|-------|--------|------------|
|
||||
| 🔴 P0 | includes/data_cache.asp | Affects all dropdowns | 2-3h |
|
||||
| 🔴 P1 | addvendor.asp, savevendor*.asp | UI changes required | 3-4h |
|
||||
| 🟡 P2 | Printer pages (7 files) | High usage feature | 4-5h |
|
||||
| 🟡 P2 | Machine pages (4 files) | High usage feature | 3-4h |
|
||||
| 🟡 P2 | PC pages (4 files) | High usage feature | 3-4h |
|
||||
| 🟢 P3 | Model management (3 files) | Backend only | 2-3h |
|
||||
| 🟢 P3 | Create server pages (4 files) | New development | 6-8h |
|
||||
| 🟢 P3 | Create switch pages (4 files) | New development | 4-6h |
|
||||
| 🟢 P3 | Create camera pages (4 files) | New development | 4-6h |
|
||||
| 🟢 P4 | Application pages (9 files) | Low vendor interaction | 4-6h |
|
||||
| 🟢 P4 | KB pages (2 files) | Minimal changes | 1-2h |
|
||||
| P0 | includes/data_cache.asp | Affects all dropdowns | 2-3h |
|
||||
| P1 | addvendor.asp, savevendor*.asp | UI changes required | 3-4h |
|
||||
| P2 | Printer pages (7 files) | High usage feature | 4-5h |
|
||||
| P2 | Machine pages (4 files) | High usage feature | 3-4h |
|
||||
| P2 | PC pages (4 files) | High usage feature | 3-4h |
|
||||
| P3 | Model management (3 files) | Backend only | 2-3h |
|
||||
| P3 | Create server pages (4 files) | New development | 6-8h |
|
||||
| P3 | Create switch pages (4 files) | New development | 4-6h |
|
||||
| P3 | Create camera pages (4 files) | New development | 4-6h |
|
||||
| P4 | Application pages (9 files) | Low vendor interaction | 4-6h |
|
||||
| P4 | KB pages (2 files) | Minimal changes | 1-2h |
|
||||
|
||||
**Total Estimated Time:** 36-54 hours
|
||||
|
||||
|
||||
@@ -75,13 +75,13 @@ ALTER TABLE vendors
|
||||
|
||||
## Benefits
|
||||
|
||||
✅ **Normalized**: Proper relational design
|
||||
✅ **Scalable**: Add new types without schema changes
|
||||
✅ **Simpler**: One type per vendor (one-to-many relationship)
|
||||
✅ **Cleaner Queries**: `JOIN vendortypes WHERE vendortypeid = 2`
|
||||
✅ **Better Reporting**: Easy to query "all vendors by type"
|
||||
✅ **Maintainable**: Type list managed in one place
|
||||
✅ **TBD Support**: Default type for unassigned/unknown vendors
|
||||
**Normalized**: Proper relational design
|
||||
**Scalable**: Add new types without schema changes
|
||||
**Simpler**: One type per vendor (one-to-many relationship)
|
||||
**Cleaner Queries**: `JOIN vendortypes WHERE vendortypeid = 2`
|
||||
**Better Reporting**: Easy to query "all vendors by type"
|
||||
**Maintainable**: Type list managed in one place
|
||||
**TBD Support**: Default type for unassigned/unknown vendors
|
||||
|
||||
---
|
||||
|
||||
@@ -399,13 +399,13 @@ This provides a safe, gradual migration path with easy rollback capability.
|
||||
See the TODO list for detailed tracking. High-level implementation order:
|
||||
|
||||
### Phase 1: Database Migration (Complete)
|
||||
- ✅ Migration script created: `/sql/refactor_vendor_types.sql`
|
||||
- ⏳ Run migration script on test database
|
||||
- ⏳ Verify vendortypes table populated with 7 types (TBD, Printer, PC, Machine, Server, Switch, Camera)
|
||||
- ⏳ Verify vendors.vendortypeid column added with proper foreign key
|
||||
- ⏳ Verify data migrated correctly from boolean flags
|
||||
- ⏳ Verify compatibility view `vw_vendors_with_types` works
|
||||
- ⏳ Verify isactive column fixed (CHAR(50) → BIT(1))
|
||||
- Migration script created: `/sql/refactor_vendor_types.sql`
|
||||
- Run migration script on test database
|
||||
- Verify vendortypes table populated with 7 types (TBD, Printer, PC, Machine, Server, Switch, Camera)
|
||||
- Verify vendors.vendortypeid column added with proper foreign key
|
||||
- Verify data migrated correctly from boolean flags
|
||||
- Verify compatibility view `vw_vendors_with_types` works
|
||||
- Verify isactive column fixed (CHAR(50) → BIT(1))
|
||||
|
||||
### Phase 2: Code Updates (31 files)
|
||||
Update all files to use new vendortypeid structure. Use one of these approaches:
|
||||
@@ -414,27 +414,27 @@ Update all files to use new vendortypeid structure. Use one of these approaches:
|
||||
- **Best**: Use helper functions from vendor_helpers.asp
|
||||
|
||||
**File Groups**:
|
||||
- ⏳ Data cache include (1 file) - **START HERE** (affects all dropdowns)
|
||||
- ⏳ Printer files (7 files)
|
||||
- ⏳ Machine files (4 files)
|
||||
- ⏳ PC files (4 files)
|
||||
- ⏳ Model/Vendor management (6 files)
|
||||
- ⏳ Application files (9 files)
|
||||
- ⏳ Knowledge base files (2 files)
|
||||
- ⏳ Search file (1 file - optional enhancement)
|
||||
- Data cache include (1 file) - **START HERE** (affects all dropdowns)
|
||||
- Printer files (7 files)
|
||||
- Machine files (4 files)
|
||||
- PC files (4 files)
|
||||
- Model/Vendor management (6 files)
|
||||
- Application files (9 files)
|
||||
- Knowledge base files (2 files)
|
||||
- Search file (1 file - optional enhancement)
|
||||
|
||||
### Phase 3: Testing
|
||||
- ⏳ Test vendor dropdowns in all add/edit forms
|
||||
- ⏳ Test filtering by vendor type works correctly
|
||||
- ⏳ Test data integrity (vendors show correct type)
|
||||
- ⏳ Test search functionality still works
|
||||
- ⏳ Verify no SQL errors in any page
|
||||
- Test vendor dropdowns in all add/edit forms
|
||||
- Test filtering by vendor type works correctly
|
||||
- Test data integrity (vendors show correct type)
|
||||
- Test search functionality still works
|
||||
- Verify no SQL errors in any page
|
||||
|
||||
### Phase 4: Cleanup (FINAL STEP - ONLY AFTER FULL VALIDATION)
|
||||
- ⏳ Create cleanup script to drop old boolean columns
|
||||
- ⏳ Run cleanup script to remove isprinter, ispc, ismachine, isserver, isswitch, iscamera
|
||||
- ⏳ Drop compatibility view if no longer needed
|
||||
- ⏳ Update documentation
|
||||
- Create cleanup script to drop old boolean columns
|
||||
- Run cleanup script to remove isprinter, ispc, ismachine, isserver, isswitch, iscamera
|
||||
- Drop compatibility view if no longer needed
|
||||
- Update documentation
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -454,14 +454,14 @@ SET SQL_SAFE_UPDATES = 1;
|
||||
|
||||
| Feature | Old (fields on machines) | New (warranty tables) |
|
||||
|---------|-------------------------|----------------------|
|
||||
| Multiple warranties | ❌ No | ✅ Yes |
|
||||
| Warranty history | ❌ No | ✅ Yes |
|
||||
| Renewal tracking | ❌ No | ✅ Yes |
|
||||
| Cost tracking | ❌ No | ✅ Yes |
|
||||
| Different vendors | ❌ No | ✅ Yes |
|
||||
| Auto-notifications | ❌ No | ✅ Yes |
|
||||
| Reporting | ⚠️ Limited | ✅ Comprehensive |
|
||||
| Audit trail | ❌ No | ✅ Yes |
|
||||
| Multiple warranties | No | Yes |
|
||||
| Warranty history | No | Yes |
|
||||
| Renewal tracking | No | Yes |
|
||||
| Cost tracking | No | Yes |
|
||||
| Different vendors | No | Yes |
|
||||
| Auto-notifications | No | Yes |
|
||||
| Reporting | Limited | Comprehensive |
|
||||
| Audit trail | No | Yes |
|
||||
|
||||
### 6.2 Example Use Cases
|
||||
|
||||
@@ -502,12 +502,12 @@ The machines table should NOT have warranty fields. All warranty information wil
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. ✅ Review warranty table design
|
||||
2. ⏳ Create warranty management views
|
||||
3. ⏳ Create data migration script for PC warranties
|
||||
4. ⏳ Update PC migration plan to use warranty tables
|
||||
5. ⏳ Create ASP pages for warranty management
|
||||
6. ⏳ Create warranty expiration notification system
|
||||
1. Review warranty table design
|
||||
2. Create warranty management views
|
||||
3. Create data migration script for PC warranties
|
||||
4. Update PC migration plan to use warranty tables
|
||||
5. Create ASP pages for warranty management
|
||||
6. Create warranty expiration notification system
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user