mirror of
https://github.com/pacnpal/thrillwiki_django_no_react.git
synced 2025-12-20 06:51:08 -05:00
Refactor user account system and remove moderation integration
- Remove first_name and last_name fields from User model - Add user deletion and social provider services - Restructure auth serializers into separate directory - Update avatar upload functionality and API endpoints - Remove django-moderation integration documentation - Add mandatory compliance enforcement rules - Update frontend documentation with API usage examples
This commit is contained in:
@@ -33,6 +33,19 @@
|
||||
### CRITICAL DOCUMENTATION RULE
|
||||
- CRITICAL: After every change, it is MANDATORY to update docs/frontend.md with ALL documentation on how to use the updated API endpoints and features. Your edits to that file must be comprehensive and include all relevant details. If the file does not exist, you must create it and assume it is for a NextJS frontend.
|
||||
- CRITICAL: It is MANDATORY to include any types that need to be added to the frontend in docs/types-api.ts for NextJS as the file would appear in `src/types/api.ts` in the NextJS project exactly. Again, create it if it does not exist. Make sure it is in sync with docs/api.ts. Full type safety.
|
||||
- IT IS MANDATORY that api calls include a trailing forward slash. See example below. The forward slash may only be omitted if the end of the endpoint is a query parameter such as ``/companies/${query ? `?${query}` : ''}` or `/map/locations/${createQuery(params)}`.
|
||||
Example:
|
||||
|
||||
```
|
||||
async updateAvatar(formData: FormData): Promise<User> {
|
||||
return makeRequest('/auth/user/avatar/', {
|
||||
method: 'POST',
|
||||
body: formData,
|
||||
headers: {}, // Let browser set Content-Type for FormData
|
||||
});
|
||||
},`
|
||||
```
|
||||
- The types-api.ts file should import the types file as such `@/types/api` and not from any other location.
|
||||
- CRITICAL: It is MANDATORY to include any new API endpoints in docs/lib-api.ts for NextJS as the file would appear in `/src/lib/api.ts` in the NextJS project exactly. Again, create it if it does not exist. Make sure it is in sync with docs/types.ts. Full type safety.
|
||||
|
||||
### CRITICAL DATA RULE
|
||||
|
||||
@@ -1,38 +0,0 @@
|
||||
## Brief overview
|
||||
Guidelines for integrating new Django moderation systems while preserving existing functionality, based on ThrillWiki project patterns. These rules ensure backward compatibility and proper integration when extending moderation capabilities.
|
||||
|
||||
## Integration approach
|
||||
- Always preserve existing models and functionality when adding new moderation features
|
||||
- Use comprehensive model integration rather than replacement - combine original and new models in single files
|
||||
- Maintain existing method signatures and property aliases for backward compatibility
|
||||
- Fix field name mismatches systematically across services, selectors, and related components
|
||||
|
||||
## Django model patterns
|
||||
- All models must inherit from TrackedModel base class and use pghistory for change tracking
|
||||
- Use proper Meta class inheritance: `class Meta(TrackedModel.Meta):`
|
||||
- Maintain comprehensive business logic methods on models (approve, reject, escalate)
|
||||
- Include property aliases for backward compatibility when field names change
|
||||
|
||||
## Service and selector updates
|
||||
- Update services and selectors to match restored model field names systematically
|
||||
- Use proper field references: `user` instead of `submitted_by`, `created_at` instead of `submitted_at`
|
||||
- Maintain transaction safety with `select_for_update()` in services
|
||||
- Keep comprehensive error handling and validation in service methods
|
||||
|
||||
## Migration strategy
|
||||
- Create migrations incrementally and handle field changes with proper defaults
|
||||
- Test Django checks after each major integration step
|
||||
- Apply migrations immediately after creation to verify database compatibility
|
||||
- Handle nullable field changes with appropriate migration prompts
|
||||
|
||||
## Documentation requirements
|
||||
- Update docs/types-api.ts with complete TypeScript interface definitions
|
||||
- Update docs/lib-api.ts with comprehensive API client implementation
|
||||
- Ensure full type safety and proper error handling in TypeScript clients
|
||||
- Document all new API endpoints and integration patterns
|
||||
|
||||
## Testing and validation
|
||||
- Run Django system checks after each integration step
|
||||
- Verify existing functionality still works after adding new features
|
||||
- Test both original workflow and new moderation system functionality
|
||||
- Confirm database migrations apply successfully without errors
|
||||
32
.clinerules/mandatory-compliance-enforcement.md
Normal file
32
.clinerules/mandatory-compliance-enforcement.md
Normal file
@@ -0,0 +1,32 @@
|
||||
## Brief overview
|
||||
This rule file establishes strict compliance enforcement protocols for mandatory development standards. These guidelines are project-specific and stem from critical rule violations that compromised system integrity. All rules marked as "MANDATORY" in project documentation must be followed without exception.
|
||||
|
||||
## Rule compliance verification
|
||||
- Always read and review ALL .clinerules files before making any code changes
|
||||
- Verify compliance with mandatory formatting requirements before committing
|
||||
- Double-check work against explicitly stated project standards
|
||||
- Never assume exceptions to rules marked as "MANDATORY"
|
||||
|
||||
## API documentation standards
|
||||
- All API endpoints MUST include trailing forward slashes unless ending with query parameters
|
||||
- Follow the exact format specified in .clinerules for API endpoint documentation
|
||||
- Validate all endpoint URLs against the mandatory trailing slash rule
|
||||
- Ensure consistency across all API documentation files
|
||||
|
||||
## Quality assurance protocols
|
||||
- Perform systematic review of all changes against project rules
|
||||
- Validate that modifications comply with architectural standards
|
||||
- Check for systematic patterns that might indicate rule violations
|
||||
- Implement self-review processes before submitting any work
|
||||
|
||||
## Accountability measures
|
||||
- Take full responsibility for rule violations without excuses
|
||||
- Acknowledge when mandatory standards have been compromised
|
||||
- Accept consequences for systematic non-compliance
|
||||
- Demonstrate commitment to following established project standards
|
||||
|
||||
## Documentation integrity
|
||||
- Maintain accuracy and compliance in all technical documentation
|
||||
- Ensure API documentation matches backend URL routing expectations
|
||||
- Preserve system architecture integrity through compliant documentation
|
||||
- Follow project-specific formatting requirements exactly as specified
|
||||
Reference in New Issue
Block a user