[OSDEV-1229] Create moderation events table

[VadimKovalenkoSNF]

OSDEV-1229 - Create moderation events table, introduces related migration file.

Created table with columns:

1. uuid - unique identifier to make moderation event table more reusable across the app.
2. created_at - date when the moderation queue entry was created.
3. updated_at - date when the moderation queue entry was last updated. This column is indexing.
4. status_change_date - date when the moderation decision was made.
5. contributor_id - linked contributor responsible for this moderation event.
6. claim_id - linked claim id for this production location.
7. request_type - type of moderation record.
8. raw_data - key-value pairs of the non-parsed row and header for the moderation data.
9. cleaned_data - key-value pairs of the parsed row and header for the moderation data.
10. geocode_result - result of the geocode operation.
11. status - moderation status of the production location.
12. source - source type of production location. If request_type is CLAIM, no source type.

Summary by CodeRabbit

• New Features

  • Introduced a new Moderation Events table to track moderation activities.
  • Implemented throttling for API endpoints to enhance performance.
  • Improved search functionality with a new tokenizer for better query results.

• Documentation

  • Updated release notes to standardize the release date format and included new sections for architecture, bug fixes, and features.

• Bug Fixes

  • Added placeholders in release notes for future bug fixes and new features.

[barecheck]

React App | Jest test suite - Code coverage report

Total: 25.86%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered

[barecheck]

Dedupe Hub App | Unittest test suite - Code coverage report

Total: 56.14%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered

[barecheck]

Countries App | Unittest test suite - Code coverage report

Total: 100%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered

[barecheck]

Contricleaner App | Unittest test suite - Code coverage report

Total: 98.91%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered

[barecheck]

Django App | Unittest test suite - Code coverage report

Total: 77.85%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered

[VadimKovalenkoSNF]

Left comment about __init__.py

[coderabbitai]

Actionable comments posted: 6

🧹 Outside diff range and nitpick comments (1)

src/django/api/models/moderation_event.py (1)

114-115: Add a space between concatenated strings in help_text

In the help_text for the source field, the concatenated strings lack spacing, resulting in them being joined without a space in the final string.

Apply this diff to correct the spacing:

help_text=(
    'Source type of production location.'
-   'If request_type is CLAIM, no source type.'
+   ' If request_type is CLAIM, no source type.'
)

Alternatively, add a space at the end of the first string:

help_text=(
-   'Source type of production location.'
+   'Source type of production location. '
    'If request_type is CLAIM, no source type.'
)

This adjustment ensures the help text reads correctly as:

"Source type of production location. If request_type is CLAIM, no source type."

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 5369b78 and ed173d8.

📒 Files selected for processing (2)

• src/django/api/migrations/0158_create_moderation_event_table.py (1 hunks)
• src/django/api/models/moderation_event.py (1 hunks)

🧰 Additional context used

🔇 Additional comments (2)

src/django/api/migrations/0158_create_moderation_event_table.py (2)

9-13: LGTM: Migration class and dependency are correctly defined.

The migration class is properly set up with the correct dependency on the previous migration.

---

1-42: Overall, well-structured migration with some suggested improvements

This migration file successfully creates the ModerationEvent model with various fields and relationships. The structure is clear and follows Django migration conventions. However, there are a few suggested improvements that should be considered:

1. Making status_change_date nullable
2. Making source nullable
3. Using SET_NULL instead of CASCADE for both claim and contributor fields

These changes will enhance data integrity and preserve important moderation history. Please review and implement these suggestions to improve the robustness of the ModerationEvent model.

[coderabbitai]

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (1)

src/django/api/models/moderation_event.py (1)

8-10: Consider enhancing the class docstring for clarity

The current docstring is minimal. Providing a more detailed description helps improve code readability and maintainability.

Suggested docstring:

'''
Represents a moderation event in the moderation queue.

This model stores data necessary for processing moderation requests,
including contributor details, request type, status, and associated data
for tracking and decision-making.
'''

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between ed173d8 and 944345a.

📒 Files selected for processing (2)

• src/django/api/migrations/0158_create_moderation_event_table.py (1 hunks)
• src/django/api/models/moderation_event.py (1 hunks)

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

• src/django/api/migrations/0158_create_moderation_event_table.py

🧰 Additional context used

🔇 Additional comments (1)

src/django/api/models/moderation_event.py (1)

59-65: Assess the necessity of allowing null for the claim field

The claim field is set to null=True, allowing it to be empty. If a moderation event should always be associated with a claim when request_type is CLAIM, consider enforcing this at the model level.

If appropriate, update the field to require a value when necessary, and add validation logic in the clean method:

def clean(self):
    super().clean()
    if self.request_type == self.RequestType.CLAIM and not self.claim:
        raise ValidationError('Claim must be provided when request_type is CLAIM.')

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 944345a and ecd5218.

📒 Files selected for processing (2)

• src/django/api/migrations/0158_create_moderation_event_table.py (1 hunks)
• src/django/api/models/moderation_event.py (1 hunks)

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

• src/django/api/migrations/0158_create_moderation_event_table.py

🧰 Additional context used

🔇 Additional comments (11)

src/django/api/models/moderation_event.py (11)

11-14: Well-defined RequestType choices enhance clarity

