search

SolutionGuidance / psm

Welcome to the Medicare/Medicaid Provider Enrollment Screening Portal
http://projectpsm.org/
Other
26 stars 20 forks source link

Remove provider statement date #1023

Closed jasonaowen closed 6 years ago

jasonaowen commented 6 years ago

The last page of the enrollment application process is for the user to sign a provider statement. Previously, we included the date on that page, and required the user to type in today's date.

It turns out this is neither necessary nor useful. We don't require it for legal reasons. It's bad UX, because there's only one acceptable answer, and the system knows what it is. Additionally, if an admin needs to later edit the application, they were sometimes forced to update the signature date, which is both annoying and incorrect.

Remove the signing date entirely: do not ask for it, do not test that it is a valid value, do not record it, and do not display it. Instead, we can rely upon the application submission date.

Here's how it looks after this change.

An individual provider statement page:

individual-provider-statement

An organization provider statement page:

ctcc-provider-statement

To test this, I created enrollments as an individual and an organization, and verified that the last page did not contain a date field and that I could successfully submit the enrollment application.

Issue #162 Provider enrollment: "Provider Statement" UI improvements Issue #301 When service admin edits pending enrollment, PSM inappropriately checks provider statement date Resolves #1021 Remove date field from provider disclosure forms

kfogel commented 6 years ago

That was fast, @jasonaowen. Thank you. I'll let someone who's not being constantly pulled into conversations at a conference review this, but I'll let @jvasile know it's PR'd now. I'm not sure whether the build failures are anything to do with this change, or are just due to build server lossage that we were discussing earlier today.

jasonaowen commented 6 years ago

@kfogel you're welcome!

The build failures appear to be unrelated (both to this PR and to the full disk on the Jenkins server), as I've seen them on other PRs, but I will investigate more tomorrow.

PaulMorris commented 6 years ago

The two unit test failures are not related to these changes. They are tests that were moved from ProviderDashboardControllerTest to ControllerHelperTest in PR #1016 . So it seems like Jenkins may be holding on to these tests in their old location, through a stale cache or similar problem?

jasonaowen commented 6 years ago

It appears that Jenkins is trying to do some clever git things to reduce disk usage and possibly increase performance, but somehow it left behind files that were deleted in #1016.

I've added a "Clean before checkout" step to the source code management phase of the unit tests build, and will shortly add this step to the other builds. (Making sure not to lose any local configuration needed, such as for the integration tests.)

Jenkins, test this please.

PaulMorris commented 6 years ago

Jenkins, test this please.

jasonaowen commented 6 years ago

FAILURE: Build failed with an exception.

  • What went wrong: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

It seems I neglected to add the --no-daemon gradle argument when I initially created the Java code style job in Jenkins. I have now added it to that job, double-checked all the others, and added it to the JavaScript code style job.

Jenkins, retest this please.