Feature/newsletter page

[varunsiravuri]

opensox.1.mov

This PR introduces a comprehensive newsletter/blog system for Opensox with:

Chronological Organization: All newsletters and articles are automatically organized by month and year, with the most recent posts shown first for easy discovery.

Rich Content Support: Each newsletter can now include formatted text, links, and images, allowing for visually engaging and informative content.

Content Management (Admin Only): Created /admin/newsletter route and supporting logic, enabling team members to easily add, edit, or remove newsletters/blogs directly via a secure admin interface.

Newsletter Listing Page: Added a public listing where users can browse all newsletters, always ordered with the latest on top.

Minimal, Readable Formatting: Ensured that each newsletter is easy to read and visually uncluttered, focusing on an accessible experience.

Implementation Approach
Introduced a new Newsletter model/schema with support for all required content fields (text, images, links, metadata for date/month).

Developed the /admin/newsletter route (protected, team-only), which streamlines the process for adding, updating, and managing newsletters in a code-driven and UI-assisted manner.

Built a frontend component for listing all newsletters with date grouping and a detail view for individual posts.

Restricted newsletter/blog management strictly to admins/team via authentication checks.

Added documentation and code comments so future contributors can extend or use this feature easily.

Testing & Demo
Video recording/demo: Attached to this PR for clarity.

Tested locally: Adding, editing, viewing, and chronological listing of newsletters as both admin and regular user.

Confirmed rich media rendering and responsive layouts.

How to Use
Team/admins: Visit /admin/newsletter to add or manage content.

All users: View all newsletters via the dedicated listing page, with articles grouped by month and year, supporting text, links, and images.

Summary by CodeRabbit

• New Features

  • Newsletter management UI: dashboard with search, filtering, archive and detail pages with Markdown rendering.
  • Admin panel to compose and generate newsletter entries and copy-ready code.

• Documentation

  • Added Newsletter Management guide with quick start and example entry.

• Chores

  • Added react-markdown and remark-gfm for rendering.
  • Removed example environment template; .env.example is now ignored by Docker build context.

[vercel]

@varunsiravuri is attempting to deploy a commit to the AJEET PRATAP SINGH's projects Team on Vercel.

A member of the Team first needs to authorize it.

[cla-assistant]

All committers have signed the CLA.

[coderabbitai]

Walkthrough

This PR adds a newsletter management feature (data, admin UI, listing and detail pages, Markdown renderer, CMS), adds react-markdown/remark-gfm, updates auth config to read providers from env, refactors Razorpay client to a lazy singleton, and removes an apps/api .env.example plus a .dockerignore negation.

Changes

Cohort / File(s)	Summary
Razorpay lazy init apps/api/src/clients/razorpay.ts, apps/api/src/services/payment.service.ts	Change from module-level eager Razorpay instance to a lazily-initialized singleton via getRazorpayInstance(); payment service now calls the getter at runtime.
Newsletter data & docs apps/web/src/data/newsletters.ts, apps/web/src/data/NEWSLETTER_README.md	New Newsletter interface, sample newsletters array, and helper functions (getNewsletterBySlug, getNewslettersByDate, getAllNewsletters, formatDate, getMonthYearLabel) plus README describing usage.
Admin UI & generator apps/web/src/app/(main)/admin/newsletter/_components/NewsAdmin.tsx, apps/web/src/app/(main)/admin/newsletter/page.tsx	New client-side admin page with hardcoded TEAM_EMAILS gate and NewsAdmin component to build newsletter object code snippets, copy/reset flows.
Dashboard listing & detail apps/web/src/app/(main)/dashboard/newsletter/page.tsx, apps/web/src/app/(main)/dashboard/newsletter/[slug]/page.tsx	New newsletter listing with search, year/month grouping, archive modal; detail page renders newsletter content (Markdown) and metadata.
Markdown renderer apps/web/src/components/newsletter/MarkdownRenderer.tsx	New ReactMarkdown-based renderer using remark-gfm with custom element renderers and Tailwind classes.
Sidebar nav apps/web/src/components/dashboard/Sidebar.tsx	Sidebar updated to include a Newsletter route (/dashboard/newsletter) and icon imports adjusted.
Deps & auth config apps/web/package.json, apps/web/src/lib/auth/config.ts	Added react-markdown and remark-gfm; auth config updated to sanitize env vars and dynamically enable Google/GitHub providers with improved diagnostics on sign-in errors.
Docker/env/docs .dockerignore, apps/api/.env.example, README.md	Removed negation from .dockerignore so .env.example is ignored; deleted apps/api/.env.example; added Newsletter Management Quick Start and example to README.
Newsletter CMS tool apps/web/src/tools/newsletter-cms/index.html	New HTML-based lightweight CMS UI for listing, creating, editing, and deleting newsletters via a storage API.

