👯♀️ Add collaborations to Contributor type #1038
Conversation
| if (value === undefined) return undefined; | ||
| if (inputAff && Object.keys(inputAff).length > Object.keys(value).length) { |
There was a problem hiding this comment.
This is a nice little check that says "Your input looks more like an affiliation than a person."
| @@ -134,6 +134,33 @@ cases: | |||
| family: Name | |||
| email: example@example.com | |||
| corresponding: false | |||
| - title: No email is corresponding if first is false | |||
There was a problem hiding this comment.
I noticed this behaviour and wanted to raise it:
Is it intentional that specifying corresponding: false on one author, prevents any other author from implicitly getting the corresponding: true flag?
I can see arguments either way:
(Yes, to the above question): the user knows about the corresponding flag, as they used it on one of their authors. If they did want a corresponding author, they would have known to add it.
(No, to the above question): we should always try to have a corresponding author where possible.
There was a problem hiding this comment.
Lets make the change! And update this test case.
fwkoch
force-pushed
the
feat/reviewer-editor
branch
2 times, most recently
from
783fa57 to
94dd6a4
Compare
fwkoch
force-pushed
the
feat/collabs-as-contribs
branch
from
82b2b30 to
066a924
Compare
Now, in addition to being a
Person, anyContributorin myst frontmatter may be a "collaboration" - that is, anAffiliationwithcollaboration: true. The logic to determine if a user-specified contributor is a person or a collaboration relies on checking thecollaborationfield - iftrue, it is a collaboration and validated as such; iffalsyit is a person.This addresses a point in #1009