Skip to content
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

Wire up boundary details page #143

Merged
merged 11 commits into from
Oct 24, 2022
Merged

Conversation

mstone121
Copy link
Contributor

@mstone121 mstone121 commented Oct 19, 2022

Overview

This PR wires up the boundary details page. Some of the data on this page was not present in the data schema so that has been updated as well.

Closes #89

Notes

I not entirely sure what to do about the activity log. It needs more formatting/syntax to match what is in figma. I think this functionality should all be in one place (and not split between the front end and back end).

Testing Instructions

  • Login as a contributor
  • View some boundaries
    • Ensure "Review" button does not appear for boundaries in review or approved
  • Login as validator
  • View some boundaries
    • Ensure "Edit" button does not appear for drafts

Checklist

  • fixup! commits have been squashed
  • CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines
  • README.md updated if necessary to reflect the changes
  • CI passes after rebase

@mstone121 mstone121 force-pushed the ms/wire-up-boundary-details-page branch from fbdc272 to 9c51cec Compare October 19, 2022 21:31
@rajadain
Copy link
Contributor

Will take a look at this after merge conflicts have been fixed

@mstone121
Copy link
Contributor Author

@rajadain Conflicts resolved, ready for review

@rajadain
Copy link
Contributor

Taking a look

Copy link
Contributor

@rajadain rajadain left a comment

Choose a reason for hiding this comment

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

This is headed in the right direction. A few more changes needed to match Figma.

I think this functionality should all be in one place (and not split between the front end and back end).

I agree. Does what the back-end send enough to have this formatting code in the front-end? What would you recommend changing about the back-end response?

src/django/api/models/submission.py Outdated Show resolved Hide resolved
src/app/src/components/Submissions/Detail/Detail.js Outdated Show resolved Hide resolved
src/app/src/components/Submissions/Detail/Map.js Outdated Show resolved Hide resolved
src/django/api/models/user.py Outdated Show resolved Hide resolved
src/app/src/components/Submissions/Badges.js Outdated Show resolved Hide resolved
Copy link
Contributor Author

@mstone121 mstone121 left a comment

Choose a reason for hiding this comment

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

@rajadain Ready for review again. See comments

src/django/api/models/submission.py Outdated Show resolved Hide resolved
src/django/api/models/user.py Outdated Show resolved Hide resolved
src/app/src/components/Submissions/Detail/Detail.js Outdated Show resolved Hide resolved
src/app/src/components/Submissions/Detail/Map.js Outdated Show resolved Hide resolved
src/app/src/components/Submissions/Badges.js Outdated Show resolved Hide resolved
Copy link
Contributor

@rajadain rajadain left a comment

Choose a reason for hiding this comment

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

Great work on this! Just a couple minor adjustments more, otherwise this is good to go.

@rajadain
Copy link
Contributor

Also seeing this behavior where the background is white on scrolling down. Going to take a quick stab at this.

2022-10-24.09.56.21.mp4

@rajadain
Copy link
Contributor

the background is white on scrolling down

This fixes it:

diff --git a/src/app/src/components/Submissions/Detail/Detail.js b/src/app/src/components/Submissions/Detail/Detail.js
index 5b044c6..b91af9b 100644
--- a/src/app/src/components/Submissions/Detail/Detail.js
+++ b/src/app/src/components/Submissions/Detail/Detail.js
@@ -18,6 +18,7 @@ import Info from './Info';
 import Map from './Map';
 import { useEndpointToastError } from '../../../hooks';
 import { useStartReviewMutation } from '../../../api/reviews';
