-
Notifications
You must be signed in to change notification settings - Fork 0
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
Finally implement row review #146
Conversation
@jthompson-arcus Maybe good to discuss the conceptual UI implementation together. |
I am happy for all input on the UI implementation. There are several ways it could go and no clear best option. |
Merge branch 'jt-99-review_by_row' into jt-99-review_by_row_for_reals # Conflicts: # R/mod_review_forms.R
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.
It's kind of the opposite. It's because the datatables are not rendered yet. @LDSamson this was hard to fix earlier in the process, but with how the code is currently setup we can handle it easier on the server side. |
observeEvent(show_all(), { | ||
req(table_data(), datatable_rendered()) | ||
reload_data(reload_data() + 1) | ||
index <- match("subject_id", colnames(table_data())) - 1 | ||
if (show_all()) { | ||
DT::showCols(table_proxy, index) | ||
} else { | ||
DT::hideCols(table_proxy, index) | ||
} | ||
}) |
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.
Can't we just hide the o_reviewed column when show_all is on? I get that you want to implement the feature to review data of all subjects in one form, but right now its not functional and hiding the check boxes feels more natural to me. Maybe then you can even remove the disabled
column/logic for now (you can always reintroduce it when its needed for reviewing all subjects in a form).
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.
In what way is it not functional right now?
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.
We can also do this in a follow-up PR if you think this is a good idea.
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.
Sure, but unless I know what's not functioning, it will be pretty hard to fix.
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 'not functional' I meant the enhancement mentioned in #22 (reviewing data of all subjects at the same time in a form) is not yet functional. This question was not about fixing anything, but more about just hiding the review column when viewing all subjects.
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.
Got it.
I think we should leave the column visible because the checkboxes are disabled for all subjects not currently being reviewed. The current functionality is consistent with how reviews worked previously.
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.
Hmm do you have a specific reason to leave the column visible? Are there specific benefits that I am missing? I will try to explain. For me personally, having the check boxes visible when viewing all subjects feels a bit awkward since viewing all subjects is about viewing general trends, not about reviewing one subject's data. Hiding the check boxes feels more natural in such a state. Furthermore, the disabled state is a bit hard to see, and it is not immediately clear at a first glance as to why they are disabled, which can cause confusion.
@aclark02-arcus what do you think here?
Again, we can discuss later as well, it is not a deal breaker since it all works, it's more about optimization/user experience. I can also ask some feedback from users internally first.
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 do see @LDSamson's point. Users probably wouldn't consider reviewing the selected patient while viewing all patients. So from that perspective, I see why hiding the Review Status
column would cause less confusion. However, I could go either way with this one.
One thing that is WAY more confusing (to me) when expanding to show all patients is that all patient data (1) doesn't show the existing patient first and (2) the rows aren't sorted by patient. Everything is just kind of "jumbled". Sorry, I know this isn't really related to the topic at hand. 🤷🏼♂️
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.
Couple of comments:
- We do not disable the overall review button. In my opinion, if we want to remove row review, we need to disable reviews period. Otherwise it gets way too tricky. For example, if a user clicked on a couple rows and then wanted to check some data against the population, what should we do? Remove his checks? Allow him to click submit review on the partial review they initiated? Feels like we would needlessly be complicating this process and opening it to bugs.
- Currently the active review is being maintained when a user clicks "Show all participants". I think this is the most desirable outcome. If we were not to preserve the active review, we would at least need to display a modal letting the user know the effects from clicking the toggle.
We can of course discuss this further, but I think a change like this should be a different PR.
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 would not change the active_review_state (better name for o_reviewed?), which I did not propose to do here and which I think does not happen after hiding the review column. Everything will be as before after switching back to only showing one patient. I agree that that is the most desirable.
Yes, we can also disable the overall review button for consistency. And yes, I think this can be a different PR as I stated before.
Things to consider for a change, but can be a follow up PR:
|
@aclark02-arcus do you have any comments on this PR? |
Yes, it's beautiful! @LDSamson, we've been using this internally now for a while... well, a version of this PR, before its the review function was modularized which is a really nice touch. Huge improvement! It has my blessing. |
Merge branch 'dev' into jt-99-review_by_row_for_reals # Conflicts: # R/mod_common_forms.R # R/mod_study_forms.R # tests/testthat/_snaps/app_feature_01/app-feature-1-002.json # tests/testthat/_snaps/app_feature_01/app-feature-1-002_.png # tests/testthat/_snaps/app_feature_01/app-feature-1-003.json # tests/testthat/_snaps/app_feature_01/app-feature-1-004.json # tests/testthat/_snaps/app_feature_01/app-feature-1-004_.png # tests/testthat/_snaps/app_feature_01/app-feature-1-005.json # tests/testthat/_snaps/app_feature_01/app-feature-1-005_.png # tests/testthat/_snaps/app_feature_03/app-feature-3-002.json # tests/testthat/_snaps/mod_study_forms/study_forms-001.json # tests/testthat/_snaps/mod_study_forms/study_forms-002.json
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.
Thanks for adding the comments in the javascript section.
I think we should proceed with merging this PR. There are some things that can be optimized (see all the comments), but that can be done in future PRs.
One thing that is in my opinion most important after merging this, is creating new unit tests/ end to end tests to capture the new behavior. All major features should be tested (ideally using the same BDD test descriptions as used before) before we can use the version in production.
Closes #99