/**
 * PR Content Theme
 *
 * The Content Styling selection (style preset + typography/spacing/layout/colour
 * overrides) for a single PR content record.
 *
 * Why a separate collection rather than a field on each PR model: PR Content is
 * twelve content types across fourteen models (PressRelease, ExpertColumn,
 * NewsStory, …), several of which nest sub-schemas. Adding the same field to all
 * of them would mean editing every one of those files for a concern none of them
 * own, and would still leave any future content type without it. Keyed by
 * contentId instead, one collection covers every type — present and future —
 * and no existing PR schema changes at all.
 *
 * `theme` is Mixed on purpose: its shape is owned by the frontend
 * (PRThemeCustomization in modules/marketing/pr/utils/prThemeCustomization.ts),
 * which normalises and range-clamps every value on read. Mirroring that shape
 * here would be two definitions to keep in step, and the server never interprets
 * the theme — it only stores and returns it.
 */

import mongoose, { Schema, Document } from 'mongoose';

export interface IPRContentTheme extends Document {
  companyId: string;
  /** Id of the PR content record this styling belongs to, any content type. */
  contentId: string;
  theme: Record<string, unknown>;
  createdAt: Date;
  updatedAt: Date;
}

const PRContentThemeSchema = new Schema<IPRContentTheme>({
  companyId: { type: String, required: true, index: true },
  contentId: { type: String, required: true },
  theme: { type: Schema.Types.Mixed, default: {} },
}, {
  timestamps: true,
});

// One styling record per content item — the upsert in the route relies on this.
PRContentThemeSchema.index({ contentId: 1 }, { unique: true });

export const PRContentTheme = mongoose.model<IPRContentTheme>('PRContentTheme', PRContentThemeSchema);