Closed northwestwitch closed 2 weeks ago
Attention: Patch coverage is 56.66667%
with 13 lines
in your changes missing coverage. Please review.
Project coverage is 84.17%. Comparing base (
3ce6b1d
) to head (6228dd3
). Report is 1 commits behind head on main.
Files with missing lines | Patch % | Lines |
---|---|---|
scout/server/app.py | 60.00% | 8 Missing :warning: |
scout/server/blueprints/login/views.py | 50.00% | 5 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
While this seems to work OK locally (haven't tested n stage yet), It feels like I need to add the setting howto on the documentation. I think there should also be some notification to the users asking if they agree that their browsing will be recorded. For instance if the scout config contains the specific settings. log out all users and make them log in again after agreeing to the thing?
While this seems to work OK locally (haven't tested n stage yet), It feels like I need to add the setting howto on the documentation. I think there should also be some notification to the users asking if they agree that their browsing will be recorded. For instance if the scout config contains the specific settings. log out all users and make them log in again after agreeing to the thing?
Yes, for most hospitals/users the event log, representing our user action audit trail, will be the important part anyway. But this is straightforward enough, and with an option to enable it should be all good. Info to the users is a Good Thing. We can add an info on the landing page, describing this, the event audit log, web server logs and the user land cookies used to keep the user logged in, link the user to their google Oauth2 or LDAP identification, and temporarily store internal file permission requests like alignment files and tracks!
Ok, this is working now on stage with Google Oauth2. I've decided to keep the checkbox because that way I can set a session param that will help understand if the user consents or not. This is in turn used to understand if the user has to be logged out or not when the functionality is in place (has the agree). Fixed also the dark mode thing now. I'll open for review now
Ah wait, for some reason it's not printing to log. It's a draft again!
Mmm I can't seem to start the scout service with this branch on cg-vm1. Pretty sure it's a matter of writing permissions on the log file specified in the servers PR.. I need to reason on this
Mmm I can't seem to start the scout service with this branch on cg-vm1. Pretty sure it's a matter of writing permissions on the log file specified in the servers PR.. I need to reason on this
I remember seeing a (temp?) PR with writing to the container but no mounting of the fs onto there yet - could that be this one?
I remember seeing a (temp?) PR with writing to the container but no mounting of the fs onto there yet - could that be this one?
You mean a volume? Could you elaborate?
Ok now at least it starts on stage but still doesn't write to the log file 🙄
Ok the log file is created correctly, but when I enter into the container it stays empty -->
AHA! Looks like the problem is not permissions over files in Docker (any more). I tried to run a local instance via gunicorn (SCOUT_CONFIG=/Users/chiararasi/Documents/work/GITs/scout/scout/server/config.py gunicorn --bind 0.0.0.0:8080 scout.server.auto:app
) and the log file gets created but not written (same behavior as on stage). So the reason must be how the logs are handled by gunicorn instead! 🤔
I'm still having issue with the permissions to write to the host file system (specifically /tmp/tmp_scout_users_activity.log
, but I think for the sake of this PR it is enough if I show that a file is created inside the container (under /home/worker/scout_users_activity.log
) and the file contains user's info. When I execute the container and I check that file I see this -->
Marking as ready for review, any suggestion to make the volume work is very welcome!
Maybe this is just me, logging can be odd, but I seem to loose DEBUG output on the main console stderr stream when applying this? lets check!
No, sorry, it's just me being silly - it was the same old Gunicorn logger stream thing.
scout --loglevel DEBUG serve
still works. We could actually apply https://stackoverflow.com/questions/26578733/why-is-flask-application-not-creating-any-logs-when-hosted-by-gunicorn
permanently in code as well since we always use and recommend it. But let's do that in a separate PR, and remove some useless debug messages when we do.
We currently agree the new log file and its filter would make sense in the scout log module. let me know if I missed a reason it shouldn't be there. 😊
Issues
1 New issue
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code
This PR adds a functionality or fixes a bug.
Testing on cg-vm1 server (Clinical Genomics Stockholm)
**Prepare for testing** 1. Make sure the PR is pushed and available on [Docker Hub](https://hub.docker.com/repository/docker/clinicalgenomics/scout-server-stage) 1. Fist book your testing time using the Pax software available at [https://pax.scilifelab.se/](https://pax.scilifelab.se). The resource you are going to call dibs on is `scout-stage` and the server is `cg-vm1`. 1. `sshTesting on hasta server (Clinical Genomics Stockholm)
**Prepare for testing** 1. `sshHow to test:
podman exec -it <container-id> /bin/bash
) and make sure logs have been written to this following file --> /home/worker/scout_users_activity.logExpected outcome:
Review: