Skip to content

refactor(entities.record): Don't include if an older version file is restricted - #652

Merged
kpsherva merged 1 commit into
CERNDocumentServer:masterfrom
sakshamarora1:fix/add_scientific_community
Oct 16, 2026
Merged

kpsherva merged 1 commit into
CERNDocumentServer:masterfrom
sakshamarora1:fix/add_scientific_community

Conversation

@sakshamarora1

Copy link
Copy Markdown
Contributor

fixes: #542

def has_any_restricted_file(self):
"""True if any of the legacy files carries a restriction status."""
return any(file.get("status") for file in self.dojson_entry.get("files", []))
return any(file.get("status") for file in self.raw_dump_entry.get("files", []))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you explain why switching this makes the difference? dojson entry normally should not manipulate the files key, only the marc

@sakshamarora1 sakshamarora1 Oct 16, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because dojson_entry only has data from the latest version, and now we're checking for restricted files across all versions

timestamp, dojson_entry = dump.latest_revision

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is latest revision of the legacy record (history of changes on metadata of the records), not the RDM versions information. The files should be the same in both cases. Can you recheck?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, so on further checking I found out that dojson_entry doesn't carry files key.
When I updated the test to be exactly like the new flow of the code, it got caught, so using without raw_dump_entry without the get operator is the correct fix. Otherwise it was falling back to an empty list of files.

@sakshamarora1
sakshamarora1 force-pushed the fix/add_scientific_community branch from 0fe2fde to 9764cd4 Compare October 16, 2026 12:19
@kpsherva
kpsherva merged commit 8e6bcd3 into CERNDocumentServer:master Oct 16, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Migration workflow: add research types to CERN_SCIENTIFIC_COMMUNITY

2 participants