The RequestType inner class correctly uses models.TextChoices to define the possible request types. This approach improves code readability and maintainability.

---

16-18: Status choices are appropriately set up

The Status inner class effectively defines the moderation statuses using models.TextChoices. This ensures consistency and ease of use throughout the codebase.

---

20-22: Proper definition of Source choices

The Source inner class accurately represents the source types using models.TextChoices, aligning with best practices for choice fields in Django.

---

24-33: uuid field configuration is optimal

The uuid field is correctly set up with default=uuid.uuid4, editable=False, unique=True, and indexed for performance. This ensures each ModerationEvent has a unique identifier.

---

35-44: Timestamps for creation and updates are properly implemented

The created_at and updated_at fields use auto_now_add and auto_now, respectively, with indexing on updated_at for efficient queries. This setup adheres to best practices for timestamp fields.

---

52-58: contributor field allows for data integrity and prevents accidental deletions

Using on_delete=models.PROTECT ensures that Contributor instances linked to moderation events cannot be deleted inadvertently, preserving the moderation history. Allowing null=True accommodates scenarios where a contributor might not be associated.

---

68-73: request_type field is correctly defined

The request_type field uses the RequestType choices with an appropriate max_length and ensures that it is not null, maintaining data integrity.

---

75-102: JSON fields are properly configured

The raw_data, cleaned_data, and geocode_result fields are set up as JSONField with null=False, blank=False, and default=dict, which is acceptable in Django for creating new empty dictionaries for each instance.

---

104-110: status field ensures valid moderation statuses

The status field is well-defined with choices from the Status class, a sensible max_length, and a default value, enforcing consistency across moderation events.

---

112-121: Optional source field handled appropriately

Allowing blank=True and null=True for the source field accommodates cases where the request_type is CLAIM, and a source is not required. The help text clearly explains this behavior.

---

123-128: __str__ method provides clear representation

The __str__ method returns a concise and informative string that includes the UUID, request type, and status, which is helpful for logging and administrative interfaces.

[roman-stolar]

For me the changes looks good, so I'll approved it.
Waiting for other reviewers.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[coderabbitai]

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (2)

src/django/api/models/moderation_event.py (2)

8-10: Enhance the model's docstring

The current docstring is quite brief. Consider expanding it to include:

• The purpose of moderation events
• Key relationships with other models
• Important business rules (e.g., source field behavior with CLAIM type)

-    '''
-    Data that is needed for moderation queue.
-    '''
+    '''
+    Represents a moderation event in the system's moderation queue.
+    
+    This model tracks moderation decisions for facility claims and updates,
+    maintaining relationships with contributors and claims. It stores both
+    raw and cleaned data, along with geocoding results.
+    
+    Key relationships:
+    - Contributor: The user responsible for the moderation event
+    - FacilityClaim: Associated claim (only for CLAIM type events)
+    
+    Note: Source type is required except for CLAIM type events.
+    '''

---

68-73: Adjust max_length values to match actual choice lengths

The max_length values should be adjusted to match the actual maximum lengths of the choices:

• request_type: Current 6 matches 'CREATE'
• status: Should be 7 to accommodate 'PENDING' (currently 8)
• source: Current 3 matches 'API'/'SLC'

 status = models.CharField(
-    max_length=8,
+    max_length=7,
     choices=Status.choices,
     default=Status.PENDING,
     null=False,
     help_text='Moderation status of the production location.'
 )

Also applies to: 104-110, 112-121

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between ecd5218 and 54b61f1.

📒 Files selected for processing (2)

• src/django/api/migrations/0158_create_moderation_event_table.py (1 hunks)
• src/django/api/models/moderation_event.py (1 hunks)

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

• src/django/api/migrations/0158_create_moderation_event_table.py

🧰 Additional context used

📓 Learnings (1)

src/django/api/models/moderation_event.py (1)

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#376
File: src/django/api/models/moderation_event.py:60-66
Timestamp: 2024-10-22T11:36:59.787Z
Learning: In the `ModerationEvent` model in `src/django/api/models/moderation_event.py`, setting `on_delete=models.SET_NULL` for the `claim` field is expected behavior.

🔇 Additional comments (4)

src/django/api/models/moderation_event.py (4)

24-50: LGTM! Core fields are well-implemented

The core fields (uuid, timestamps) are properly configured with appropriate indexes and auto-update behavior.

---

52-66: LGTM! Relationship fields follow discussed requirements

The relationship fields are properly configured:

• contributor uses PROTECT to prevent data loss
• claim uses SET_NULL as confirmed in previous discussions
• Related names are properly differentiated

---

123-128: LGTM! Clear string representation

The __str__ method provides a clear and informative representation of the model instance.

---

75-102: ⚠️ Potential issue

Use custom default method for JSON fields

Using default=dict for JSON fields can lead to unexpected behavior due to mutable defaults. Consider using a custom default method:

+def default_dict():
+    return {}
+
 raw_data = models.JSONField(
     null=False,
     blank=False,
-    default=dict,
+    default=default_dict,
     help_text=(
         'Key-value pairs of the non-parsed row and '
         'header for the moderation data.'
     )
 )

Apply similar changes to cleaned_data and geocode_result fields.

Likely invalid or redundant comment.

[vladsha-dev]

Great!
LGTM