Sequence Diagram(s)

sequenceDiagram
    participant Admin as Admin User
    participant AdminPage as /admin/newsletter
    participant NewsAdmin as NewsAdmin
    participant Data as newsletters.ts
    participant Dashboard as /dashboard/newsletter
    participant Reader as Reader User

    rect rgb(224,240,255)
      Admin->>AdminPage: visit page
      AdminPage->>AdminPage: auth check (TEAM_EMAILS)
      AdminPage->>NewsAdmin: render form
      Admin->>NewsAdmin: fill form & generate code
      NewsAdmin->>Admin: show generated snippet (copy)
      Admin->>Data: paste snippet into `newsletters` array
    end

    rect rgb(240,255,224)
      Reader->>Dashboard: visit listing
      Dashboard->>Data: getAllNewsletters/getNewslettersByDate
      Data-->>Dashboard: newsletter list grouped/sorted
      Dashboard->>Reader: render cards
      Reader->>Dashboard: open /[slug]
      Dashboard->>Data: getNewsletterBySlug
      Data-->>Dashboard: newsletter
      Dashboard->>Reader: render Markdown via MarkdownRenderer
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Files/areas to focus review on:

• apps/api/src/clients/razorpay.ts — concurrency and error handling in lazy init
• apps/api/src/services/payment.service.ts — ensure error mapping unchanged and instance usage safe
• apps/web/src/data/newsletters.ts — date parsing, sorting, and sample data correctness
• apps/web/src/lib/auth/config.ts — env sanitization and provider enabling logic
• MarkdownRenderer and pages — verify XSS-safe rendering and link target/rel behavior

Possibly related PRs

• auto onboarding #131 — also touches Razorpay client and payment flow; may conflict in client initialization/export shape.
• v2-dashboard: created a new ui for the dashboard #116  #125 — modifies Sidebar and related web deps; likely overlaps with navigation/dependency changes.
• [feat] add sheet and revamp dashboard #165 — also updates Sidebar entries/icons; review for duplicate edits.

Poem

🐇 I hop and type a newsletter seed,

Fields and Markdown, ready to feed,
Admin crafts code, readers delight,
From draft to dashboard, pixels take flight,
A rabbit's cheer for content and speed!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 54.55% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check	❓ Inconclusive	The title 'Feature/newsletter page' partially relates to the changeset. It refers to a real aspect—the newsletter feature—but is overly broad and generic, not capturing the main scope of the changes (comprehensive newsletter system with admin management, frontend pages, data models, and supporting utilities).	Consider a more specific title that captures the core change, such as 'Add newsletter management system with admin and public views' or 'Implement newsletter feature with chronological listing and admin controls'.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 34cb10b and 4d0ade1.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (2)

