add(faser): new models and transformation rules#525
Conversation
449b371 to
ad9f970
Compare
5a1ae44 to
b80fdd9
Compare
5c9c961 to
c5cb66e
Compare
zubeydecivelek
changed the title
53f5e25 to
b178502
Compare
ecbe233 to
c7c9763
Compare
1078762 to
d162634
Compare
| @model.over("access_grants", "^506[1_]_", override=True) | ||
| @for_each_value | ||
| def access_grants(self, key, value): | ||
| """Translates status field.""" | ||
| restriction_access_notes = value.get("a", "").strip().lower() | ||
| # TODO: how to handle these values? resource type? | ||
| if restriction_access_notes and restriction_access_notes not in [ | ||
| "faser-confnote", | ||
| "faser-confpaper", | ||
| "faser-preprint", | ||
| "faser-slide", | ||
| ]: | ||
| raise UnexpectedValue(subfield="a", field=key, value=value) |
There was a problem hiding this comment.
This field is different than normal access_grants field. I dont think these are related with access. What should we do? @kpsherva
There was a problem hiding this comment.
do you have example records? how is this field different? I can't answer without examples
There was a problem hiding this comment.
examples:
this is the rule in research.py: https://github.com/CERNDocumentServer/cds-migrator-kit/blob/master/cds_migrator_kit/rdm/records/transform/xml_processing/rules/research.py#L331-L341
I dont think it's access permissions for faser values
There was a problem hiding this comment.
if you check for ,CFG_WEBCOMMENT_RESTRICTION_DATAFIELD` in legacy code and see the various configurations for GENSBM_config_Faser_* it seems to be restriction for who can comment per resource type :) we have to ask tomorrow at the meeting (please note it down) if there is any need to restrict on who can comment on specific resource types - this going to be complicated, it would be better to avoid it
There was a problem hiding this comment.
so basically this is the e-group which we should set as reviewers on the request for community inclusion, pinging @palkerecsenyi here for another opinion - is it EP Approval request or community inclusion request?
There was a problem hiding this comment.
So this is not a record restriction, it's comments right? should we still use this to the records access?
There was a problem hiding this comment.
reviewers of the request - there is already partial implementation from Fatimah done for 906 field which handles this, 506 in Fasers case seems to be the same but for e-groups
There was a problem hiding this comment.
I'm not hugely sure since I don't have much experience with the migration and the legacy data model. But I think community inclusion sounds more realistic. I'm not sure you could customise the EP Approval request reviewers on legacy?
There was a problem hiding this comment.
I'm not hugely sure since I don't have much experience with the migration and the legacy data model. But I think community inclusion sounds more realistic. I'm not sure you could customise the EP Approval request reviewers on legacy?
it is not that much about migration as about how to fit the data we have into the new data model and since you were working a lot on the EP workflow I thought you might have an understanding if this fits more into community inclusion or EP approval.
No it is not possible to customise easily the EP reviewers on legacy - the e-groups were hardcoded basically
37a778d to
06f70ac
Compare
e5f8d10 to
6f7135c
Compare
d807e69 to
e5a7147
Compare
e5a7147 to
b013592
Compare
b013592 to
9ebae4f
Compare
3 participants
No description provided.