add(vocabularies): scientific committees, open access, former dep#795
add(vocabularies): scientific committees, open access, former dep#795kpsherva wants to merge 7 commits into
Conversation
kpsherva
force-pushed
the
migration-LEP
branch
2 times, most recently
from
a596d6f to
3c97768
Compare
…ents * needed for former experiments migration * closes CERNDocumentServer/cds-migrator-kit#412
palkerecsenyi
left a comment
palkerecsenyi
left a comment
There was a problem hiding this comment.
Looks good!! Mostly just a question about the open access level field description
| @@ -0,0 +1 @@ | |||
| ../../app_data No newline at end of file | |||
There was a problem hiding this comment.
Is this a symlink change? What is it doing?
There was a problem hiding this comment.
commit has an explanation. I need to link the vocabularies folder to be packaged as part of the ./site installation... because I don't want to use search for vocabularies values during migration. So I want the yamls to be accessible when I install cds-rdm in cds-migrator-kit, and this is the least disruptive way.
Not using the search saves us up to 1/3 to half a second (in some cases) per record, and when we are migrating 20k records then this becomes serious saving...
| props=dict( | ||
| label=_("Open Access Level"), | ||
| icon="lock open", | ||
| description=_("Select the open access level of this record."), |
There was a problem hiding this comment.
I'm presuming users know what this refers to and what Bronze/Green/Gold open access means? Would it be worth adding a link to an explanatory website in the description, or is this something users already know about?
There was a problem hiding this comment.
normally this will be filled only by the curators who know the values meaning, but it is a good point to make it more explicit that this field requires some expert knowledge (somehow). I will think about it
| props=dict( | ||
| label="Committee", | ||
| icon="users", | ||
| description="Please select a CERN committee related to this record if applicable.", |
There was a problem hiding this comment.
nit: the descriptions of the custom fields all have slightly different formats, e.g. this one is "Please select .... if applicable", while cern:administrative_unit is "Optionally provide..." and cern:programmes is "Please select a ... applicable to your record". Maybe we could make them more consistent? It's not really a big problem though, just a nitpick :)
|
|
||
| render() { | ||
| const { key, children, label, active } = this.props; | ||
| const [journal, oaLevel, oaFundingModel, imprint, thesis] = children; |
There was a problem hiding this comment.
Why are we array-destructuring the children? This seems a little unusual
There was a problem hiding this comment.
what do you find as unusual?
The children are from the python config of custom fields, will always be sorted in the same way
There was a problem hiding this comment.
Ah so the children prop is not being used as the actual React children prop (e.g. a list of React nodes)? I was just thinking this is slightly unusual since children is sort of maybe a 'reserved' prop name. But if this is the name that we're already using elsewhere then it's fine
There was a problem hiding this comment.
yes, this is how the custom fields are propagating subfields in JS. It is not the best I agree with you but I didn't find a better way for now. We had this implementation in another local template of a CF (CERNFields)
Co-authored-by: Pál Kerecsényi <pal@kerecs.com>
zubeydecivelek
left a comment
zubeydecivelek
left a comment
There was a problem hiding this comment.
Looks good to me!
3 participants
Committees custom field will be needed for collections, it is not really a subject, since it is authority body. The committees will get their own communities too
Departments
OA, section collapsed by default