Skip to content

Conversation

@osm-Jatin
Copy link

@osm-Jatin osm-Jatin commented Jul 7, 2025

Task Link

REST-1582

Description

  • Update the README file.

Summary by CodeRabbit

  • New Features

    • Introduced login and token revocation endpoints with Redis-backed token management.
    • Added support for generating PDF documents from HTML/EJS templates and Word documents with placeholders, tables, and images.
    • Integrated Redis for token storage and revocation.
  • Refactor

    • Renamed namespaces and project structure from "DocumentService" to "OsmoDoc".
    • Updated Docker and docker-compose configurations for new service names and Redis integration.
    • Enhanced configuration and environment variable handling.
  • Bug Fixes

    • Improved input validation and error handling in document generation endpoints.
  • Documentation

    • Updated README and developer documentation to reflect new names, features, and usage examples.
    • Revised API documentation and navigation to match updated namespaces.
  • Chores

    • Updated .gitignore, environment variable examples, and project metadata.

osm-Jatin and others added 30 commits June 15, 2025 14:51
@osm-Jatin osm-Jatin requested a review from sameer-s-b July 7, 2025 05:19
@osm-Jatin osm-Jatin self-assigned this Jul 7, 2025
@coderabbitai
Copy link

coderabbitai bot commented Jul 7, 2025

Walkthrough

This update migrates the project from "DocumentService" to "OsmoDoc," renaming namespaces, classes, documentation, and configuration files accordingly. It introduces Redis-backed JWT token management, adds new API endpoints for login and token revocation, and restructures Docker and environment setups. Both PDF and Word document generation logic are refactored, with improved configuration, validation, and asynchronous processing.

Changes

