Closed redmitry closed 1 year ago
If we add _community_id
to Reference
, we should also include an orig_id
_ field, as well as switching to an OpenEBench generated identifier.
If we add _
community_id
toReference
, we should also include anorig_id
_ field, as well as switching to an OpenEBench generated identifier.
Rationale?
If we add _
community_id
toReference
, we should also include anorig_id
_ field, as well as switching to an OpenEBench generated identifier.Rationale?
If the Reference
entry is associated to a community, but its __id
_ is still a DOI or a PubMedId, then the id is "embargoed" by that community, banning other ones from any change on it. So, a solution is allowing more than one Reference
entry referring to the same manuscript or digital object, but being managed by the community.
Yeah. Currently (without community_id) I just allow all community owners add/modify references. Probably we can add community_ids[], but again - who has write permissions?
Yeah. Currently (without community_id) I just allow all community owners add/modify references. Probably we can add community_ids[], but again - who has write permissions?
I guess that only the community managers, who should act as curators.
So, community_ids
would be more a list of communities which are involved in some way to that reference than an attribute telling the bibliographic reference is "owned" by those communities.
Fixed at commit 40ee07689f401de0009d5c3a67ce3b4f442de1a7 adding dependable_community_ids
, which is optional.
Publications (Reference) are global what provokes incertitude in who is allowed to write and update them. Community owners should be able to manage the publications relevant to their submissions.
Another way is to allow all community owners write to the Reference...