-- Gold Jewellery Software - Void Sale & Void Purchase
-- Migration 009: lets a same-day mistake be undone safely rather than
-- editing a posted transaction in place (see README for why editing
-- posted Sales/Purchases directly is deliberately not supported).
USE gold_jewellery;

-- sales.void already exists (migration 002) — this adds its Purchase
-- counterpart, kept as its own permission rather than folded into
-- purchase.manage, matching how sales.void is separate from sales.create.
INSERT INTO permissions (slug, description) VALUES
 ('purchase.void', 'Cancel a posted purchase, if none of its items have moved yet')
ON DUPLICATE KEY UPDATE description = VALUES(description);

INSERT INTO role_permissions (role_id, permission_id)
SELECT r.id, p.id FROM roles r CROSS JOIN permissions p
WHERE r.name = 'ADMIN' AND p.slug = 'purchase.void'
ON DUPLICATE KEY UPDATE role_id = role_id;

-- Add PURCHASE_RETURN to stock_movements.movement_type, alongside the
-- existing SALE_RETURN, so voided-purchase items get a properly labeled
-- movement instead of being lumped under the generic ADJUSTMENT type.
-- Checked via information_schema first so this is safe to run more than
-- once and doesn't assume MySQL/MariaDB version-specific ALTER syntax.
SET @already_has_it := (
  SELECT COUNT(*) FROM information_schema.COLUMNS
  WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'stock_movements'
    AND COLUMN_NAME = 'movement_type' AND COLUMN_TYPE LIKE '%PURCHASE_RETURN%'
);
SET @sql := IF(@already_has_it = 0,
  'ALTER TABLE stock_movements MODIFY COLUMN movement_type ENUM(''PURCHASE'',''SALE'',''SALE_RETURN'',''PURCHASE_RETURN'',''TRANSFER_IN'',''TRANSFER_OUT'',''KARAGIR_ISSUE'',''KARAGIR_RECEIVE'',''ADJUSTMENT'',''MELTING'') NOT NULL',
  'SELECT 1'
);
PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;