Add optional RFC field to UserUpdateRequest model

[gmorales96]

Summary by CodeRabbit

• New Features

  • You can now include an RFC (tax ID) when updating a user’s profile. This field is optional.

• Chores

  • Bumped package version to 2.1.19.

[coderabbitai]

Walkthrough

• Added optional field rfc: Optional[Rfc] = None to the UserUpdateRequest model in cuenca_validations/types/requests.py.
• Updated package version from 2.1.18 to 2.1.19 in cuenca_validations/version.py.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• version #383 — Also adds optional fields to UserUpdateRequest, modifying the same class.
• Add optional fiscal_regime_code field to UserUpdateRequest model #381 — Adds a different optional field (fiscal_regime_code) to UserUpdateRequest in the same file.

Suggested reviewers

• rogelioLpz
• felipao-mx
• pachCode

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 pull request title clearly and concisely states the primary change by indicating an optional RFC field addition to the UserUpdateRequest model, matching the changeset and providing sufficient context for readers without superfluous information.
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 feat/user-update-request-optional-rfc

---

📜 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 fe78144 and 18aa8c3.

📒 Files selected for processing (2)

• cuenca_validations/types/requests.py (1 hunks)
• cuenca_validations/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:

• cuenca_validations/types/requests.py
• cuenca_validations/version.py

🔇 Additional comments (2)

cuenca_validations/version.py (1)

1-1: LGTM!

The patch version bump from 2.1.18 to 2.1.19 is appropriate for adding a backward-compatible optional field to the UserUpdateRequest model.

cuenca_validations/types/requests.py (1)

512-512: LGTM!

The addition of the optional rfc field is well-implemented:

• Uses the existing Rfc validated type
• Follows snake_case naming convention
• Backward compatible (optional field with None default)
• Logically placed alongside other fiscal-related fields

---

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (fe78144) to head (18aa8c3).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #390   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           16        16           
  Lines         1395      1396    +1     
=========================================
+ Hits          1395      1396    +1     

Flag	Coverage Δ
unittests	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
cuenca_validations/types/requests.py	100.00% <100.00%> (ø)
cuenca_validations/version.py	100.00% <100.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fe78144...18aa8c3. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.