Skip to content

Commit e9bb418

Browse files
chasetmartinchasetmartin
authored
Merge pull request #312 from DataIntegrationGroup/cm-data-visibility-review-feature-update
BDMS-402: data visibility/review feature review
2 parents dc80fa2 + c6dfcee commit e9bb418

1 file changed

Lines changed: 216 additions & 122 deletions

File tree

‎tests/features/data-visibility-and-review.feature‎

Lines changed: 216 additions & 122 deletions
Original file line numberDiff line numberDiff line change
@@ -1,122 +1,216 @@
1-
# Created by marissa at 12/11/2025
2-
# file: tests/features/data_visibility_and_review_backend.feature
3-
4-
@backend @BDMS-XXX
5-
Feature: Manage data visibility separately from review and approval in the backend
6-
As an Ocotillo data manager
7-
I want visibility/privacy and review/approval to be stored as two separate backend attributes
8-
So that the system can independently control who can see the data and which data is reviewed
9-
10-
# Business rules:
11-
# - visibility has two states: "internal" or "public"
12-
# - review_status has two states: "provisional" or "approved"
13-
# - visibility and review_status are REQUIRED when creating new data
14-
# - new data must use visibility and review_status (no new use of legacy fields)
15-
# - legacy combined values will be migrated into visibility and review_status using a documented mapping
16-
17-
Background:
18-
Given a functioning api
19-
And all database models have a visibility field that supports "internal" and "public"
20-
And all database models have a review_status field that supports "provisional" and "approved"
21-
And visibility and review_status are required fields when creating new records
22-
# hard to test?
23-
And new records must use visibility and review_status as the source of truth
24-
And legacy combined visibility/review fields are deprecated
25-
26-
27-
Scenario Outline: Require visibility and review status when creating a new record
28-
When I create a new <model> without specifying visibility or review_status
29-
Then the system should return a 422 status code
30-
And the system should not persist the new dataset
31-
And the error response should indicate that visibility is required
32-
And the error response should indicate that review_status is required
33-
34-
# Given Require visibility and review status when creating a new record. no default for visibility and review
35-
# status will be defined so this is impossible to test
36-
And the error response should not include default values for visibility or review_status
37-
38-
Examples:
39-
|model|
40-
|Well |
41-
|Contact|
42-
|Observation|
43-
44-
Scenario Outline: Migrate legacy combined visibility/review values to separate fields
45-
Given the system has legacy records with a combined visibility/review field for <legacy_table>
46-
And there is a documented mapping from each legacy value to a visibility and review_status pair
47-
When the migration job runs to populate visibility and review_status for <legacy_table> records
48-
Then the system should set visibility according to the documented mapping
49-
And the system should set review_status according to the documented mapping
50-
# hard to test?
51-
And the system should stop using the legacy combined field as the source of truth
52-
And subsequent updates to migrated records should modify visibility and review_status fields only
53-
54-
Examples:
55-
|legacy_table|
56-
|Location |
57-
|WaterLevels |
58-
|WaterLevelsContinuous_Acoustic|
59-
|WaterLevelsContinuous_Pressure|
60-
61-
Scenario: Spot-check migrated legacy records against the documented mapping
62-
Given the migration job has completed
63-
And the tester selects a sample of migrated records with known legacy values
64-
When the tester retrieves each sampled record via the api
65-
Then the visibility value for each sampled record should match the expected mapped visibility
66-
And the review_status value for each sampled record should match the expected mapped review_status
67-
68-
#
69-
# @skip
70-
# @patch
71-
# Scenario: Update visibility for a new dataset without changing review status
72-
# Given the system has a new dataset with visibility "internal" and review_status "provisional"
73-
# When the user updates the dataset visibility to "public" via the api
74-
# Then the system should persist the dataset with visibility "public"
75-
# And the system should preserve the review_status as "provisional"
76-
# And retrieving the dataset via the api should return visibility "public" and review_status "provisional"
77-
#
78-
# @skip
79-
# @patch
80-
# Scenario: Update review status for a new dataset without changing visibility
81-
# Given the system has a new dataset with visibility "internal" and review_status "provisional"
82-
# When an authorized reviewer updates the dataset review_status to "approved" via the api
83-
# Then the system should persist the dataset with review_status "approved"
84-
# And the system should preserve the visibility as "internal"
85-
# And retrieving the dataset via the api should return visibility "internal" and review_status "approved"
86-
#
87-
# @skip
88-
# @authorization
89-
# Scenario: Allow all datasets for internal users
90-
# Given the system has datasets with combinations of:
91-
# | visibility | review_status |
92-
# | internal | provisional |
93-
# | internal | approved |
94-
# | public | provisional |
95-
# | public | approved |
96-
# And the caller is identified as an internal staff user
97-
# When the internal staff user requests those datasets via the api
98-
# Then the system should return all of those datasets in the response
99-
#
100-
# @skip @authorization
101-
# Scenario: Reject unauthorized changes to visibility or review status
102-
# Given the system has a dataset with visibility "internal" and review_status "provisional"
103-
# And the caller is authenticated without permission to change visibility or review_status
104-
# When the caller attempts to update the visibility to "public" via the api
105-
# And the caller attempts to update the review_status to "approved" via the api
106-
# Then the system should return an authorization error for these updates
107-
# And the dataset should remain persisted with visibility "internal" and review_status "provisional"
108-
#
109-
# @skip
110-
# @disclaimer
111-
# Scenario: Include disclaimer information based on review status
112-
# Given the system has a dataset with visibility "public" and review_status "provisional"
113-
# When any authorized caller retrieves the dataset via the api
114-
# Then the system should return a response in JSON format
115-
# And the response should include a disclaimer field derived from the review_status
116-
# And the disclaimer should indicate that the data is provisional
117-
#
118-
# And the system has a dataset with visibility "internal" and review_status "approved"
119-
# When any authorized caller retrieves that dataset via the api
120-
# Then the response should include a disclaimer field derived from the review_status
121-
# And the disclaimer should indicate that the data is approved
122-
#
1+
# Created by marissa at 12/11/2025
2+
# file: tests/features/data_visibility_and_review_backend.feature
3+
4+
@backend @BDMS-XXX
5+
Feature: Manage data visibility separately from review in the backend
6+
As an Ocotillo data manager
7+
I want visibility and review status to be stored as two separate backend attributes
8+
So that the system can independently control who can see the data and which data is reviewed
9+
10+
# Business rules:
11+
# - visibility has two states: "internal" or "public"
12+
# - review_status has two states: "provisional" or "approved"
13+
# - visibility and review_status are REQUIRED when creating new data
14+
# - new data must use visibility and review_status (no new use of legacy fields)
15+
# - legacy combined values will be migrated into visibility and review_status using a documented mapping
16+
# - visibility and review must cover previous release_status business logic
17+
18+
Background:
19+
Given a functioning api
20+
And all database models have a visibility field that determines if a record can or cannot be viewed by the public
21+
And the only possible values for the visibility field are internal and public
22+
And all database models have a review_status field that determines if a record is provisional or approved
23+
And the only possible values for the review_status field are provisional and approved
24+
And visibility and review_status are required fields when creating new records
25+
And new records must use visibility and review_status as the source of truth
26+
And legacy combined visibility/review fields are deprecated
27+
28+
# ---------------------------------------------------------------------------
29+
# PUBLIC ACCESS
30+
# ---------------------------------------------------------------------------
31+
32+
@public_access @visibility
33+
Scenario Outline: Public users can only access public data
34+
Given I am a public API consumer
35+
And there is <data_type> data stored with a visibility field that evaluates to either public or internal
36+
When I request <data_type> data through API endpoints
37+
Then I should only see records where the visibility field is set to public
38+
And records whose visibility field is set to internal should not be returned
39+
And the response should include the review_status for each public record
40+
41+
Examples:
42+
| data_type |
43+
| locations |
44+
| samples |
45+
| observations |
46+
47+
# might not be relevant yet in NMSampleLocations
48+
@public_access @reports
49+
Scenario: Public reports include review status disclaimers
50+
Given I am a public API consumer
51+
And data is stored with visibility public and review_status provisional or approved
52+
When I request a report of observations
53+
Then all returned observations should have visibility public
54+
And provisional observations should include a disclaimer derived from review_status
55+
And approved observations should indicate that they are fully reviewed
56+
57+
# might not be relevant yet in NMSampleLocations
58+
@public_access @data_download
59+
Scenario: Public data downloads exclude internal datasets
60+
Given I am a public API consumer
61+
And the data contains public and internal records with different review_status values
62+
When I requests a CSV export
63+
Then only the public records should be included
64+
And the download should list the review_status for each record
65+
66+
# ---------------------------------------------------------------------------
67+
# AUTHENTICATED STAFF ACCESS
68+
# ---------------------------------------------------------------------------
69+
70+
@staff_access @visibility
71+
Scenario Outline: Staff can access all data and its review status
72+
Given I am an authenticated staff member
73+
And I have permission to view internal data
74+
When I view <data_type> data through API endpoints
75+
Then I should see visibility internal and public records
76+
And I should see whether each record is provisional or approved
77+
78+
Examples:
79+
| data_type |
80+
| things |
81+
| locations |
82+
| samples |
83+
| observations |
84+
85+
@staff_access @management
86+
Scenario: Staff can change visibility without affecting review status
87+
Given I am an authenticated staff member
88+
And I have permission to modify data visibility
89+
And data is stored with visibility internal and review_status provisional
90+
When I update the visibility to public
91+
Then the data visibility should be persisted as public
92+
And the review_status should remain provisional
93+
And retrieving the data should show the updated visibility and original review_status
94+
95+
@staff_access @review_status
96+
Scenario: Staff can approve data without changing visibility
97+
Given I am an authenticated staff member
98+
And I have permission to modify data review status
99+
Given data is stored with visibility public and review_status provisional
100+
When I update the review_status to approved
101+
Then the data should remain visible to the public
102+
And the review_status should be persisted as approved
103+
And the API response should immediately show the approved status
104+
105+
# ---------------------------------------------------------------------------
106+
# DATA SUBMISSION AND WORKFLOW
107+
# ---------------------------------------------------------------------------
108+
109+
@workflow @validation
110+
Scenario Outline: New records require explicit visibility and review status
111+
When I attempt to create a new <data_type> without both visibility and review_status
112+
Then the request should be rejected with a 422 status code
113+
And the error response should indicate that visibility is required
114+
And the error response should indicate that review_status is required
115+
116+
Examples:
117+
| data_type |
118+
| thing |
119+
| contact |
120+
| observation |
121+
122+
@workflow @defaults
123+
Scenario: Safe defaults when both attributes are omitted
124+
Given data is being submitted to the system with visibility and review_status omitted
125+
When the record is created
126+
Then the system should persist visibility internal and review_status provisional by default
127+
128+
@workflow @privacy_protection
129+
Scenario: Contact data is private and protected by default
130+
Given private contact data is being submitted
131+
When the data is entered into the system
132+
Then the data should default to be stored with visibility internal
133+
And the data should default to be stored with review_status provisional
134+
135+
# may need to work this out more
136+
# should we include the legacy table examples?
137+
@workflow @migration
138+
Scenario: Legacy combined values are migrated into separate attributes
139+
Given legacy records exist with a combined visibility/review field
140+
And a documented mapping defines visibility and review_status for each legacy value
141+
When the data transfer migration job runs
142+
Then each record should have visibility populated according to the mapping
143+
And each record should have review_status populated according to the mapping
144+
145+
# ---------------------------------------------------------------------------
146+
# VISIBILITY AND REVIEW MANAGEMENT
147+
# ---------------------------------------------------------------------------
148+
149+
@management @status_change
150+
Scenario: Making internal data public without re-review
151+
Given a <data_type> is currently visibility internal and review_status approved
152+
And staff has the correct permissions to change visibility
153+
When staff changes the visibility to public
154+
Then the <data_type> should become visible to unauthenticated users
155+
And the review_status should remain approved
156+
And associated observations should also reflect the new visibility
157+
158+
Examples:
159+
| data_type |
160+
| thing |
161+
| location |
162+
| sample |
163+
164+
@management @status_change
165+
Scenario: Moving public data back to internal without changing review status
166+
Given a thing is currently visibility public and review_status approved
167+
And a data owner requests privacy
168+
When staff changes the visibility to internal
169+
Then the thing should disappear from public endpoints
170+
And the review_status should continue to show approved
171+
And all associated data should remain approved but hidden
172+
173+
@management @bulk_operations
174+
Scenario: Bulk updates keep visibility and review_status in sync
175+
Given a project has 50 things with visibility internal and review_status provisional
176+
And the project has completed internal review
177+
When staff performs a bulk change to set visibility public and review_status approved
178+
Then all 50 things should become publicly visible
179+
And all 50 things should show review_status approved
180+
181+
# ---------------------------------------------------------------------------
182+
# DATA INTEGRITY AND CONSISTENCY
183+
# ---------------------------------------------------------------------------
184+
185+
@integrity @cascading
186+
Scenario: Visibility restrictions cascade to associated data
187+
Given an internal thing has observations and samples
188+
When a public user queries for data
189+
Then all data associated with that thing should be hidden
190+
And no review_status values for those internal records should be exposed
191+
192+
@integrity @mixed_status
193+
Scenario: Handling different review statuses for public data
194+
Given a thing is visibility public
195+
And individual observations at the thing have review_status provisional and approved
196+
When a public user views the thing data
197+
Then only observations with visibility public should appear
198+
And each observation should clearly display whether it is provisional or approved
199+
200+
# ---------------------------------------------------------------------------
201+
# SPECIAL DATA REPRESENTATION
202+
# ---------------------------------------------------------------------------
203+
204+
@special_cases @defaults
205+
Scenario: Certain data types default to public and provisional
206+
Given certain categories of data are configured to default to visibility public and review_status provisional
207+
When new data of these types is collected
208+
Then the data should be automatically marked as public
209+
And the review_status should be set to provisional until staff approval
210+
211+
@special_cases @representation
212+
Scenario: Visibility and review status are consistently represented
213+
Given a record has visibility and review_status set
214+
When the data is viewed through any interface
215+
Then both fields should be clearly indicated
216+
And the public/private and provisional/approved statuses should be unambiguous

0 commit comments

Comments
 (0)