• apps/web/package.json (1 hunks)
• apps/web/src/components/dashboard/Sidebar.tsx (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• apps/web/package.json
• apps/web/src/components/dashboard/Sidebar.tsx

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 10

🧹 Nitpick comments (11)

apps/web/src/lib/auth/config.ts (1)

60-64: Consider failing fast if no providers are configured.

When no OAuth providers are configured, the server continues to start but authentication will be completely broken. This could lead to confusing runtime errors.

Consider throwing an error to prevent the server from starting with invalid configuration:

 if (providers.length === 0) {
-  console.error(
-    "No OAuth providers configured. Please set at least one provider's credentials in .env.local"
-  );
+  throw new Error(
+    "No OAuth providers configured. Please set at least one provider's credentials in .env.local"
+  );
 }

This provides immediate feedback during development rather than allowing runtime auth failures.

apps/api/src/clients/razorpay.ts (1)

5-35: LGTM with minor concurrency consideration.

The lazy initialization implementation is well-structured with proper environment variable validation and clear error messages. The singleton pattern ensures only one instance is created across the application lifecycle.

Minor note on potential race condition:
While unlikely in Node.js due to the single-threaded event loop, if multiple async calls to getRazorpayInstance() occur simultaneously before the first initialization completes, there's a theoretical possibility of creating multiple instances. However, given that:

1. The initialization is synchronous (no await in the function)
2. Node.js processes code in the event loop serially
3. The assignment and check are atomic operations

This is not a practical concern for this implementation.

If you want to be absolutely certain about thread safety in all edge cases, you could add a simple initialization lock:

let rz_instance: Razorpay | null = null;
let isInitializing = false;

export function getRazorpayInstance(): Razorpay {
  if (rz_instance) {
    return rz_instance;
  }

  if (isInitializing) {
    throw new Error("Razorpay instance is already being initialized");
  }

  isInitializing = true;
  
  // ... rest of initialization code ...
  
  isInitializing = false;
  return rz_instance;
}

However, this is purely optional and likely unnecessary for this use case.

README.md (1)

270-298: Clear documentation for newsletter management.

The Quick Start guide and example are helpful. Consider making the path more explicit in step 4: apps/web/src/data/newsletters.ts instead of just data/newsletters.ts for clarity from the repository root.

apps/web/src/components/newsletter/MarkdownRenderer.tsx (1)

1-86: Well-implemented Markdown renderer with proper styling.

The component provides comprehensive custom renderers for Markdown elements with appropriate theme styling and security attributes (noopener noreferrer for links).

Consider improving type safety on line 61 by defining a proper type for the code component props instead of any:

-          code: ({ node, inline, ...props }: any) =>
+          code: ({ node, inline, className, children, ...props }: { node?: any; inline?: boolean; className?: string; children?: React.ReactNode }) =>

apps/web/src/tools/newsletter-cms/index.html (1)

7-9: Consider upgrading to React 18 createRoot API.

The code uses the deprecated ReactDOM.render API. React 18 recommends using ReactDOM.createRoot instead.

Replace the render calls with:

   <script crossorigin src="https://unpkg.com/react@18/umd/react.production.min.js"></script>
   <script crossorigin src="https://unpkg.com/react-dom@18/umd/react-dom.production.min.js"></script>

And update line 249:

-ReactDOM.render(<NewsletterCMS />, document.getElementById('root'));
+const root = ReactDOM.createRoot(document.getElementById('root'));
+root.render(<NewsletterCMS />);

apps/web/src/app/(main)/admin/newsletter/_components/NewsAdmin.tsx (1)

28-32: Replace alert() with proper validation UI.

Using alert() for validation errors provides poor UX and blocks the UI. Modern web apps should display inline validation messages.

Consider adding error state and displaying validation messages inline:

+const [errors, setErrors] = useState<{title?: string; content?: string}>({});
+
 const generateCode = () => {
+  const newErrors: typeof errors = {};
   if (!formData.title || !formData.content) {
-    alert('Please fill in Title and Content');
+    if (!formData.title) newErrors.title = 'Title is required';
+    if (!formData.content) newErrors.content = 'Content is required';
+    setErrors(newErrors);
     return;
   }
+  setErrors({});

Then display errors near the relevant input fields with appropriate styling.

apps/web/src/app/(main)/dashboard/newsletter/page.tsx (3)

277-285: Redundant conditional check.

Line 277 checks if (newsletter.issueNumber), but line 279 checks the same condition again inside the block. The outer check is unnecessary.

Simplify the conditional:

-                      {(newsletter.issueNumber) && (
-                        <div className="flex items-center gap-2">
-                          {newsletter.issueNumber && (
-                            <span className="text-xs text-ox-gray">
-                              issue {newsletter.issueNumber}
-                            </span>
-                          )}
-                        </div>
-                      )}
+                      {newsletter.issueNumber && (
+                        <div className="flex items-center gap-2">
+                          <span className="text-xs text-ox-gray">
+                            issue {newsletter.issueNumber}
+                          </span>
+                        </div>
+                      )}

---

1-1: Consider converting to Server Component for better performance.

This component uses "use client" but most of the logic could run server-side. Server Components provide:

• Faster initial page load (no JS hydration needed for static content)
• Better SEO (fully rendered HTML)
• Reduced client bundle size
• Server-side data fetching

The interactive portions (search, filters, modal) could be isolated into smaller client components.

Refactor structure:

1. Make the main page a Server Component
2. Extract <SearchAndFilters> as a client component
3. Extract <ArchiveModal> as a client component
4. Pass filtered data as props

This follows Next.js 15 best practices for App Router.

---

31-52: Inefficient repeated filtering in getMonthsForYear.

This function filters the entire newsletters array twice for each month: once to find months (line 35) and again to count newsletters (lines 45-49). This creates O(n²) complexity.

Optimize by filtering once:

 const getMonthsForYear = (year: number) => {
-  const months = Array.from(
-    new Set(
-      allNewsletters
-        .filter((n) => new Date(n.publishedAt).getFullYear() === year)
-        .map((n) => new Date(n.publishedAt).getMonth())
-    )
-  ).sort((a, b) => b - a);
-
-  return months.map((m) => {
-    const date = new Date(year, m);
-    return {
-      value: `${year}-${String(m + 1).padStart(2, "0")}`,
-      label: date.toLocaleString("default", { month: "long" }),
-      count: allNewsletters.filter(
-        (n) =>
-          new Date(n.publishedAt).getFullYear() === year &&
-          new Date(n.publishedAt).getMonth() === m
-      ).length,
-    };
-  });
+  const yearNewsletters = allNewsletters.filter(
+    (n) => new Date(n.publishedAt).getFullYear() === year
+  );
+  
+  const monthCounts = new Map<number, number>();
+  yearNewsletters.forEach((n) => {
+    const month = new Date(n.publishedAt).getMonth();
+    monthCounts.set(month, (monthCounts.get(month) || 0) + 1);
+  });
+  
+  return Array.from(monthCounts.entries())
+    .sort(([a], [b]) => b - a)
+    .map(([m, count]) => {
+      const date = new Date(year, m);
+      return {
+        value: `${year}-${String(m + 1).padStart(2, "0")}`,
+        label: date.toLocaleString("default", { month: "long" }),
+        count,
+      };
+    });
 };

apps/web/src/data/newsletters.ts (2)

1-13: Consider adding optional fields to interface.

The Newsletter interface is well-structured, but consider adding fields that would be useful for a real CMS:

 export interface Newsletter {
   id: string;
   slug: string;
   title: string;
   description?: string;
   content: string;
   publishedAt: Date;
   author?: string;
   image?: string;
   issueNumber?: string;
   readTime?: number;
+  status?: 'draft' | 'published' | 'archived';
+  createdAt?: Date;
+  updatedAt?: Date;
+  createdBy?: string;  // User ID who created it
+  tags?: string[];     // For categorization
 }

These fields support common CMS workflows like drafts, audit trails, and content organization.

---

1959-1981: Optimize getNewslettersByDate to avoid redundant sorting.

The function sorts each group individually after grouping, but since newsletters is unsorted, this is necessary. However, if you sort newsletters first, you can avoid sorting each group.

 export function getNewslettersByDate(): Record<string, Newsletter[]> {
   const grouped: Record<string, Newsletter[]> = {};
+  
+  // Sort newsletters once upfront (latest first)
+  const sortedNewsletters = [...newsletters].sort(
+    (a, b) => new Date(b.publishedAt).getTime() - new Date(a.publishedAt).getTime()
+  );

-  newsletters.forEach((newsletter) => {
+  sortedNewsletters.forEach((newsletter) => {
     const date = new Date(newsletter.publishedAt);
     const key = `${date.getFullYear()}-${String(date.getMonth() + 1).padStart(2, "0")}`;
     
     if (!grouped[key]) {
       grouped[key] = [];
     }
     grouped[key].push(newsletter);
   });

-  // sort each group by date (latest first)
-  Object.keys(grouped).forEach((key) => {
-    grouped[key].sort(
-      (a, b) =>
-        new Date(b.publishedAt).getTime() - new Date(a.publishedAt).getTime()
-    );
-  });
-
   return grouped;
 }

This changes from O(n log n) per group to O(n log n) once, improving performance.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 97e699a and 34cb10b.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (16)

• .dockerignore (1 hunks)
• README.md (1 hunks)
• apps/api/.env.example (0 hunks)
• apps/api/src/clients/razorpay.ts (1 hunks)
• apps/api/src/services/payment.service.ts (2 hunks)
• apps/web/package.json (1 hunks)
• apps/web/src/app/(main)/admin/newsletter/_components/NewsAdmin.tsx (1 hunks)
• apps/web/src/app/(main)/admin/newsletter/page.tsx (1 hunks)
• apps/web/src/app/(main)/dashboard/newsletter/[slug]/page.tsx (1 hunks)
• apps/web/src/app/(main)/dashboard/newsletter/page.tsx (1 hunks)
• apps/web/src/components/dashboard/Sidebar.tsx (2 hunks)
• apps/web/src/components/newsletter/MarkdownRenderer.tsx (1 hunks)
• apps/web/src/data/NEWSLETTER_README.md (1 hunks)
• apps/web/src/data/newsletters.ts (1 hunks)
• apps/web/src/lib/auth/config.ts (2 hunks)
• apps/web/src/tools/newsletter-cms/index.html (1 hunks)

💤 Files with no reviewable changes (1)

• apps/api/.env.example

🧰 Additional context used

🧬 Code graph analysis (4)

apps/web/src/app/(main)/dashboard/newsletter/[slug]/page.tsx (2)

apps/web/src/data/newsletters.ts (2)

• getNewsletterBySlug (1954-1956)
• formatDate (1984-1990)

apps/web/src/components/newsletter/MarkdownRenderer.tsx (1)

• MarkdownRenderer (11-85)

apps/web/src/app/(main)/admin/newsletter/page.tsx (1)

apps/web/src/app/(main)/admin/newsletter/_components/NewsAdmin.tsx (1)

• NewsletterAdmin (4-232)

apps/web/src/app/(main)/dashboard/newsletter/page.tsx (1)

apps/web/src/data/newsletters.ts (4)

• getAllNewsletters (2000-2005)
• formatDate (1984-1990)
• newsletters (16-1951)
• getMonthYearLabel (1993-1997)

apps/api/src/services/payment.service.ts (1)

apps/api/src/clients/razorpay.ts (1)

• getRazorpayInstance (9-35)

🪛 LanguageTool

apps/web/src/data/NEWSLETTER_README.md

[uncategorized] ~73-~73: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...YYY-MM-DD")` format 4. Content: Use markdown for formatting. The content will be aut...

(MARKDOWN_NNP)

---

[uncategorized] ~101-~101: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ... to view the full content 5. Check that markdown formatting renders correctly ## Best P...

(MARKDOWN_NNP)

🪛 markdownlint-cli2 (0.18.1)

apps/web/src/data/NEWSLETTER_README.md

81-81: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🔇 Additional comments (13)

.dockerignore (1)

16-18: Verify that environment variable documentation is updated elsewhere.

The removal of the negation pattern for .env.example (line 18) combined with the deletion of apps/api/.env.example from the repository means developers can no longer reference .env.example to discover required environment variables. Ensure that setup documentation (README, contributing guide, or docs) has been updated with clear environment variable guidance to maintain developer experience.

apps/web/src/lib/auth/config.ts (2)

6-20: Well-implemented helper function.

The getEnvVar helper correctly handles common environment variable edge cases including whitespace trimming and quote removal. The logic is safe with proper guards before slicing.

---

85-99: Good improvement to error diagnostics.

The enhanced error handling provides helpful feedback when the backend API is unreachable. The connection error detection using ECONNREFUSED and "fetch failed" patterns covers common failure scenarios, and the security posture is maintained by denying sign-in on any error.

apps/api/src/services/payment.service.ts (2)

1-1: LGTM: Import updated for lazy initialization pattern.

The import change correctly uses the new factory function instead of a direct Razorpay instance.

---

77-77: Refactoring verified as intentional and complete.

The migration from direct export to lazy initialization pattern is properly implemented. The old rz_instance export has been removed from apps/api/src/clients/razorpay.ts, and the codebase contains no remaining imports of the old pattern. All usages have been successfully migrated to getRazorpayInstance(). The singleton implementation correctly avoids creating multiple instances despite per-order calls.

apps/api/src/clients/razorpay.ts (1)

3-3: LGTM: Private nullable variable for lazy initialization.

The variable is correctly scoped as private and initialized to null to support the lazy initialization pattern.

apps/web/src/components/dashboard/Sidebar.tsx (2)

20-20: LGTM! Icon import added correctly.

---

39-43: LGTM! Newsletter sidebar entry added.

The new sidebar entry follows the existing pattern and is properly configured with path, label, and icon.

apps/web/src/data/NEWSLETTER_README.md (1)

1-114: Excellent documentation for newsletter management.

This comprehensive guide provides clear instructions, examples, file structure overview, testing steps, and best practices. The documentation will be valuable for contributors adding newsletters.

apps/web/src/tools/newsletter-cms/index.html (1)

1-254: Clarify the purpose of this standalone HTML CMS tool.

This standalone HTML file seems disconnected from the main Next.js application and references an undefined window.storage API. The PR description mentions an admin interface at /admin/newsletter (which exists in apps/web/src/app/(main)/admin/newsletter/page.tsx), making the purpose of this standalone tool unclear.

Is this file:

1. A prototype/example that should be removed?
2. A tool meant to be served separately?
3. Missing integration with the main app?

If it's meant to be used, document how to access it and ensure the window.storage API is properly defined.

apps/web/src/app/(main)/dashboard/newsletter/[slug]/page.tsx (1)

40-102: Well-structured newsletter detail view.

The component properly handles the not-found case, displays all newsletter metadata (issue number, title, description, date, author, read time), and renders Markdown content using the MarkdownRenderer component. The UI is clean and accessible with proper semantic HTML.

apps/web/package.json (1)

36-39: Versions confirmed as latest stable.

react-markdown 10.1.0 and remark-gfm 4.0.1 are indeed the latest stable versions. The dependencies in package.json are appropriate and up-to-date.

apps/web/src/data/newsletters.ts (1)

1954-1956: LGTM: Helper functions are well-implemented.

The helper functions (getNewsletterBySlug, formatDate, getMonthYearLabel, getAllNewsletters) are straightforward, well-named, and handle their responsibilities correctly. They work well with the current data structure.

Once you migrate to a database, these functions can be adapted to query the database instead of filtering arrays.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Major architectural concern: Manual workflow doesn't scale.

This component generates code snippets for manual copy-paste into source files rather than persisting data to a database. This approach has significant limitations:

• No version control or audit trail for content changes
• Deployment required for every newsletter update
• Error-prone manual ID management
• No editing capability for existing newsletters
• Security risk if admins accidentally paste malicious content
• Doesn't support the PR objectives of "Admin content management" with creation, editing, and deletion

For a production newsletter system, consider implementing:

• Server actions or API routes for CRUD operations
• Database storage (e.g., PostgreSQL, MongoDB)
• Proper authentication checks server-side
• Rich text editor for content
• Preview functionality
• Draft/publish workflow

Would you like me to help design a proper database-backed newsletter management system with Next.js server actions?

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Slug generation doesn't handle edge cases.

The generateSlug() function could produce empty strings or colliding slugs in edge cases (e.g., titles with only special characters, or identical titles).

Add validation and uniqueness checks:

 const generateSlug = (title: string) => {
-  return title
+  const slug = title
     .toLowerCase()
     .replace(/[^a-z0-9]+/g, '-')
     .replace(/(^-|-$)/g, '');
+  
+  if (!slug) {
+    throw new Error('Title must contain at least one alphanumeric character');
+  }
+  
+  return slug;
 };

For production, also check slug uniqueness against existing newsletters.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const generateSlug = (title: string) => {
	return title
	.toLowerCase()
	.replace(/[^a-z0-9]+/g, '-')
	.replace(/(^-|-$)/g, '');
	};
	const generateSlug = (title: string) => {
	const slug = title
	.toLowerCase()
	.replace(/[^a-z0-9]+/g, '-')
	.replace(/(^-|-$)/g, '');
	if (!slug) {
	throw new Error('Title must contain at least one alphanumeric character');
	}
	return slug;
	};

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Hard-coded ID creates maintenance burden.

The getNextId() function returns a hard-coded value that must be manually updated after each newsletter addition. This is error-prone and can lead to ID collisions if forgotten.

Consider one of these approaches:

• Auto-increment IDs in a database
• UUID generation: crypto.randomUUID()
• Timestamp-based IDs

Example with UUID:

-const getNextId = () => {
-  return "18"; // Update this to the next ID number
-};
+const getNextId = () => {
+  return crypto.randomUUID();
+};

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In apps/web/src/app/(main)/admin/newsletter/_components/NewsAdmin.tsx around
lines 24 to 26, getNextId() currently returns a hard-coded "18" causing manual
updates and possible collisions; replace it with an automatic ID generator
(e.g., return crypto.randomUUID() or Date.now().toString()) and ensure any
required imports or browser API usage is supported (or fallback to a small UUID
helper) so new newsletters get unique IDs without manual intervention.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Potential XSS vulnerability in generated code.

The generated code doesn't escape special characters in user input. If an admin enters quotes, backticks, or other special characters in form fields, it could break the JavaScript syntax or create injection risks when pasted into source code.

Add proper escaping for string values:

+const escapeString = (str: string) => {
+  return str.replace(/\\/g, '\\\\')
+           .replace(/`/g, '\\`')
+           .replace(/\$/g, '\\$');
+};
+
 const generateCode = () => {
   // ... validation ...
   
   const code = `{
   id: "${getNextId()}",
   slug: "${slug}",
-  title: "${formData.title}",${formData.description ? `
-  description: "${formData.description}",` : ''}
-  content: \`${formData.content}\`,
+  title: "${escapeString(formData.title)}",${formData.description ? `
+  description: "${escapeString(formData.description)}",` : ''}
+  content: \`${escapeString(formData.content)}\`,

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Server Components are preferred in Next.js 15 App Router.

This page uses "use client" but only needs client-side code for the NewsletterAdmin component (which is already marked as client). The authentication check should be done server-side, allowing this page component to be a Server Component.

See the previous comment for the recommended server-side authentication pattern.

🤖 Prompt for AI Agents

In apps/web/src/app/(main)/admin/newsletter/page.tsx around line 1, the file is
marked "use client" which forces the entire page to be a Client Component even
though only the NewsletterAdmin child needs client behavior; remove the "use
client" directive so the page becomes a Server Component, perform the
authentication check on the server (using the project’s server-side auth pattern
referenced in the prior comment), and keep NewsletterAdmin as a client component
for interactive UI—ensure any client-only hooks or browser APIs remain inside
NewsletterAdmin or other client components and that server-side props/auth
results are passed down as needed.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Replace client-side auth with server-side protection.

The hardcoded email check (line 18: const userEmail = "ajeet@opensox.ai") and client-side authorization bypass all real authentication. This is a critical security vulnerability as anyone can:

1. View the source code and see the hardcoded email
2. Modify client-side JavaScript to bypass the check
3. Directly access the admin functionality

Next.js 15 with the App Router should use server-side authentication.

Replace this client-side check with proper server-side authentication. Here's the recommended approach:

import { getServerSession } from "next-auth";
import { redirect } from "next/navigation";
import NewsletterAdmin from "./_components/NewsAdmin";

const TEAM_EMAILS = [
  "ajeet@opensox.ai",
  "team@opensox.ai",
];

export default async function NewsletterAdminPage() {
  const session = await getServerSession();
  
  if (!session?.user?.email || !TEAM_EMAILS.includes(session.user.email)) {
    redirect("/dashboard");
  }

  return <NewsletterAdmin />;
}

This ensures:

• Authentication is checked server-side before rendering
• The check cannot be bypassed by client-side manipulation
• Proper integration with NextAuth.js (already in your stack)

🤖 Prompt for AI Agents

In apps/web/src/app/(main)/admin/newsletter/page.tsx around lines 16 to 26, the
file contains a client-side useEffect with a hardcoded userEmail which bypasses
real auth; replace this with server-side protection by converting the page to an
async server component that imports getServerSession from next-auth and redirect
from next/navigation, move TEAM_EMAILS into the module scope, call
getServerSession() at the top of the component, and if the session is missing or
session.user.email is not in TEAM_EMAILS call redirect("/dashboard"); otherwise
return the NewsletterAdmin component; remove the client-side useEffect and
hardcoded email entirely.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Refactor to async Server Component for Next.js 15 best practices.

In Next.js 15, route params are async and should be awaited in Server Components. This page uses "use client" with React.use(), which works but is not optimal. Since the page only accesses static data (no client-side interactivity needed at the page level), it should be a Server Component.

Refactor to an async Server Component:

-"use client";
-
 import React from "react";
-import { use } from "react";
 import Link from "next/link";
 import { getNewsletterBySlug, formatDate } from "@/data/newsletters";
 import { MarkdownRenderer } from "@/components/newsletter/MarkdownRenderer";
 import { ArrowLeftIcon, CalendarIcon, ClockIcon } from "@heroicons/react/24/outline";

 interface NewsletterDetailPageProps {
   params: Promise<{
     slug: string;
   }>;
 }

-export default function NewsletterDetailPage({
+export default async function NewsletterDetailPage({
   params,
 }: NewsletterDetailPageProps) {
-  const { slug } = use(params);
+  const { slug } = await params;
   const newsletter = getNewsletterBySlug(slug);

Benefits:

• Better performance (less JavaScript sent to client)
• Improved SEO (content rendered server-side)
• Aligns with Next.js 15 best practices
• MarkdownRenderer can remain a client component for interactivity

Based on Next.js 15 documentation in the library context provided.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	"use client";
	import React from "react";
	import { use } from "react";
	import Link from "next/link";
	import { getNewsletterBySlug, formatDate } from "@/data/newsletters";
	import { MarkdownRenderer } from "@/components/newsletter/MarkdownRenderer";
	import { ArrowLeftIcon, CalendarIcon, ClockIcon } from "@heroicons/react/24/outline";
	interface NewsletterDetailPageProps {
	params: Promise<{
	slug: string;
	}>;
	}
	export default function NewsletterDetailPage({
	params,
	}: NewsletterDetailPageProps) {
	const { slug } = use(params);
	const newsletter = getNewsletterBySlug(slug);
	import React from "react";
	import Link from "next/link";
	import { getNewsletterBySlug, formatDate } from "@/data/newsletters";
	import { MarkdownRenderer } from "@/components/newsletter/MarkdownRenderer";
	import { ArrowLeftIcon, CalendarIcon, ClockIcon } from "@heroicons/react/24/outline";
	interface NewsletterDetailPageProps {
	params: Promise<{
	slug: string;
	}>;
	}
	export default async function NewsletterDetailPage({
	params,
	}: NewsletterDetailPageProps) {
	const { slug } = await params;
	const newsletter = getNewsletterBySlug(slug);

🤖 Prompt for AI Agents

In apps/web/src/app/(main)/dashboard/newsletter/[slug]/page.tsx around lines
1-20, the page is currently a client component using "use client" and
use(params) for route params; refactor it into an async Server Component by
removing the "use client" directive, change the component to "export default
async function NewsletterDetailPage({ params }: NewsletterDetailPageProps)",
await the incoming params (const { slug } = await params) and call/get the
newsletter data server-side (await getNewsletterBySlug(slug) if it returns a
promise), keep MarkdownRenderer as a client component (no changes needed) and
return the same JSX; this will render on the server, reduce client JS, and align
with Next.js 15 best practices.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Unused input field with no state binding.

The search input in the "all issues" section of the archive modal is not connected to any state. It renders but doesn't filter the newsletter list below it.

Either remove this input or implement the filtering functionality:

Option 1: Remove unused input

-            <div className="relative">
-              <MagnifyingGlassIcon className="size-4 absolute left-3 top-1/2 -translate-y-1/2 text-ox-gray" />
-              <input
-                type="text"
-                placeholder="filter by title or topic"
-                className="w-full pl-10 pr-4 py-2 bg-[#121214] border border-[#1a1a1d] rounded-lg text-ox-white placeholder:text-ox-gray text-sm focus:outline-none focus:border-ox-purple"
-              />
-            </div>

Option 2: Implement filtering

+const [archiveSearch, setArchiveSearch] = useState("");
+
+const filteredArchiveNewsletters = allNewsletters.filter(n =>
+  n.title.toLowerCase().includes(archiveSearch.toLowerCase())
+);
+
 // In JSX:
 <input
   type="text"
   placeholder="filter by title or topic"
+  value={archiveSearch}
+  onChange={(e) => setArchiveSearch(e.target.value)}
   className="..."
 />
 <div className="space-y-2 max-h-48 overflow-y-auto">
-  {allNewsletters.map((newsletter) => (
+  {filteredArchiveNewsletters.map((newsletter) => (

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical architectural issue: Static data contradicts PR objectives.

The PR objectives state "Admin content management: new protected /admin/newsletter route and supporting logic for team-only creation, editing, and deletion of newsletters." However, this implementation stores 1,900+ lines of static newsletter content in source code, which:

• Cannot be edited through the admin interface (NewsAdmin only generates code for manual pasting)
• Cannot be deleted without code changes
• Requires redeployment for every content update
• No versioning or audit trail for content changes
• Doesn't scale beyond a small number of newsletters
• Blocks non-technical team members from managing content

This is not a sustainable CMS solution.

For a production newsletter system aligned with the PR objectives, you need:

Database Schema (Prisma example):

model Newsletter {
  id           String   @id @default(uuid())
  slug         String   @unique
  title        String
  description  String?
  content      String   @db.Text
  publishedAt  DateTime
  author       String?
  image        String?
  issueNumber  String?
  readTime     Int?
  createdAt    DateTime @default(now())
  updatedAt    DateTime @updatedAt
  createdBy    String   // User ID
  
  @@index([publishedAt])
  @@index([slug])
}

Next.js Server Actions (app/actions/newsletter.ts):

'use server'

export async function createNewsletter(data: NewsletterInput) {
  const session = await auth()
  if (!session?.user?.isAdmin) throw new Error('Unauthorized')
  
  return await db.newsletter.create({ data })
}

export async function updateNewsletter(id: string, data: NewsletterInput) {
  const session = await auth()
  if (!session?.user?.isAdmin) throw new Error('Unauthorized')
  
  return await db.newsletter.update({ where: { id }, data })
}

export async function deleteNewsletter(id: string) {
  const session = await auth()
  if (!session?.user?.isAdmin) throw new Error('Unauthorized')
  
  return await db.newsletter.delete({ where: { id } })
}

This would provide true CRUD capabilities as described in the PR objectives.

🤖 Prompt for AI Agents

In apps/web/src/data/newsletters.ts around lines 16 to 1951, the PR accidentally
embeds 1,900+ lines of static newsletter content which contradicts the admin
CRUD objective; replace this static array with a thin data-access shim that
reads/writes newsletters from the database (remove the bulky content file), add
a Prisma Newsletter model and migration (fields: id, slug, title, description,
content as Text, publishedAt, author, issueNumber, readTime, createdAt,
updatedAt, createdBy, and indexes on publishedAt/slug), implement Next.js server
actions (create/update/delete) that enforce admin auth and call the DB, migrate
existing static items into the DB via a seed/migration script, update the admin
UI to use the server actions and new data-access API, and refactor any imports
to use the new DB-backed source so newsletters can be edited, deleted, and
versioned without redeploys.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Remove duplicate ReactDOM.render call.

Lines 249 and 251 both call ReactDOM.render with identical arguments, causing the component to be rendered twice unnecessarily.

Apply this diff:

 // Render the component
 ReactDOM.render(<NewsletterCMS />, document.getElementById('root'));
-    
-    ReactDOM.render(<NewsletterCMS />, document.getElementById('root'));

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// Render the component
	ReactDOM.render(<NewsletterCMS />, document.getElementById('root'));
	ReactDOM.render(<NewsletterCMS />, document.getElementById('root'));
	// Render the component
	ReactDOM.render(<NewsletterCMS />, document.getElementById('root'));

🤖 Prompt for AI Agents

In apps/web/src/tools/newsletter-cms/index.html around lines 248 to 251 there
are two identical ReactDOM.render calls that render <NewsletterCMS /> into the
same root, causing duplicate rendering; remove the redundant line so only a
single ReactDOM.render(<NewsletterCMS />, document.getElementById('root'));
remains.

[varunsiravuri]

Its good to work on opensox , would love to contribute more !

[apsinghdev]

@varunsiravuri thanks for the submission! Unfortunately, we are moving with a different submission this time, so we won't be able to accept it. Still, you are welcome to make contributions! 🙏