Fix: Make NOMBRECOMP field optional in Person mode

[gmorales96]

Summary by CodeRabbit

• New Features
  • Improved handling of records missing a full name: entries without this value are now accepted without errors, ensuring smoother imports and processing of incomplete datasets.
• Bug Fixes
  • Reduced validation failures when some personal details are absent, improving data robustness.
• Chores
  • Version updated to 1.0.3.

[coderabbitai]

Walkthrough

• In quienesquien/person.py, the Person model’s nombrecomp field changes from a required string to an optional string with a default of None, retaining the alias 'NOMBRECOMP'. No other logic in the class is modified.
• In quienesquien/version.py, the version constant is updated from '1.0.2' to '1.0.3'.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title clearly summarizes the primary change by stating that the NOMBRECOMP field in the Person class is now optional, directly reflecting the modification in person.py. It is concise, specific, and immediately conveys the core update without extraneous detail.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/make-nombrecomp-optional

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 650036b and 873741e.

📒 Files selected for processing (2)

• quienesquien/person.py (1 hunks)
• quienesquien/version.py (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.py

⚙️ CodeRabbit configuration file

**/*.py: Enforce Relative Imports for Internal Modules

Ensure that any imports referencing internal modules use relative paths. However, if modules reside in the main module directories (for example /src or /library_or_app_name) —and relative imports are not feasible—absolute imports are acceptable. Additionally, if a module is located outside the main module structure (for example, in /tests or /scripts at a similar level), absolute imports are also valid.

Examples and Guidelines:

1. If a module is in the same folder or a subfolder of the current file, use relative imports. For instance: from .some_module import SomeClass
2. If the module is located under /src or /library_or_app_name and cannot be imported relatively, absolute imports are allowed (e.g., from library_or_app_name.utilities import helper_method).
3. If a module is outside the main module directories (for example, in /tests, /scripts, or any similarly placed directory), absolute imports are valid.
4. External (third-party) libraries should be imported absolutely (e.g., import requests).

**/*.py:
Rule: Enforce Snake Case in Python Backend

1. New or Modified Code: Use snake_case for all variables, functions, methods, and class attributes.
2. Exceptions (Pydantic models for API responses):
   • Primary fields must be snake_case.
   • If older clients expect camelCase, create a computed or alias field that references the snake_case field.
   • Mark any camelCase fields as deprecated or transitional.

Examples

Invalid:

class CardConfiguration(BaseModel):
    title: str
    subTitle: str  # ❌ Modified or new field in camelCase

Valid:

class CardConfiguration(BaseModel):
    title: str
    subtitle: str  # ✅ snake_case for new/modified field

    @computed_field
    def subTitle(self) -> str:  # camelCase allowed only for compatibility
        return self.subtitle

Any direct use of camelCase in new or updated code outside of these exceptions should be flagged.

`*...

Files:

• quienesquien/person.py
• quienesquien/version.py

🔇 Additional comments (2)

quienesquien/version.py (1)

1-1: Version bump is acceptable, but be aware of potential breaking changes.

The patch version bump (1.0.2 → 1.0.3) is appropriate if the NOMBRECOMP field was incorrectly marked as required and this fixes a validation bug. However, making a required field optional can break downstream consumers that access person.nombrecomp without None checks.

Consider whether a minor version bump (1.1.0) would better signal this change to consumers, especially if they need to update their code to handle None values.

quienesquien/person.py (1)

15-15: No production usages of nombrecomp—no action required. Verified that only test code references this field (always with non-null inputs) and no runtime code accesses it.

---

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