Files/Paths Change Summary
.env.example, .gitignore, README.md, CONTRIBUTING.md, .github/... Updated environment examples, ignore rules, documentation, and PR templates for new project name and configs.
docker-compose.yaml, Dockerfile Reworked Docker setup: added Redis service, updated API service, ports, environment variables, and volumes.
OsmoDoc.sln, OsmoDoc.API/OsmoDoc.API.sln, OsmoDoc/OsmoDoc.csproj Renamed solution and project files from DocumentService to OsmoDoc; updated project references and metadata.
OsmoDoc.API/Program.cs Added Redis connection, JWT revocation, stricter env checks, and improved Swagger config.
OsmoDoc.API/Controllers/LoginController.cs New: Added login and token revocation endpoints using Redis-backed JWT management.
OsmoDoc.API/Controllers/PdfController.cs, OsmoDoc.API/Controllers/WordController.cs Refactored: Updated namespaces, async processing, config validation, error logging, and resource cleanup.
OsmoDoc.API/Helpers/AuthenticationHelper.cs, .../Base64StringHelper.cs, ... Updated namespaces to OsmoDoc; minor validation improvements.
OsmoDoc.API/Helpers/AutoMappingProfile.cs Re-added mapping profile class under new namespace (empty implementation).
OsmoDoc.API/Models/* Replaced/rewrote DTOs for login, revoke token, PDF, and Word generation requests.
OsmoDoc/Pdf/Models/*, OsmoDoc/Word/Models/* Recreated model classes and enums in new namespaces with minor property and logic changes.
OsmoDoc/Pdf/PdfDocumentGenerator.cs, OsmoDoc/Word/WordDocumentGenerator.cs Re-implemented document generators with async methods, improved error handling, and resource management.
OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs New: Added static config class for PDF tool path.
OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs, OsmoDoc/Services/RedisTokenStoreService.cs New: Added Redis-backed token store interface and implementation.
DocumentService/*, DocumentService.API/* Deleted: Removed all legacy code, DTOs, helpers, and document generation logic from old namespaces.
docs/site/*, docs/site/manifest.json, docs/site/xrefmap.yml Updated documentation to reflect new namespaces, class names, and project branding.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant API as OsmoDoc.API
    participant Redis
    participant PDFGen as PdfDocumentGenerator
    participant WordGen as WordDocumentGenerator

    Client->>API: POST /api/login (email)
    API->>API: Generate JWT token
    API->>Redis: StoreTokenAsync(token, email)
    Redis-->>API: Ack
    API-->>Client: { status: Success, token }

    Client->>API: POST /api/revoke (token)
    API->>Redis: RevokeTokenAsync(token)
    Redis-->>API: Ack
    API-->>Client: { status: Success }

    Client->>API: POST /api/pdf (PDFGenerationRequestDTO)
    API->>PDFGen: GeneratePdf(template, metaData, ...)
    PDFGen-->>API: PDF file path
    API-->>Client: { status: Success, file }

    Client->>API: POST /api/word (WordGenerationRequestDTO)
    API->>WordGen: GenerateDocumentByTemplate(template, data, ...)
    WordGen-->>API: Word file path
    API-->>Client: { status: Success, file }
Loading

Poem

🐇
OsmoDoc hops in, leaving DocumentService behind,
With Redis for tokens and configs aligned.
PDF and Word, now smarter and clean,
Async and robust, the best you’ve seen!
Docker and docs, all shiny and new—
A rabbit’s proud leap for the whole dev crew!

✨ Finishing Touches
  • 📝 Generate Docstrings

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
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 9

🧹 Nitpick comments (20)
.github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (1)

68-71: Replace stray replacement characters with normal bullets

The “�” glyphs indicate a bad copy-paste / encoding issue and render oddly in Markdown.

- - <strong style="color:black">�</strong> **If we suggest changes, then:**
-   - � Make the required updates.
-   - � Ensure that your changes do not break existing functionality or introduce new issues.
-   - � Rebase your branch and force push to your GitHub repository. This will update your Pull Request.
+ - **If we suggest changes, then:**
+   - Make the required updates.
+   - Ensure that your changes do not break existing functionality or introduce new issues.
+   - Rebase your branch and force-push to update the PR.
CONTRIBUTING.md (1)

1-2: Unify brand capitalization: “OsmoDoc” vs “osmodoc”

Line 1 introduces “OsmoDoc” (PascalCase) while line 2 immediately switches to lowercase “osmodoc”.
Standardising on a single style improves brand consistency across docs.

OsmoDoc.API/Helpers/Base64StringHelper.cs (1)

5-17: Harden input & avoid silent overwrite

  1. configuration.GetSection("CONFIG:UPLOAD_FILE_SIZE_LIMIT_BYTES").Value can return null, causing Convert.ToInt64 to throw.
  2. File.WriteAllBytesAsync will blindly overwrite an existing file.
+        if (configuration is null)
+            throw new ArgumentNullException(nameof(configuration));
+
+        var sizeLimitValue = configuration["CONFIG:UPLOAD_FILE_SIZE_LIMIT_BYTES"];
+        if (!long.TryParse(sizeLimitValue, out var uploadFileSizeLimitBytes))
+            throw new InvalidOperationException("Missing/invalid upload size limit config.");
+
-        long uploadFileSizeLimitBytes = Convert.ToInt64(configuration.GetSection("CONFIG:UPLOAD_FILE_SIZE_LIMIT_BYTES").Value);
-
-        if (data.LongLength > uploadFileSizeLimitBytes)
+        if (data.LongLength > uploadFileSizeLimitBytes)
             throw new BadHttpRequestException("Uploaded file is too large");
+
+        // Fail if the file already exists to avoid accidental overwrite
+        if (File.Exists(filePath))
+            throw new IOException($"File already exists at {filePath}");

Consider also streaming to disk instead of buffering the entire byte[] for very large uploads, but that might be outside this PR’s scope.

OsmoDoc.API/DotEnv.cs (1)

12-30: Skip empty / comment lines & tighten parsing for robustness

Load currently processes every non-existent/blank line and ignores # comment lines only if they don’t contain =.
This will:

  1. Try to set env-vars for lines that are whitespace only.
  2. Mis-handle commented keys like #FOO=bar (will set an empty key).

A small guard and using the newer range syntax keeps the method safe & compact:

 foreach (string raw in File.ReadAllLines(filePath))
 {
-    // Check if the line contains '='
-    int equalsIndex = line.IndexOf('=');
-    if (equalsIndex == -1)
-    {
-        continue; // Skip lines without '='
-    }
+    var line = raw.Trim();
+    if (string.IsNullOrEmpty(line) || line.StartsWith('#'))
+        continue;
+
+    var equalsIndex = line.IndexOf('=');
+    if (equalsIndex <= 0)           // key cannot be empty
+        continue;
 
     string key = line[..equalsIndex].Trim();
-    string value = line.Substring(equalsIndex + 1).Trim();
+    string value = line[(equalsIndex + 1)..].Trim();
 
     // Remove the surrounding quotes, if any
-    if (value.StartsWith("\"") && value.EndsWith("\""))
-    {
-        value = value[1..^1];
-    }
+    if (value.Length > 1 && value.StartsWith('"') && value.EndsWith('"'))
+        value = value[1..^1];
 
     Environment.SetEnvironmentVariable(key, value);
 }

No behavioural change for valid lines, but prevents accidental bad keys and unnecessary env-var writes.

OsmoDoc/Pdf/Models/ContentMetaData.cs (1)

3-7: Consider record type & XML docs for public model

This DTO is immutable in practice and exposed publicly. A C# record (or record class) gives:

  • built-in value equality (useful in unit tests)
  • succinct syntax
-public class ContentMetaData
-{
-    public string Placeholder { get; set; } = string.Empty;
-    public string Content { get; set; } = string.Empty;
-}
+/// <summary>
+/// Mapping between a template placeholder and its replacement content.
+/// </summary>
+public record ContentMetaData(string Placeholder, string Content);

Purely optional, but reduces boilerplate and communicates intent.

OsmoDoc/Pdf/Models/DocumentData.cs (2)

1-4: Remove unused System.Text import.

System.Text isn’t referenced – keeping it adds noise and may trigger style-cop warnings.

-using System.Text;

7-10: Add XML docs & prefer collection expression.

To keep parity with the Word counterpart and surface-area docs:

-namespace OsmoDoc.Pdf.Models;
-
-public class DocumentData
-{
-    public List<ContentMetaData> Placeholders { get; set; } = new List<ContentMetaData>();
-}
+namespace OsmoDoc.Pdf.Models;
+
+/// <summary>
+/// Represents the placeholder data for PDF generation.
+/// </summary>
+public class DocumentData
+{
+    /// <summary>
+    /// List of placeholder metadata. Empty list is allowed.
+    /// </summary>
+    public List<ContentMetaData> Placeholders { get; set; } = new();
+}
OsmoDoc.API/Helpers/AuthenticationHelper.cs (1)

10-27: Parameter naming & null-input guard.

Minor polish – makes the public surface more idiomatic and avoids silent NREs:

-public static string JwtTokenGenerator(string LoginEmail)
+public static string JwtTokenGenerator(string loginEmail)
 {
-    SymmetricSecurityKey secretKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(
+    ArgumentNullException.ThrowIfNull(loginEmail);
+
+    var secretKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(
         Environment.GetEnvironmentVariable("JWT_KEY") ?? throw new InvalidOperationException("No JWT key specified")
     ));
-    SigningCredentials signinCredentials = new SigningCredentials(secretKey, SecurityAlgorithms.HmacSha256);
+    var signinCredentials = new SigningCredentials(secretKey, SecurityAlgorithms.HmacSha256);

(Safe to defer if outside PR scope; creating a tracking issue would match past preference.)

OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (1)

5-6: Consider locking-in configuration immutability
WkhtmltopdfPath is a mutable static. If this value is changed after services are already using it, concurrent requests could see inconsistent paths. If runtime changes aren’t required, make the setter init-only (C# 9) or expose a one-time Configure method that throws if called twice.

-    public static string? WkhtmltopdfPath { get; set; }
+    public static string? WkhtmltopdfPath { get; init; }
OsmoDoc/Word/Models/ContentData.cs (1)

7-29: Fix documentation inconsistency regarding content types.

The class implementation is solid with proper initialization and comprehensive documentation. However, there's an inconsistency on line 20 where the comment mentions "text or image" but the ContentType enum only supports Text.

Apply this fix to align the documentation with the current enum:

    /// <summary>
-    /// Gets or sets the content type of the placeholder (text or image).
+    /// Gets or sets the content type of the placeholder.
    /// </summary>
OsmoDoc/Word/Models/DocumentData.cs (1)

1-3: Remove unused using statements.

The System and System.Text namespaces are not used in this file.

Apply this diff to remove unused imports:

-using System;
 using System.Collections.Generic;
-using System.Text;
OsmoDoc.API/Models/WordGenerationRequestDTO.cs (1)

17-19: Consider using consistent list initialization syntax.

For consistency with modern C# syntax, consider using just new() instead of new List<T>():

-    public List<ContentData> Placeholders { get; set; } = new List<ContentData>();
-    public List<TableData> TablesData { get; set; } = new List<TableData>();
-    public List<ImageData> ImagesData { get; set; } = new List<ImageData>();
+    public List<ContentData> Placeholders { get; set; } = new();
+    public List<TableData> TablesData { get; set; } = new();
+    public List<ImageData> ImagesData { get; set; } = new();
OsmoDoc/Services/RedisTokenStoreService.cs (1)

24-28: Consider using System.Text.Json for better performance.

Since this is new code, consider using the more performant System.Text.Json instead of Newtonsoft.Json:

-using Newtonsoft.Json;
+using System.Text.Json;

-        return this._db.StringSetAsync($"{KeyPrefix}{token}", JsonConvert.SerializeObject(new
+        return this._db.StringSetAsync($"{KeyPrefix}{token}", JsonSerializer.Serialize(new
         {
             issuedTo = email,
             issuedAt = DateTime.UtcNow
         }));
Dockerfile (1)

17-20: Consider adding .dockerignore for build optimization.

While copying entire directories simplifies the Dockerfile, it may include unnecessary files in the build context. Consider creating a .dockerignore file to exclude files like bin/, obj/, and other build artifacts.

Would you like me to generate a .dockerignore file to optimize the Docker build process?

OsmoDoc.API/Program.cs (1)

39-43: Consider validating the wkhtmltopdf tool path at startup.

The PDF tool path is set but not validated. Consider checking if the file exists at startup to fail fast if misconfigured.

Add validation after setting the path:

 OsmoDocPdfConfig.WkhtmltopdfPath = Path.Combine(
     builder.Environment.WebRootPath,
     builder.Configuration.GetSection("STATIC_FILE_PATHS:HTML_TO_PDF_TOOL").Value!
 );
+
+// Validate tool path on non-Linux platforms
+if (!RuntimeInformation.IsOSPlatform(OSPlatform.Linux) && !File.Exists(OsmoDocPdfConfig.WkhtmltopdfPath))
+{
+    throw new FileNotFoundException($"wkhtmltopdf tool not found at: {OsmoDocPdfConfig.WkhtmltopdfPath}");
+}
OsmoDoc.API/Controllers/LoginController.cs (1)

25-31: Add email validation in the login endpoint.

The login endpoint accepts an email but doesn't validate its format. Consider adding email validation to prevent invalid tokens from being generated.

Add validation before generating the token:

 public async Task<ActionResult<BaseResponse>> Login([FromBody] LoginRequestDTO loginRequest)
 {
     BaseResponse response = new BaseResponse(ResponseStatus.Fail);
     try
     {
+        if (string.IsNullOrWhiteSpace(loginRequest?.Email))
+        {
+            response.Message = "Email is required";
+            return this.BadRequest(response);
+        }
+
+        // Optional: Add email format validation
+        if (!System.ComponentModel.DataAnnotations.EmailAddressAttribute().IsValid(loginRequest.Email))
+        {
+            response.Message = "Invalid email format";
+            return this.BadRequest(response);
+        }
+
         string token = AuthenticationHelper.JwtTokenGenerator(loginRequest.Email);
         await this._tokenStoreService.StoreTokenAsync(token, loginRequest.Email, this.HttpContext.RequestAborted);
README.md (3)

30-30: Add missing article "a" for better grammar.

-6. Copy data from [example template](.env.example) into `.env`. Then set suitable JWT key.
+6. Copy data from [example template](.env.example) into `.env`. Then set a suitable JWT key.

33-33: Fix heading hierarchy for proper document structure.

The heading levels jump from h2 to h4, skipping h3. This affects document structure and accessibility.

-#### Development
+### Development
-#### Testing/Staging
+### Testing/Staging
-#### Production
+### Production
-#### HTML TO PDF
+### HTML TO PDF
-#### EJS TO PDF
+### EJS TO PDF

Also applies to: 112-112


260-260: Clarify the target framework specification.

The framework is listed as ".NET Framework 8.0", but .NET 8.0 is part of the modern .NET (formerly .NET Core) lineup, not .NET Framework.

-1. .NET Framework 8.0
+1. .NET 8.0
docker-compose.yaml (1)

32-32: Add newline at end of file.

Add a newline character at the end of the file to follow YAML best practices:

   osmodoc-net:
-    driver: bridge
+    driver: bridge
+
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 10ba019 and c524efd.

⛔ Files ignored due to path filters (1)
  • OsmoDoc.API/wwwroot/Tools/wkhtmltopdf.exe is excluded by !**/*.exe
