-
Notifications
You must be signed in to change notification settings - Fork 1
BDMS-372: data visibility and review feature #292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
chasetmartin
wants to merge
21
commits into
staging
Choose a base branch
from
data-visibility-review-feature
base: staging
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
21 commits
Select commit
Hold shift + click to select a range
92dba17
feat: data visibility and review feature
chasetmartin c26faee
fix: change file name
chasetmartin 3f6e94f
feat: update data visibility and review scenarios for clarity and con…
jirhiker a267088
fix: update validation error status code for new record creation
jirhiker 6494f4d
Merge pull request #298 from DataIntegrationGroup/jir-data-visibility…
jirhiker 19c8bc9
Add legacy business logic to reconcile
kbighorse e5074d4
Refactor public_release.feature to use business language
kbighorse 6f4f781
Rename deprecated `public_release` feature in favor of `release_statu…
kbighorse 6cbce07
Implement feature with integration tests
kbighorse b006a78
Implement non-passing integration tests for release_status
kbighorse 7e8dfb7
Implement release_status filtering for data visibility control
kbighorse 98847d1
Add unit tests for release_status filtering logic
kbighorse 5d0d31f
Fix test infrastructure for scenario isolation
kbighorse dc80fa2
Formatting changes
kbighorse ef3a484
feat: align data visibility/review feature with release_status legacy…
chasetmartin 103ee6e
feat: update functioning api and model given to be more explicit abou…
chasetmartin b94a42f
fix: update default authentication and cascading language per comments
chasetmartin 650b3e7
fix: continued rework of scenario wording for authenticated staff and…
chasetmartin d295b8d
fix: minor typo in given statement
chasetmartin c6dfcee
fix: staff permission in review management
chasetmartin e9bb418
Merge pull request #312 from DataIntegrationGroup/cm-data-visibility-…
chasetmartin File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,98 @@ | ||
| # Data Visibility Feature Files | ||
|
|
||
| This directory contains feature files documenting data visibility and access control requirements during the ongoing migration from AMPAPI's legacy model to NMSampleLocations' new design. | ||
|
|
||
| ## Active Migration: Three Approaches | ||
|
|
||
| ### 1. AMPAPI Legacy (`public_release.feature`) | ||
| **Model:** Single `PublicRelease` Boolean field | ||
| - `True` = public, `False`/`NULL` = private | ||
| - 21 scenarios, fully implemented with unit tests | ||
| - Binary decision: data is either public or not | ||
|
|
||
| ### 2. NMSampleLocations Current (in codebase) | ||
| **Model:** Single `release_status` enum field (default: "draft") | ||
| - Values: draft, provisional, final, published, public, private, archived | ||
| - ⚠️ Field exists but filtering NOT implemented | ||
| - ⚠️ All data currently visible to all users | ||
| - Workflow stages implied but not enforced | ||
|
|
||
| ### 3. NMSampleLocations Proposed (`data-visibility-and-review.feature`) | ||
| **Model:** Two separate fields for independent control | ||
| - `visibility`: "internal" | "public" (who can see it) | ||
| - `review_status`: "provisional" | "approved" (quality status) | ||
| - Both fields REQUIRED, no defaults | ||
| - Supports four combinations (e.g., public+provisional, internal+approved) | ||
|
|
||
| ## Migration Path: Two-Field Design (Recommended) | ||
|
|
||
| **Adopt the two-field approach** - separates "who can see" from "data quality" | ||
|
|
||
| ### Current Implementation Mapping | ||
|
|
||
| **AMPAPI → NMSampleLocations (implemented in transfers/):** | ||
| ``` | ||
| PublicRelease Boolean → release_status | ||
| --------------------|------------------ | ||
| True → "public" | ||
| False/NULL → "private" | ||
| (new records) → "draft" (default) | ||
| ``` | ||
|
|
||
| **Proposed Two-Field Design:** | ||
| ``` | ||
| Current release_status → (visibility, review_status) | ||
| ---------------------------------------------------- | ||
| draft → (internal, provisional) | ||
| provisional → (internal, provisional) | ||
| final → (internal, approved) | ||
| published → (public, approved) | ||
| public → (public, approved) | ||
| private → (internal, approved) | ||
| archived → (internal, approved) | ||
| ``` | ||
|
|
||
| **Business Concepts (from `public_release.feature`):** | ||
| - "public data" = data visible to unauthenticated users | ||
| - "private data" = data visible only to authenticated staff | ||
| - "draft data" = work in progress, staff only | ||
|
|
||
| ### Key Business Rules to Implement | ||
|
|
||
| From refactored scenarios in `public_release.feature`: | ||
| - Public users see only public data | ||
| - Staff see ALL data (public, private, draft) | ||
| - New data defaults to safe visibility (private or draft) | ||
| - Data can be changed from private to public (and vice versa) | ||
| - Visibility filtering is consistent across all endpoints (API, GeoJSON, maps, reports) | ||
| - Associated data inherits visibility from parent location | ||
| - Bulk visibility changes supported for projects | ||
|
|
||
| ### Implementation Status | ||
| - [x] Schema design documented | ||
| - [x] Legacy scenarios documented (`public_release.feature`) | ||
| - [x] New design scenarios documented (`data-visibility-and-review.feature`) | ||
| - [ ] Add `visibility` and `review_status` columns to models | ||
| - [ ] Migrate existing `release_status` data to new fields | ||
| - [ ] Implement filtering in routers (public vs. internal users) | ||
| - [ ] Add unit tests for all scenarios | ||
| - [ ] Update API schemas | ||
| - [ ] Deprecate `release_status` field | ||
|
|
||
| ## File Status | ||
|
|
||
| - **`release_status.feature`** - Refactored from AMPAPI, 16 scenarios adapted to NMSampleLocations | ||
| - Uses business language (public/private) instead of technical fields | ||
| - Maps AMPAPI `PublicRelease` Boolean → NMSampleLocations `release_status` values | ||
| - Updated terminology: AMPAPI concepts → NMSampleLocations concepts | ||
| - Implemented as non-passing integration tests (requires filtering implementation) | ||
| - **`data-visibility-and-review.feature`** - Proposed two-field design, 3 active scenarios | ||
| - Other .feature files - Existing NMSampleLocations integration tests (unrelated to visibility) | ||
|
|
||
| ## Next Steps | ||
|
|
||
| 1. Add new columns to ReleaseMixin | ||
| 2. Create Alembic migration with data transformation | ||
| 3. Implement router filtering based on `visibility` | ||
| 4. Port AMPAPI unit test approach to validate scenarios | ||
| 5. Update client apps (Ocotillo, Weaver) to use new fields | ||
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrapping my head around this file/workflow. I feel like this migration step assumes the existing 'release_status' field properly migrates the legacy scenarios, so is that the first step in this process? Like ensuring testing and documenting:
and then moving on to:
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, step 1. is now theoretically accomplished by this commit: e5074d4?new_files_changed=true
step 2 will follow.