Allow embargoed products to still be listed#48
Conversation
rgov
left a comment
There was a problem hiding this comment.
I'm taking your word for it that it works. It seems relatively straightforward.
I worry about the implicit constraints that we have that, say, there aren't overlapping cruises. Having to scan the database every time (on ever request?) to map lowering -> cruise is also very inefficient. I don't think we have a database index for this. The database layer needs to be gutted...
That one is pretty safe since it's unlikely Alvin will ever be on two cruises simultaneously, but it's a house of cards yeah.
Have an agent working on that... hopefully figures it out by the time I wake up next week. |
|
Also cleaned up CI so it can actually build + test on PRs now without attempting a Dockerhub push. |
|
Part of the reason to push to Docker for all PRs was so it could be pulled on an |
Could be useful, but it always failed on PRs (at least on the client side?) because of some auth issue: https://github.com/WHOIGit/ndsf-sealog-client/actions/runs/23510179471/job/68428719568 I think it's using auth you setup and presume your account would have to fix. |
|
For PRs ( |
|
@rgov good to merge then? |
|
Sure |
Embargoed products are now listed on the cruise menu, but only metadata (date, id) is available and message displayed indicating how to get access.
Also adds checks to ensure exported events never include those belonging to a parents lowering or cruise that is hidden. Somewhat complex checks involved because of the nature of the database.