📒 Files selected for processing (60)
  • .env.example (1 hunks)
  • .github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (1 hunks)
  • .gitignore (1 hunks)
  • CONTRIBUTING.md (7 hunks)
  • Dockerfile (1 hunks)
  • DocumentService.API/Helpers/AutoMappingProfile.cs (0 hunks)
  • DocumentService.API/Models/PdfGenerationRequestDTO.cs (0 hunks)
  • DocumentService.API/Models/WordGenerationRequestDTO.cs (0 hunks)
  • DocumentService/DocumentService.csproj (0 hunks)
  • DocumentService/Pdf/Models/ContentMetaData.cs (0 hunks)
  • DocumentService/Pdf/Models/DocumentData.cs (0 hunks)
  • DocumentService/Pdf/PdfDocumentGenerator.cs (0 hunks)
  • DocumentService/Word/Models/ContentData.cs (0 hunks)
  • DocumentService/Word/Models/DocumentData.cs (0 hunks)
  • DocumentService/Word/Models/Enums.cs (0 hunks)
  • DocumentService/Word/Models/TableData.cs (0 hunks)
  • DocumentService/Word/WordDocumentGenerator.cs (0 hunks)
  • OsmoDoc.API/Controllers/LoginController.cs (1 hunks)
  • OsmoDoc.API/Controllers/PdfController.cs (1 hunks)
  • OsmoDoc.API/Controllers/WordController.cs (1 hunks)
  • OsmoDoc.API/DotEnv.cs (1 hunks)
  • OsmoDoc.API/Helpers/AuthenticationHelper.cs (1 hunks)
  • OsmoDoc.API/Helpers/AutoMappingProfile.cs (1 hunks)
  • OsmoDoc.API/Helpers/Base64StringHelper.cs (1 hunks)
  • OsmoDoc.API/Helpers/CommonMethodsHelper.cs (1 hunks)
  • OsmoDoc.API/Models/BaseResponse.cs (1 hunks)
  • OsmoDoc.API/Models/LoginRequestDTO.cs (1 hunks)
  • OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (1 hunks)
  • OsmoDoc.API/Models/RevokeTokenRequestDTO.cs (1 hunks)
  • OsmoDoc.API/Models/WordGenerationRequestDTO.cs (1 hunks)
  • OsmoDoc.API/OsmoDoc.API.csproj (1 hunks)
  • OsmoDoc.API/OsmoDoc.API.sln (1 hunks)
  • OsmoDoc.API/Program.cs (1 hunks)
  • OsmoDoc.sln (1 hunks)
  • OsmoDoc/OsmoDoc.csproj (1 hunks)
  • OsmoDoc/Pdf/Models/ContentMetaData.cs (1 hunks)
  • OsmoDoc/Pdf/Models/DocumentData.cs (1 hunks)
  • OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (1 hunks)
  • OsmoDoc/Pdf/PdfDocumentGenerator.cs (1 hunks)
  • OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs (1 hunks)
  • OsmoDoc/Services/RedisTokenStoreService.cs (1 hunks)
  • OsmoDoc/Word/Models/ContentData.cs (1 hunks)
  • OsmoDoc/Word/Models/DocumentData.cs (1 hunks)
  • OsmoDoc/Word/Models/Enums.cs (1 hunks)
  • OsmoDoc/Word/Models/ImageData.cs (1 hunks)
  • OsmoDoc/Word/Models/TableData.cs (1 hunks)
  • OsmoDoc/Word/WordDocumentGenerator.cs (1 hunks)
  • README.md (3 hunks)
  • docker-compose.yaml (1 hunks)
  • docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.html (5 hunks)
  • docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html (2 hunks)
  • docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html (4 hunks)
  • docs/site/10.0.2/api/OsmoDoc.Word.Models.ParentBody.html (2 hunks)
  • docs/site/10.0.2/api/OsmoDoc.Word.Models.TableData.html (3 hunks)
  • docs/site/10.0.2/api/OsmoDoc.Word.Models.html (2 hunks)
  • docs/site/10.0.2/api/OsmoDoc.Word.WordDocumentGenerator.html (3 hunks)
  • docs/site/10.0.2/api/OsmoDocWord.html (2 hunks)
  • docs/site/10.0.2/api/toc.html (1 hunks)
  • docs/site/manifest.json (1 hunks)
  • docs/site/xrefmap.yml (1 hunks)
💤 Files with no reviewable changes (12)
  • DocumentService.API/Helpers/AutoMappingProfile.cs
  • DocumentService/Pdf/Models/DocumentData.cs
  • DocumentService/Word/Models/ContentData.cs
  • DocumentService/Word/Models/TableData.cs
  • DocumentService/Word/Models/DocumentData.cs
  • DocumentService/Pdf/Models/ContentMetaData.cs
  • DocumentService/DocumentService.csproj
  • DocumentService/Word/Models/Enums.cs
  • DocumentService.API/Models/WordGenerationRequestDTO.cs
  • DocumentService.API/Models/PdfGenerationRequestDTO.cs
  • DocumentService/Word/WordDocumentGenerator.cs
  • DocumentService/Pdf/PdfDocumentGenerator.cs