+import { NAVBAR_HEIGHT } from '../../../constants';
 
 export default function SubmissionDetail() {
     const navigate = useNavigate();
@@ -56,7 +57,7 @@ export default function SubmissionDetail() {
             bg='gray.50'
             align='stretch'
             divider={<StackDivider />}
-            h='100vh'
+            minH={`calc(100vh - ${NAVBAR_HEIGHT}px)`}
         >
             <Flex mb={7}>
                 <Flex direction='column' w='50%'>

Copy link
Contributor

@rajadain rajadain left a comment

Choose a reason for hiding this comment

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

Actually there are a couple missing features:

  1. When the Boundary is in Needs Revisions, the Contributor should be able to "Revise boundary". Also the info box should be orange, not green.
    Current:
    image
    Wireframe:
    image
  2. For Validators, there should no info box. Also, they should have an Approve button in the top right.
    Wireframe:
    image

case BOUNDARY_STATUS.NEEDS_REVISIONS:
return getReviewDetailText(boundary.submission.review);
case BOUNDARY_STATUS.APPROVED:
return 'Your map has been approved.';
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed from this to your to match Figma.

Comment on lines 179 to 192
const getBarColor = () => {
switch (boundary.status) {
case BOUNDARY_STATUS.SUBMITTED:
return 'teal';
case BOUNDARY_STATUS.IN_REVIEW:
return 'This map will be reviewed.';
case BOUNDARY_STATUS.NEEDS_REVISIONS:
return 'This map needs revisions.';
return 'orange';
case BOUNDARY_STATUS.APPROVED:
return 'This map has been approved.';
return 'green';
default:
throw new Error(`Unexpected status ${status}`);
return null;
}
};
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This diff is confusing. getBarColor looks like this

    const getBarColor = () => {
        switch (boundary.status) {
            case BOUNDARY_STATUS.SUBMITTED:
                return 'teal';
            case BOUNDARY_STATUS.IN_REVIEW:
            case BOUNDARY_STATUS.NEEDS_REVISIONS:
                return 'orange';
            case BOUNDARY_STATUS.APPROVED:
                return 'green';
            default:
                return null;
        }
    };

This leads to a mismatch between the badge colors and the submission bar color. SUBMITTED and IN_REVIEW have the same status bar text, so I figured they should have the same color as well.

I assumed APPROVED should be green, but maybe we don't need a status bar when a boundary is approved.

Copy link
Contributor

Choose a reason for hiding this comment

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

maybe we don't need a status bar when a boundary is approved.

Correct on the green. There is a bar for approved boundaries, shown here:

image

@mstone121
Copy link
Contributor Author

c9d657d - Validator Approve button

Should administrator also see this?

@rajadain
Copy link
Contributor

Should administrator also see this?

Yes

@mstone121
Copy link
Contributor Author

Also regarding the "Mark approved" button: I couldn't find an empty circle hero icon so I used the checked circle instead.

@rajadain
Copy link
Contributor

Going to take another look

Copy link
Contributor

@rajadain rajadain left a comment

Choose a reason for hiding this comment

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

+1 tested, nice work capturing all the different moving parts to this. I made #151 for handling the actual approval process.

A couple last minor comments to get this working, then this should be good to merge.

Comment on lines 153 to 154
case BOUNDARY_STATUS.SUBMITTED:
case BOUNDARY_STATUS.IN_REVIEW:
return 'Your map will be reviewed.';
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
case BOUNDARY_STATUS.SUBMITTED:
case BOUNDARY_STATUS.IN_REVIEW:
return 'Your map will be reviewed.';
case BOUNDARY_STATUS.SUBMITTED:
return 'Your map will be reviewed.';
case BOUNDARY_STATUS.IN_REVIEW:
return 'Your map is being reviewed.';

};

const getReviewDetailText = review => {
const commentCount = review.comments.length;
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
const commentCount = review.comments.length;
const commentCount = review.annotations.length;

Matt Stone added 3 commits October 24, 2022 14:15
Making the SubmissionStatusBar a hook allows its return value to be
checked for null. If it were a component, the parent (in this case Map),
would need to determine whether or not it should render. This would
involve repeating much of the logic that already exists in theS
SubmissionStatusBar.
@mstone121 mstone121 force-pushed the ms/wire-up-boundary-details-page branch from d5af311 to 2a1dbf8 Compare October 24, 2022 19:16
@mstone121 mstone121 merged commit c087c57 into develop Oct 24, 2022
@mstone121 mstone121 deleted the ms/wire-up-boundary-details-page branch October 24, 2022 19:21
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.

Wire up Boundary Detail Page
2 participants