ADORSYS-GIS / ADORSYS-GIS/CoopData
User-Facing Legal, Privacy & Consent Management
- 主要言語
- TypeScript
- スター
- 4
- フォーク
- 0
- 平均マージ
- 20時間 22分
- マージ済み PR(30日)
- 48
説明
# Ticket: User-Facing Legal, Privacy & Consent Management
**Priority:** High
**Type:** Feature / Compliance
**Component:** Frontend + Backend
## Description
Implement a complete user-facing legal and privacy section for CoopData to ensure users are clearly informed about how their personal and organizational data is collected, processed, stored, and used.
The platform should provide users with access to the relevant legal documents and require appropriate acceptance during account registration. The system must also maintain a versioned record of the policies accepted by each user.
## Business Value
CoopData processes personal, organizational, and potentially sensitive financial information. Providing clear legal documentation and auditable consent management improves transparency, user trust, and compliance readiness.
It also ensures that the platform can demonstrate which version of its Terms and Privacy Policy a user accepted and when.
## Scope
### 1. Legal Documents
Create dedicated, publicly accessible pages for:
* **Privacy Policy**
* **Terms of Service**
* **Cookie Policy**
* **Acceptable Use Policy**
* **Security & Data Protection**
* **Data Retention Policy**
The documents should be accessible without requiring authentication where appropriate.
### 2. Registration Consent
Update the registration flow to include mandatory acceptance of the Terms of Service and acknowledgment of the Privacy Policy.
Example:
> ☐ I agree to the Terms of Service and acknowledge the Privacy Policy.
The document names should be clickable and open the corresponding policy.
Optional marketing/product communications must be handled separately and must not be bundled with mandatory legal acceptance.
Example:
> ☐ I would like to receive product updates and other communications by email.
### 3. Consent Version Tracking
Implement backend storage for policy acceptance.
Each acceptance record should contain at least:
* User ID
* Policy/document type
* Policy version
* Acceptance timestamp
* Optional IP address/session metadata where legally appropriate
Example:
```text
user_id: 123
document: TERMS_OF_SERVICE
version: 2.1
accepted_at: 2026-08-24T14:30:00Z
```
Another example:
```text
user_id: 123
document: PRIVACY_POLICY
version: 1.4
accepted_at: 2026-08-24T14:30:00Z
```
### 4. Policy Versioning
Policies must have explicit versions.
For example:
```text
Terms of Service
Version 2.1
Effective: August 24, 2026
```
When a policy is materially updated, users should be prompted to review and accept the new version where required.
Previous acceptance records must not be overwritten.
### 5. User Privacy & Security Settings
Add a **Privacy & Security** section to account settings.
Users should be able to see:
* Current Terms of Service version
* Accepted Terms version
* Terms acceptance date
* Current Privacy Policy version
* Privacy Policy acceptance date
* Cookie preferences where applicable
Example:
```text
Privacy & Security
Terms of Service
Version 2.1
Accepted on August 24, 2026
Privacy Policy
Version 1.4
Accepted on August 24, 2026
[View Terms]
[View Privacy Policy]
```
### 6. Privacy Requests
Provide mechanisms for users to initiate applicable privacy requests, including:
* Request personal data
* Request correction of personal data
* Request account deletion
Requests should be securely authenticated and tracked by the backend.
### 7. Footer / Legal Navigation
Add a consistent legal section to the application footer.
Example:
```text
Legal
Privacy Policy
Terms of Service
Cookie Policy
Acceptable Use Policy
Security & Data Protection
Data Retention Policy
```
## Technical Requirements
### Backend
Create a policy/consent model capable of storing:
```text
id
user_id
document_type
document_version
accepted_at
created_at
```
Optional metadata may include:
```text
ip_address
user_agent
```
subject to applicable privacy requirements.
Create APIs for:
* Retrieving currently active policies
* Recording user acceptance
* Retrieving a user's acceptance history
* Checking whether the user has accepted the latest required policies
Authorization must ensure that users can only access their own consent history.
### Frontend
Implement:
* Legal document pages
* Registration consent component
* Policy acceptance modal/page when updated policies require re-acceptance
* Privacy & Security settings page
* Legal footer links
* Cookie preference UI where applicable
## Security Requirements
* Policy acceptance must be recorded server-side.
* The frontend must not be trusted to determine whether a policy was accepted.
* Users must not be able to modify their acceptance timestamps or policy versions.
* Users must not be able to modify another user's consent records.
* Policy versions must be immutable once published.
* Sensitive privacy requests must require authentication.
* Administrative access to policy management must use appropriate RBAC permissions.
## Acceptance Criteria
* [ ] Users can access the Privacy Policy.
* [ ] Users can access the Terms of Service.
* [ ] Users can access the Cookie Policy.
* [ ] Users can access the Acceptable Use Policy.
* [ ] Users can access the Security & Data Protection information.
* [ ] Users can access the Data Retention Policy.
* [ ] Registration requires acceptance of the Terms of Service.
* [ ] Registration requires acknowledgment of the Privacy Policy.
* [ ] Terms and Privacy Policy links are available directly from the registration screen.
* [ ] Optional marketing consent is separate from mandatory legal acceptance.
* [ ] The backend records the accepted policy version.
* [ ] The backend records the acceptance timestamp.
* [ ] Previous acceptance records are preserved when policies are updated.
* [ ] Users can view their current and previously accepted policy versions.
* [ ] Users can access Privacy & Security from their account settings.
* [ ] Users can initiate applicable data/privacy requests.
* [ ] Unauthorized users cannot modify or access another user's consent records.
* [ ] Updated policies can trigger a new acceptance requirement.
* [ ] Legal documents are accessible from the application footer.
* [ ] All policy pages are responsive and accessible.
* [ ] Policy acceptance and privacy functionality are covered by automated tests.
## Definition of Done
* [ ] All legal pages are implemented.
* [ ] Backend policy and consent models are implemented.
* [ ] API endpoints are documented in OpenAPI.
* [ ] Registration flow includes legal consent.
* [ ] Consent versioning is implemented.
* [ ] Privacy & Security settings are implemented.
* [ ] RBAC and authorization are tested.
* [ ] Unit and integration tests pass.
* [ ] Frontend and backend CI pipelines pass.
* [ ] Legal content has been reviewed and approved by the appropriate legal/compliance stakeholders.
* [ ] Feature has been demonstrated and acceptance criteria verified.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
Start by mapping the existing registration flow, account settings, footer, backend API, OpenAPI, and CI entry points; no files or tests are named in the issue. Treat the acceptance criteria and Definition of Done as the checklist: legal pages, server-side versioned consent, privacy requests, authorization tests, documented APIs, passing automated checks, and legal/compliance approval.
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- openapi, typescript
- 領域
- api, authentication, authorization, backend, content, documentation, frontend, security
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 活発
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 25/100