🧰 Additional context used
🧠 Learnings (46)
📓 Common learnings
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.
OsmoDoc.API/OsmoDoc.API.sln (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
.github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.
OsmoDoc/Pdf/Models/ContentMetaData.cs (7)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
OsmoDoc.API/OsmoDoc.API.csproj (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
OsmoDoc.API/Helpers/Base64StringHelper.cs (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
OsmoDoc.API/Helpers/CommonMethodsHelper.cs (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Controllers/WordController.cs:46-47
Timestamp: 2025-06-19T18:01:38.314Z
Learning: In the OsmoDoc project, the `CreateDirectoryIfNotExists` method in `CommonMethodsHelper` is designed to accept file paths as parameters. It internally uses `Path.GetDirectoryName(filePath)` to extract the directory path before creating the directory, so passing full file paths to this method is the correct usage pattern.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
OsmoDoc.API/Helpers/AuthenticationHelper.cs (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ParentBody.html (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
docs/site/10.0.2/api/OsmoDoc.Word.Models.html (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc.sln (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
OsmoDoc.API/Models/RevokeTokenRequestDTO.cs (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
OsmoDoc.API/Helpers/AutoMappingProfile.cs (2)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
docs/site/manifest.json (1)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
docs/site/10.0.2/api/OsmoDocWord.html (7)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs:5-10
Timestamp: 2025-06-20T15:03:58.820Z
Learning: StackExchange.Redis basic methods (StringSetAsync, KeyExistsAsync, KeyDeleteAsync) don't directly support CancellationToken parameters. The recommended approach is to use cancellationToken.ThrowIfCancellationRequested() for early cancellation detection before Redis operations.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
OsmoDoc/Word/Models/DocumentData.cs (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
.env.example (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
OsmoDoc/Word/Models/TableData.cs (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
docs/site/10.0.2/api/OsmoDoc.Word.WordDocumentGenerator.html (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
docs/site/10.0.2/api/toc.html (2)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
OsmoDoc/Word/Models/Enums.cs (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc/OsmoDoc.csproj (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AutoMappingProfile.cs:9-11
Timestamp: 2025-07-04T03:10:35.535Z
Learning: osm-Jatin indicated that AutoMapper mapping configurations are not needed in the empty AutoMappingProfile constructor in the OsmoDoc project, suggesting they may not be using AutoMapper for certain mappings or have alternative approaches.
OsmoDoc/Word/Models/ContentData.cs (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc.API/Models/BaseResponse.cs (2)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
docs/site/10.0.2/api/OsmoDoc.Word.Models.TableData.html (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.html (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc.API/Models/WordGenerationRequestDTO.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
OsmoDoc/Pdf/Models/DocumentData.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
OsmoDoc.API/Program.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
OsmoDoc/Pdf/PdfDocumentGenerator.cs (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
CONTRIBUTING.md (4)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.
OsmoDoc.API/Models/LoginRequestDTO.cs (3)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
OsmoDoc.API/Controllers/WordController.cs (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
README.md (10)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
OsmoDoc/Word/Models/ImageData.cs (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc.API/Controllers/LoginController.cs:25-31
Timestamp: 2025-06-21T16:53:18.086Z
Learning: In ASP.NET Core controllers, data annotations like [Required] and [EmailAddress] on DTO properties provide automatic model validation that eliminates the need for explicit null checks in most scenarios, as the framework handles validation before the action method executes.
OsmoDoc/Word/WordDocumentGenerator.cs (11)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:46-47
Timestamp: 2025-06-21T16:48:17.115Z
Learning: In the OsmoDoc project, the DocumentData class properties Placeholders and TablesData are initialized with empty lists using `= new()`, which means they are never null and don't require null-coalescing operators when accessed.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Word/WordDocumentGenerator.cs:0-0
Timestamp: 2025-06-20T14:47:35.545Z
Learning: NPOI's XWPFDocument.Write method does not support async operations (WriteAsync is not available), so when working with NPOI Word document generation, synchronous write operations should be used rather than attempting to make them async.
OsmoDoc.API/Controllers/PdfController.cs (7)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:24-37
Timestamp: 2025-06-18T14:03:39.731Z
Learning: In OsmoDoc PdfDocumentGenerator.GeneratePdf method, an empty metaDataList is a valid scenario when users want to convert HTML/EJS templates to PDF without any placeholder replacements. Only null metaDataList should be validated, not empty ones.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Dockerfile (5)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
OsmoDoc/Services/RedisTokenStoreService.cs (8)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/RedisTokenStoreService.cs:18-24
Timestamp: 2025-06-20T14:36:49.953Z
Learning: In the OsmoDoc project, the team prefers manual token lifecycle management over automatic TTL expiration in Redis. They deliberately store tokens without expiration to maintain precise control over when tokens become invalid through their dedicated revocation endpoints, rather than relying on automatic expiration.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-07-04T14:44:16.582Z
Learning: In the OsmoDoc project, the team has determined that adding issuer and audience claims to JWT tokens is not required for their specific use case. They have a comprehensive token management system with Redis-based revocation that meets their security requirements without needing additional JWT validation features.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs:5-10
Timestamp: 2025-06-20T15:03:58.820Z
Learning: StackExchange.Redis basic methods (StringSetAsync, KeyExistsAsync, KeyDeleteAsync) don't directly support CancellationToken parameters. The recommended approach is to use cancellationToken.ThrowIfCancellationRequested() for early cancellation detection before Redis operations.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Program.cs:98-112
Timestamp: 2025-06-20T14:36:43.563Z
Learning: In the OsmoDoc project, JWT tokens are intentionally designed to be non-expiring. The custom LifetimeValidator in Program.cs always returns true to prevent token expiration validation, which is by design rather than a bug.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, non-expiry JWT tokens are used intentionally with manual invalidation mechanisms. The team handles token lifecycle management manually rather than using time-based expiration.
docs/site/xrefmap.yml (9)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists with `= new()`, and DTOs are also initialized properly. This pattern ensures that the properties are never null, making additional null checks unnecessary for these specific properties in the WordDocumentGenerator.GenerateDocumentByTemplate method.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:32-47
Timestamp: 2025-06-21T17:00:19.937Z
Learning: In the OsmoDoc project, DocumentData class has its Placeholders and TablesData properties initialized to empty lists by default, and in WordGenerationRequestDTO, the DocumentData property is initialized with `= new();`. This pattern ensures that the properties are never null, though the parameter itself could still be null if explicitly passed as null.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#43
File: OsmoDoc/Word/WordDocumentGenerator.cs:298-311
Timestamp: 2025-06-21T17:11:15.672Z
Learning: In the OsmoDoc Word document generation code, when checking mainDocumentPart for null before populating a drawings collection, an additional null check inside the foreach loop is redundant because if mainDocumentPart was null, the drawings collection would remain empty and the loop wouldn't execute.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.
OsmoDoc.API/Controllers/LoginController.cs (6)
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#41
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:10-27
Timestamp: 2025-06-19T04:10:32.232Z
Learning: In the OsmoDoc project, they use a hybrid JWT + Redis token management approach: non-expiry JWT tokens are generated and stored in Redis for validation and manual revocation. The system includes RedisTokenService for token storage/validation and dedicated revocation endpoints, allowing stateless JWT benefits while maintaining token lifecycle control.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#42
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:18-24
Timestamp: 2025-06-20T14:37:36.118Z
Learning: In OsmoDoc.API, JWT tokens are intentionally created without expiration because the application uses Redis as the authoritative source for token validity. Tokens are stored in Redis when issued and can be manually revoked by removing them from Redis, providing centralized token management and immediate invalidation capability.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:11-24
Timestamp: 2025-06-22T13:55:51.706Z
Learning: In the OsmoDoc project, JWT tokens are intentionally created without expiration dates. The team has chosen to implement manual token invalidation through Redis storage instead of using JWT expiration claims. Tokens are stored in Redis and can be manually revoked using the /api/revoke endpoint. This design decision was made in PR #42 where the user stated "Not needed, we will make the token inactive manually for now."
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:129-136
Timestamp: 2025-07-04T03:22:57.460Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the user initially thought that request parameter null checks were unnecessary because DocumentData property is initialized with `= new();` in the DTO. However, property initialization only prevents null properties within successfully created DTO objects, while the request parameter itself can still be null due to null request bodies, malformed JSON, or model binding failures.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/LoginController.cs:42-43
Timestamp: 2025-07-04T03:45:35.740Z
Learning: In the OsmoDoc project, the team follows a specific logging pattern that includes logging both the exception message and stack trace using `_logger.LogError(ex.Message)` and `_logger.LogError(ex.StackTrace)` as seen in LoginController.cs. This is their established pattern for error logging across the application.
🧬 Code Graph Analysis (4)
OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (2)
OsmoDoc/Word/Models/DocumentData.cs (1)
  • DocumentData (11-28)
OsmoDoc/Pdf/Models/DocumentData.cs (1)
  • DocumentData (7-10)
OsmoDoc.API/Models/WordGenerationRequestDTO.cs (3)
OsmoDoc/Word/Models/ContentData.cs (1)
  • ContentData (7-29)
OsmoDoc/Word/Models/TableData.cs (1)
  • TableData (9-22)
OsmoDoc/Word/Models/ImageData.cs (1)
  • ImageData (13-39)
OsmoDoc/Pdf/Models/DocumentData.cs (2)
OsmoDoc/Word/Models/DocumentData.cs (1)
  • DocumentData (11-28)
OsmoDoc/Pdf/Models/ContentMetaData.cs (1)
  • ContentMetaData (3-7)
OsmoDoc/Pdf/PdfDocumentGenerator.cs (2)
OsmoDoc/Pdf/Models/ContentMetaData.cs (1)
  • ContentMetaData (3-7)
OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs (1)
  • OsmoDocPdfConfig (3-7)
🪛 LanguageTool
README.md

[duplication] ~1-~1: Possible typo: you repeated a word.
Context: # OsmoDoc OsmoDoc is a library with the following functio...

(ENGLISH_WORD_REPEAT_RULE)


[uncategorized] ~30-~30: You might be missing the article “a” here.
Context: ...te](.env.example) into .env. Then set suitable JWT key. 7. Set environment variables...

(AI_EN_LECTOR_MISSING_DETERMINER_A)

🪛 markdownlint-cli2 (0.17.2)
README.md

33-33: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)


112-112: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

🪛 YAMLlint (1.37.1)
docker-compose.yaml

[error] 32-32: no new line character at the end of file

(new-line-at-end-of-file)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Analyze (csharp)
🔇 Additional comments (38)
OsmoDoc.API/OsmoDoc.API.sln (1)

6-6: Confirm .csproj path remains correct after rename

"OsmoDoc.API.csproj" is now referenced from the solution root.
Double-check that the physical file really moved/was renamed accordingly; otherwise dotnet build will break.

.gitignore (1)

355-357: 👍 Top-level Temp/ ignore looks good

Adds coverage for the Docker-mounted folder without interfering with existing **/wwwroot/Temp rule.
No issues spotted.

.github/PULL_REQUEST_TEMPLATE/pull_request_template_api.md (1)

5-5: Updated repo link LGTM
The link now correctly targets osmodoc.
Good catch.

OsmoDoc.API/OsmoDoc.API.csproj (2)

11-11: Confirm Redis runtime dependency is documented

Adding StackExchange.Redis is fine, but the API will now fail fast if a Redis endpoint isn’t available in non-Docker/dev environments.
Please ensure the README / deployment docs updated by this PR mention:

  • required environment variables for Redis host/port/password
  • a docker-compose override (if applicable)

Otherwise newcomers will hit runtime connection exceptions.


16-16: Project reference path : double-check relative location

The ProjectReference jumps up one level (..) then into OsmoDoc\OsmoDoc.csproj.
If the API project is already at solution root, the extra .. will break CI builds on Windows/Linux with different casing.
Please verify the resulting path resolves in your build pipeline.

docs/site/10.0.2/api/OsmoDocWord.html (1)

8-12: Namespace rename looks correct
Only textual updates; no functional concerns.

docs/site/manifest.json (1)

3-4: Manifest paths updated – LGTM

Relative source_base_path and namespace rewrites line up with the new folder structure.

Also applies to: 8-82

docs/site/10.0.2/api/OsmoDoc.Word.Models.ParentBody.html (1)

70-82: Namespace/assembly rename looks correct.

The data-uid, header id, namespace, and assembly have been updated consistently to OsmoDoc.Word.Models. No further action required.

docs/site/10.0.2/api/OsmoDoc.Word.Models.html (1)

70-93: Documentation points to renamed types correctly.

Links and data-uids now reference OsmoDoc.Word.Models.* and render as expected.
No issues spotted.

docs/site/10.0.2/api/OsmoDoc.Word.Models.DocumentData.html (1)

70-110: Documentation accurately reflects namespace migration
All data-uid, heading IDs, and namespace/assembly references now point to OsmoDoc.Word.Models.*. No broken xrefs spotted.

docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentData.html (1)

70-110: ContentData docs updated correctly
Renaming changes look consistent; cross-links (ContentType, ParentBody) resolve to new locations.

OsmoDoc.API/Helpers/AutoMappingProfile.cs (1)

7-12: Empty profile – verify if AutoMapper is still required
The profile contains no mappings. If AutoMapper is no longer used, consider removing the package & startup registration to trim dependencies; otherwise add the intended mappings.

OsmoDoc.sln (1)

6-9: Solution rename looks correct
Projects now reference OsmoDoc and OsmoDoc.API; GUIDs unchanged and build configurations preserved.

OsmoDoc.API/Helpers/CommonMethodsHelper.cs (3)

3-3: LGTM: Namespace updated correctly.

The namespace change from DocumentService.API.Helpers to OsmoDoc.API.Helpers aligns with the project-wide refactoring.


9-12: Good defensive programming practice.

The input validation for filePath parameter prevents potential exceptions from Path.GetDirectoryName() when passed null or empty values.


16-16: Correct nullable type usage.

The nullable string? type is appropriate since Path.GetDirectoryName() can return null for certain inputs (e.g., root paths).

OsmoDoc.API/Models/RevokeTokenRequestDTO.cs (1)

5-9: LGTM: Well-structured DTO with proper validation.

The DTO follows established patterns with:

  • Required validation attribute for automatic model validation
  • Proper initialization to prevent null values
  • Clear property naming and purpose

This integrates well with the Redis-based token management system.

OsmoDoc/Word/Models/TableData.cs (1)

9-22: LGTM: Well-designed model class with excellent documentation.

The TableData class follows established patterns:

  • Collection property initialized to prevent null values (= new())
  • Comprehensive XML documentation explaining the purpose and structure
  • Clear property naming and types

This aligns with the defensive programming approach used throughout the OsmoDoc project.

.env.example (1)

1-10: LGTM: Comprehensive environment configuration for Redis integration.

The updates provide:

  • Clear guidance for JWT_KEY security requirements (min 32 characters)
  • Complete Redis configuration variables for the new token management system
  • Proper default values that align with the Docker Compose setup
  • Clear naming conventions for all variables

This supports the new Redis-based token management functionality effectively.

docs/site/10.0.2/api/toc.html (1)

17-43: LGTM: Documentation consistently updated for namespace refactoring.

All navigation links have been properly updated from DocumentService.Word to OsmoDoc.Word, maintaining:

  • Consistent naming throughout the table of contents
  • Proper link structure and hierarchy
  • Complete coverage of all model classes and generators

This ensures the documentation remains synchronized with the codebase changes.

OsmoDoc.API/Models/LoginRequestDTO.cs (1)

5-10: LGTM! Clean and well-structured DTO implementation.

The implementation follows ASP.NET Core best practices with proper data annotations for validation. The [Required] and [EmailAddress] attributes will provide automatic model validation, and initializing the Email property to string.Empty is a good defensive programming practice.

OsmoDoc/OsmoDoc.csproj (1)

1-27: LGTM! Well-configured project file with comprehensive NuGet metadata.

The project file is properly configured for .NET 8.0 with appropriate package references for document generation functionality. The NuGet package metadata is comprehensive and follows best practices for package publishing.

OsmoDoc.API/Models/PdfGenerationRequestDTO.cs (1)

6-12: LGTM! Consistent with project patterns and well-designed for PDF generation.

The implementation follows the established patterns in the OsmoDoc project:

  • Proper use of required keyword for critical properties
  • DocumentData initialization with = new() to prevent null reference issues
  • Appropriate nullable annotation for optional SerializedEjsDataJson

The design effectively supports the PDF generation workflow with proper validation.

docs/site/10.0.2/api/OsmoDoc.Word.Models.TableData.html (1)

70-70: LGTM! Documentation updates are consistent with the namespace migration.

All namespace and assembly references have been properly updated from DocumentService.Word.Models to OsmoDoc.Word.Models and from DocumentService.dll to OsmoDoc.dll. The updates are comprehensive and maintain consistency throughout the documentation.

Also applies to: 74-74, 107-108, 109-109, 115-116, 139-140

docs/site/10.0.2/api/OsmoDoc.Word.WordDocumentGenerator.html (1)

70-70: LGTM! Documentation updates are thorough and consistent with the namespace migration.

All namespace and assembly references have been properly updated from DocumentService.Word to OsmoDoc.Word and from DocumentService.dll to OsmoDoc.dll. The DocumentData type reference has been correctly updated to point to OsmoDoc.Word.Models.DocumentData. The updates maintain documentation consistency and accuracy.

Also applies to: 74-74, 107-108, 115-116, 139-139

OsmoDoc/Word/Models/Enums.cs (2)

7-13: LGTM: Well-defined enum with clear documentation.

The ContentType enum is properly defined with comprehensive XML documentation.


18-30: LGTM: ParentBody enum is well-structured.

The enum properly defines the parent body contexts for Word document placeholders.

OsmoDoc/Word/Models/DocumentData.cs (1)

11-28: LGTM: Well-structured class following established patterns.

The DocumentData class properly initializes all collections with empty lists, which aligns with the established pattern in the OsmoDoc project and prevents null reference exceptions.

OsmoDoc.API/Models/BaseResponse.cs (1)

24-37: LGTM: Improved error handling with robust null checks.

The refactored ModelValidationErrorResponse method properly handles null ModelState values and extracts the first meaningful error message with appropriate fallback. The implementation is more robust and follows good practices.

OsmoDoc/Services/Interfaces/IRedisTokenStoreService.cs (1)

6-11: LGTM: Well-designed interface with proper async patterns.

The interface properly defines the token management operations with appropriate async signatures and CancellationToken support. The method signatures align with the Redis-based token management approach used in the OsmoDoc project.

docs/site/xrefmap.yml (1)

4-195: Documentation namespace updates are consistent.

All references have been properly updated from DocumentService.Word to OsmoDoc.Word throughout the documentation cross-reference file, aligning with the project-wide namespace migration.

OsmoDoc/Word/Models/ImageData.cs (1)

6-39: Well-implemented image data model with appropriate validation.

The ImageData class properly validates that ImageExtension is required when SourceType is Base64, which is essential for proper image handling. The enum design and property initialization follow best practices.

OsmoDoc.API/Controllers/WordController.cs (1)

148-172: Excellent cleanup implementation.

The finally block ensures proper cleanup of temporary files with appropriate error logging, aligning with the project's cleanup scope requirements as noted in previous learnings.

OsmoDoc/Services/RedisTokenStoreService.cs (1)

19-29: Implementation aligns well with the team's token management approach.

The non-expiring token storage and manual revocation pattern correctly implements the team's preferred JWT + Redis hybrid approach as established in previous PRs. The cancellation token usage follows the recommended pattern for StackExchange.Redis.

Dockerfile (2)

5-7: LGTM! Production build configuration is appropriate.

The change to Release/Production configuration is correct for the production Docker image.


36-40: Good consolidation of package installation.

Combining the package installation into a single RUN command reduces the number of Docker layers and properly cleans up the apt cache.

OsmoDoc/Pdf/PdfDocumentGenerator.cs (1)

87-87: Verify the quadruple brace placeholder pattern.

The placeholder replacement uses {{{{placeholder}}}} pattern. This seems unusual as typically placeholders use double braces {{placeholder}}. Please verify if this is intentional for escaping purposes or if it should be simplified.

OsmoDoc.API/Program.cs (1)

165-169: Verify if Swagger UI in production is intentional.

Swagger UI is now enabled in both Development and Production environments. While this can be useful for API documentation, it may expose sensitive API structure in production. Please confirm this is intentional.

Comment on lines 95 to 102
<tr>
<td id="DocumentService_Word_Models_ContentType_Image">Image</td>
<td id="OsmoDoc_Word_Models_ContentType_Image">Image</td>
<td>The placeholder represents an image.</td>
</tr>
<tr>
<td id="DocumentService_Word_Models_ContentType_Text">Text</td>
<td id="OsmoDoc_Word_Models_ContentType_Text">Text</td>
<td>The placeholder represents text content.</td>
</tr>
Copy link

@coderabbitai coderabbitai bot Jul 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Docs out of sync with code – enum still lists Image.

The current source code (per PR summary) states ContentType only contains Text, yet the generated docs list both Image and Text. Regenerate the docs after updating the enum or adjust the enum if removal was accidental.

🤖 Prompt for AI Agents
In docs/site/10.0.2/api/OsmoDoc.Word.Models.ContentType.html around lines 95 to
102, the documentation lists both "Image" and "Text" as enum values, but the
source code enum only includes "Text". To fix this, verify the enum definition
in the source code and either remove "Image" from the enum if it was removed
intentionally or add it back if its removal was accidental. Then regenerate the
documentation to ensure it matches the updated enum values.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these docs manually created or with some buil-in library. I have no clue about this docs/ folder. Can you explain

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 Analysis chain

@osm-Jatin I'll investigate the documentation setup in your project to explain how these docs are generated.


🏁 Script executed:

#!/bin/bash
# Look for DocFX configuration files
find . -name "docfx.json" -o -name "*.docfx.json" 2>/dev/null

# Search for documentation-related build scripts or workflows
find . -name "*.yml" -o -name "*.yaml" | xargs grep -l -i "docfx\|documentation\|docs" 2>/dev/null || true

# Look for any documentation setup in README files
find . -name "README*" -exec grep -l -i "docfx\|documentation\|docs" {} \; 2>/dev/null || true

# Check if there are any package.json or project files mentioning documentation tools
find . -name "package.json" -o -name "*.csproj" | xargs grep -l -i "docfx\|documentation" 2>/dev/null || true

# Look at the docs directory structure
ls -la docs/ 2>/dev/null || echo "No docs directory found"

# Check for any build scripts
find . -name "build.sh" -o -name "build.ps1" -o -name "*.bat" | head -5

Length of output: 612


🏁 Script executed:

#!/bin/bash
# Examine the DocFX configuration file
echo "=== DocFX Configuration ==="
cat ./docfx.json

echo -e "\n=== Docs directory structure ==="
find docs/ -type f | head -10

echo -e "\n=== Check for GitHub Actions or CI that might build docs ==="
find .github/ -name "*.yml" -o -name "*.yaml" | xargs grep -l -i "docfx" 2>/dev/null || echo "No CI/CD files found with DocFX"

echo -e "\n=== Check manifest.json for more details ==="
head -20 docs/site/manifest.json 2>/dev/null || echo "No manifest found"

Length of output: 2490


@osm-Jatin Based on my investigation, here's what I found about your documentation setup:

DocFX Auto-Generated Documentation

Your docs are auto-generated using DocFX, a Microsoft documentation generation tool for .NET projects. Here's how it works:

Setup:

  • Configuration file: docfx.json in your root directory
  • Tool: DocFX scans your *.csproj files and extracts API documentation from:
    • XML documentation comments in your code
    • Class/method/property signatures
    • Assembly metadata

Generation Process:

  1. DocFX reads your C# code and generates YAML metadata files in obj/10.0.2/api/
  2. Converts YAML to HTML files in docs/site/10.0.2/api/
  3. Creates cross-reference maps and navigation

Current Issue:

The docs are out of sync with your source code. The HTML shows both Text and Image enum values, but your actual ContentType enum (per the AI summary) only contains Text.

To Fix This:

You need to regenerate the documentation by running:

# Install DocFX (if not already installed)
dotnet tool install -g docfx

# Regenerate docs from current source code
docfx docfx.json --serve

Manual vs Automated:

  • Currently: Manual regeneration (no CI/CD found)
  • Recommendation: Add a GitHub Action to auto-regenerate docs on code changes

The docs folder isn't manually created - it's the output of DocFX processing your actual C# code. You just need to regenerate them to match your current source code.


🧠 Learnings used
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T09:27:22.341Z
Learning: osm-Jatin prefers to move entirely to OpenXML SDK for the OsmoDoc NuGet library to eliminate document corruption issues caused by the hybrid NPOI + OpenXML approach, choosing long-term reliability and MS Office compatibility over the simpler NPOI APIs.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I run these commands:

  • dotnet tool install -g docfx
  • docfx docfx.json --serve

Will it override the docs/ directly without my intervention ? Or what steps should I follow to update this

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 Analysis chain

@osm-Jatin Let me check your DocFX configuration to give you the exact behavior:


🏁 Script executed:

#!/bin/bash
# Examine the DocFX configuration to understand the output settings
echo "=== DocFX Configuration - Build Section ==="
cat docfx.json | jq '.build'

echo -e "\n=== Current docs directory structure ==="
find docs/ -type f | head -5

echo -e "\n=== Check if there are any .gitignore entries for docs ==="
grep -n "docs" .gitignore 2>/dev/null || echo "No docs entries in .gitignore"

echo -e "\n=== Check source and destination paths ==="
cat docfx.json | jq '.build.dest'

Length of output: 1308


Based on your DocFX configuration, here's exactly what will happen and the safe steps to follow:

What the Commands Do:

docfx docfx.json --serve:

  • Safe: Creates a new _site/ directory (won't touch your existing docs/)
  • Generates fresh documentation in _site/10.0.2/api/
  • Starts a local web server to preview the docs
  • No automatic overwriting of your committed docs/ folder

Step-by-Step Process:

1. Generate Fresh Docs (Safe)

# Install DocFX globally
dotnet tool install -g docfx

# Generate docs and preview locally  
docfx docfx.json --serve

2. Review the Generated Docs

  • DocFX will serve the docs at http://localhost:8080
  • Compare with your current docs to ensure everything looks correct
  • Verify the ContentType enum now shows only the correct values

3. Update Your Committed Docs (Manual Step)

# Backup current docs (optional safety measure)
cp -r docs/site docs/site.backup

# Replace with freshly generated docs
rm -rf docs/site/10.0.2
cp -r _site/10.0.2 docs/site/

# Clean up the temporary _site directory
rm -rf _site

4. Commit the Changes

git add docs/
git commit -m "docs: regenerate API documentation to sync with current source code"

Key Points:

  • ✅ Your original docs/ won't be touched automatically
  • ✅ You control when/if to replace the committed docs
  • ✅ You can preview everything before committing
  • ⚠️ The manual copy step is required to update your committed documentation

This gives you full control over the update process!


🧠 Learnings used
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Word/WordDocumentGenerator.cs:314-315
Timestamp: 2025-06-19T18:07:02.969Z
Learning: In the OsmoDoc/Word/WordDocumentGenerator.cs file, the team prefers to keep the HttpClient usage as it is currently implemented (creating a new HttpClient instance for each image download), despite potential performance considerations. This decision was made with reference to discussion in PR #41.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/PdfController.cs:34-46
Timestamp: 2025-06-18T14:34:35.161Z
Learning: In OsmoDoc.API/Controllers/PdfController.cs, the PdfDocumentGenerator.GeneratePdf method only deletes its internal temporary files (converted HTML, modified HTML, JSON data files) but does not delete the input template files or output PDF files created by the controller, requiring manual cleanup in the controller to prevent disk bloat.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T09:27:22.341Z
Learning: osm-Jatin prefers to move entirely to OpenXML SDK for the OsmoDoc NuGet library to eliminate document corruption issues caused by the hybrid NPOI + OpenXML approach, choosing long-term reliability and MS Office compatibility over the simpler NPOI APIs.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

atingupta@fedora:~/Desktop/Work/osmodoc$ docfx docfx.json --serve
No files are found with glob pattern .csproj, excluding /bin/,/obj/, under directory "/home/jatingupta/Desktop/Work/osmodoc"
warning: No .NET API project detected.
Creating output...
warning: No .NET API detected for .
Searching built-in plugins in directory /home/jatingupta/.dotnet/tools/.store/docfx/2.78.3/docfx/2.78.3/tools/net8.0/any/...
No files are found with glob pattern **/
.yml,api/*.md, excluding , under directory "/home/jatingupta/Desktop/Work/osmodoc/obj/10.0.2"
7 plug-in(s) loaded.
Applying templates to 0 model(s)...
XRef map exported.
EmptyInputContents: No content file found. Please make sure the content section of docfx.json is correctly configured.
Serving "/home/jatingupta/Desktop/Work/osmodoc/_site" on http://localhost:8080
Press Ctrl+C to shut down
^C

Build succeeded with warning.

2 warning(s)
0 error(s)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 Analysis chain

@osm-Jatin The issue is that your docfx.json is missing the metadata section that tells DocFX where to find your .NET projects. Let me check the current configuration and provide the fix:


🏁 Script executed:

#!/bin/bash
# Check current DocFX configuration
echo "=== Current DocFX Configuration ==="
cat docfx.json

echo -e "\n=== Project files locations ==="
find . -name "*.csproj" -type f

echo -e "\n=== Current directory structure ==="
ls -la

Length of output: 2357


Perfect! I found the issue. Your docfx.json has the metadata section, but it's looking for *.csproj files in the current directory when your projects are actually in subdirectories.

The Problem:

  • Current pattern: "*.csproj" in "cwd": "."
  • Actual projects: ./OsmoDoc.API/OsmoDoc.API.csproj and ./OsmoDoc/OsmoDoc.csproj
  • Wrong target framework: "net452" (should be "net8.0")

Fix Your docfx.json:

Replace your current docfx.json with this corrected version:

{
    "metadata": [{
        "src": [{
            "files": [
                "**/*.csproj"
            ],
            "exclude": ["**/bin/**", "**/obj/**"],
            "cwd": "."
        }],
        "properties": {
            "TargetFramework": "net8.0"
        },
        "dest": "obj/10.0.2/api",
        "shouldSkipMarkup": true
    }],
    "build": {
        "content": [
            { "files": ["**/*.yml", "api/*.md"], "src": "obj/10.0.2", "dest": "10.0.2" }
        ],
        "globalMetadata": {
            "_appTitle": "OsmoDoc API Documentation",
            "_disableContribution": true,
            "_appFooter": " ",
            "_navRel": "../toc.html"
        },
        "template": [
            "default",
            "template"
        ],
        "overwrite": [
            { "files": ["*.md"] }
        ],
        "dest": "_site"
    }
}

Key Changes:

  1. "*.csproj""**/*.csproj" (finds projects in subdirectories)
  2. "net452""net8.0" (correct target framework)
  3. ✅ Updated app title to "OsmoDoc API Documentation"

Now Try Again:

# Clean any previous artifacts
rm -rf obj/ _site/

# Generate fresh docs
docfx docfx.json --serve

This should now detect your projects and generate the correct API documentation!


🧠 Learnings used
Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Word/WordDocumentGenerator.cs:33-44
Timestamp: 2025-07-04T03:15:02.263Z
Learning: In the OsmoDoc project, empty DocumentData collections (Placeholders, TablesData, Images) are valid scenarios when users want to generate documents without any placeholder replacements, table data, or images. The DocumentData parameter is always initialized at the controller level, but null checks are still added for defensive programming.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Controllers/PdfController.cs:27-124
Timestamp: 2025-07-05T11:54:07.645Z
Learning: In the OsmoDoc project, the cleanup scope is intentionally limited to modified/intermediate files created during document generation, not the input template or output files. This is because OsmoDoc is planned to be used as a NuGet package where users will provide and manage their own input and output file paths.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:194-198
Timestamp: 2025-07-07T14:45:51.713Z
Learning: osm-Jatin successfully implemented the npx cross-platform compatibility changes for EJS execution in OsmoDoc/Pdf/PdfDocumentGenerator.cs as discussed, using the correct conditional command line assignment and updating the arguments method to use npx consistently across Windows and Linux platforms.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:194-198
Timestamp: 2025-07-07T14:45:51.714Z
Learning: osm-Jatin successfully implemented the npx cross-platform compatibility changes for EJS execution in OsmoDoc/Pdf/PdfDocumentGenerator.cs in PR #54, using the exact implementation discussed: ternary operator for command line assignment (line 196), "/C npx ejs" for Windows (line 243), and "ejs" as first argument for Linux npx execution (line 247).

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#54
File: OsmoDoc.API/Controllers/LoginController.cs:26-31
Timestamp: 2025-07-07T15:09:24.073Z
Learning: In the OsmoDoc project, osm-Jatin prefers to rely on ASP.NET Core's built-in model validation system (using [Required] attributes and ModelValidationBadRequest.ModelValidationErrorResponse in BaseResponse.cs) rather than adding explicit null checks for request parameters in controller methods, as the framework automatically handles validation before action execution.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:84-92
Timestamp: 2025-06-18T14:44:46.570Z
Learning: osm-Jatin prefers to document input requirements clearly in the README file rather than adding runtime validation code for scenarios like null/duplicate placeholders in the OsmoDoc PDF generation functionality.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#40
File: OsmoDoc.API/Controllers/WordController.cs:38-60
Timestamp: 2025-06-18T15:05:30.284Z
Learning: osm-Jatin prefers to create separate GitHub issues to track technical debt and improvement suggestions that are out of scope for the current PR, such as temporary file cleanup concerns in the OsmoDoc project.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#53
File: OsmoDoc/Word/WordDocumentGenerator.cs:362-365
Timestamp: 2025-07-07T09:27:22.341Z
Learning: osm-Jatin prefers to move entirely to OpenXML SDK for the OsmoDoc NuGet library to eliminate document corruption issues caused by the hybrid NPOI + OpenXML approach, choosing long-term reliability and MS Office compatibility over the simpler NPOI APIs.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:5-7
Timestamp: 2025-07-05T11:50:52.163Z
Learning: In OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs, osm-Jatin intentionally keeps the WkhtmltopdfPath property with a public setter to allow runtime configuration for cross-platform compatibility, enabling users to manually set the appropriate wkhtmltopdf binary path based on their operating system.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc/Pdf/Models/OsmoDocPdfConfig.cs:3-7
Timestamp: 2025-07-04T03:19:33.236Z
Learning: osm-Jatin prefers to defer non-critical code improvements like thread safety enhancements and validation logic when they are not essential for the current PR scope, preferring to keep changes focused on the main objectives.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#49
File: OsmoDoc.API/Controllers/PdfController.cs:96-97
Timestamp: 2025-07-04T03:27:39.798Z
Learning: osm-Jatin prefers to defer security-related logging improvements (like removing stack trace logging) when they are not essential for the current PR scope in the OsmoDoc project, choosing to keep existing implementation for now.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#52
File: OsmoDoc.API/Helpers/AuthenticationHelper.cs:13-16
Timestamp: 2025-07-05T11:50:12.096Z
Learning: In the OsmoDoc project, osm-Jatin prefers to keep performance optimizations simple for infrequently used endpoints like the login endpoint, choosing not to implement caching optimizations when the endpoint usage is expected to be rare.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#51
File: OsmoDoc/Pdf/PdfDocumentGenerator.cs:92-102
Timestamp: 2025-07-05T11:36:58.382Z
Learning: osm-Jatin follows through on technical debt by creating tracking issues and then implementing fixes in separate PRs, ensuring proper review and testing of improvements identified during code reviews in the OsmoDoc project.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#54
File: OsmoDoc.API/DotEnv.cs:24-47
Timestamp: 2025-07-07T19:05:56.955Z
Learning: osm-Jatin prefers to keep error handling simple in utility methods like DotEnv.Load when the input (e.g., .env files) is expected to be well-formed and reliable, choosing not to over-engineer with extensive validation and error handling.

Learnt from: osm-Jatin
PR: OsmosysSoftware/osmodoc#54
File: OsmoDoc.API/Helpers/Base64StringHelper.cs:7-8
Timestamp: 2025-07-07T19:21:25.387Z
Learning: osm-Jatin prefers to handle exceptions like FormatException at the controller level using comprehensive catch blocks rather than adding specific exception handling in helper methods like Base64StringHelper.cs, maintaining consistency with the established error handling patterns in the OsmoDoc project.

@osm-Jatin osm-Jatin closed this Jul 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants