-
Notifications
You must be signed in to change notification settings - Fork 6
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
#2350: Generate survey files async #2362
Conversation
c9ee306
to
02a9384
Compare
f08c2b8
to
b633f1a
Compare
First of all, sorry for the huge PR. Things got wild. Here's my list of pending things, which we may want to move to a different issue/PR.
I'll try to address some of these while we review the PR. |
06aad77
to
a12192f
Compare
instead of Questionnaire
We should un-skip them by the end of the PR. See #2350
The info about the generated files is still pending. See #2350
This will allow us to check if there already is a file generated or not. Also, we move the decision of whether to regenerate a file or not to the user (instead of checking if we should generate the file again or not). See #2350
From the UI, request that the CSV files are generated by the backend. We still miss checking if the files exist or are currently being generated. See #2350
Small changes, nothing too relevant. See #2350
There's probably still an issue with react-timeago not being properly ignored yet. See #2350
There are no definitions available. See #2350
Thanks, eslint! See #2350
They've already been solved or there's nothing to do about them.
They were previously placed in a public directory, statically served. We now apply the usual access control we have for generation (and had for streaming). See #2350
Those URLs in the RespondentIndex.jsx smelled. See #2350
Due to the way the `q` variable was bound in the previous implementation of the `setInterval` call, we were always querying the file status using the filter (or lack thereof) that was in place in the first show of the modal. We now get the current value of `q` at the time in which the refresh function is called. See #2350
They were already working - not sure when they were fixed but that's fine. See #2350
a12192f
to
d5ceb9a
Compare
7aeabb7
to
c9ba84b
Compare
|
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.
I cannot officially approve this PR since I was the original author, but this looks good to me! ✨
@matiasgarciaisaia I would encourage we deploy a preview of this branch to staging so we can play with it a bit without having to set it up in each of our local environments 😬
|
||
ActivityLog.download(project, conn, survey, "survey_results") |> Repo.insert() | ||
ActivityLog.generate_file(project, conn, survey, "survey_results") |> Repo.insert() |
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.
following the naming normalization perhaps we can change the ActivityLog entry to register respondents_results
instead of survey_results
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.
I wanted to keep the files themselves backwards-compatible. Changing these names would imply running a migration to change old activity logs from the DB. Which could be OK, but these are not exactly the same strings used "internally". We should also take a look at including the filter, somehow, for the results file - here we're completely ignoring whether there's a filter or not.
|
||
SurveyResults.generate_disposition_history_file(survey.id) | ||
|
||
ActivityLog.generate_file(project, conn, survey, "disposition_history") |> Repo.insert() |
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.
should we create en enum or constants with the different file names so we avoid repeating the strings all over?
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.
With the last changes the files modal behaves as expected - even changing between different surveys. ✅
However, what I've noticed is that once the user opens the "download files" modal, the app keeps on requesting the /files
status - even if the user has closed the modal. This is not critical, but it's useless. Even more because if the user opens the modal again, a new request is triggered
Yes. We don't have (or I haven't found) an event for when the modal closes, so the requests keep going every 20 seconds even when we don't need them. |
Changes
SurveyResults
GenServerRespondentController
to newSurveyResults
actorcsv
format)Out of scope
for #2350