icgc-argo / dac-ui

Development of the ICGC ARGO Data Access Control UI

https://daco.icgc-argo.org/

GNU Affero General Public License v3.0

0 stars 0 forks source link

[Data Hookup]: Make Sections Auto-Save on edit #161

Closed rosibaj closed 3 years ago

rosibaj commented 3 years ago

Follow-up to #49

Goal

For each application section, the applicant can edit data and it is auto-saved with the correct functionality as outlined in the wiki Application Form Save Functionality table: https://wiki.oicr.on.ca/display/icgcargotech/DACO+Technical+Specifications

Endpoint to use

this relies on the PATCH Applications/id

Expected Outcomes

All behaviors outlined on the wiki are working, which include:

[x] User fills out values in fields and they are automatically saved when leaving the field

Note: saving and editing for collaborators is broken out into this ticket; https://github.com/icgc-argo/dac-ui/issues/52 And ethics in this ticket; https://github.com/icgc-argo/dac-ui/issues/58

justincorrigible commented 3 years ago

For documentation purposes: We found an issue with the word counter, and will fix it as part of ticket #163

Comment made there: https://github.com/icgc-argo/dac-ui/issues/163#issuecomment-874983809

As part of this ticket, I'll also ensure the word counter tracks the number upon loading data from BE.

kcullion commented 3 years ago

[x] mentioned to @caravinci ...just a copy change for the note in section B. this should be

Must be the institutional email address of the Institutional Representative.

justincorrigible commented 3 years ago

Completed implementation, pending review. All fields in the specified scope should work correctly, as far as I checked.

Worth mentioning:

The Publication URLs add/remove behaviour is iffy, and will be revised at #138. Use at your own risk ☠️
Noticed the API doesn't validate whether there's duplicate URLs (at least it seemed this way when I used the same valid url in the 4th and 5th fields.) May be worth double checking whether that logic is present or needs improvement.
If the Representative's Primary Affiliation is filled before the Applicant's (i.e. if the Applicant's Affiliation hasn't been set yet), then Representative is currently being validated as complete, which shouldn't be the case since the two should match.

rosibaj commented 3 years ago

Re point three:

If the Representative's Primary Affiliation is filled before the Applicant's (i.e. if the Applicant's Affiliation hasn't been set yet), then Representative is currently being validated as complete, which shouldn't be the case since the two should match.

This is the correct behaviour - The validation on them not being the same should not kick in until the Applicants Primary Affiliation is taken into account. Once that is filled in, all affiliations will be validated to match against the Primary Affiliation of the applicant.

justincorrigible commented 3 years ago

Got it. thanks for clarifying! @rosibaj

kcullion commented 3 years ago

tested this ticket and I think we can move it. We are just opening save feedback bug tickets as we find them

rosibaj commented 3 years ago

Agree - preliminary data hookup is done here and a lot of sections can be saved.

Follow-up bugs:

188

189

190

191

rosibaj commented 3 years ago

https://github.com/icgc-argo/dac-api/issues/83