Item page entities changes/refactoring#475
Conversation
…d list using new REST API search endpoint + test cases on publication pages
Conflicts: src/app/core/data/relationship.service.spec.ts
| <ds-metadata-representation-list | ||
| [label]="'relationships.isAuthorOf' | translate" | ||
| [representations]="authors$ | async"> | ||
| [parentItem]="item" |
There was a problem hiding this comment.
Hi @Atmire-Kristof , this isn't working for me. I've already started a project from scratch, loaded some entities, but still I can't see related authors. Meanwhile on the author's page, I can see the publications. Am I missing something?
There was a problem hiding this comment.
@paulo-graca , I double-checked, but can't seem to reproduce your issue. I am able to see a list of author relations on publication pages. I've tested with both the 4science rest api (dspace7.4science.cloud/server/api), as well as our own.
There was a problem hiding this comment.
As far as the two pictures go, I don't see anything wrong here.
There's two reasons I can think of that could cause this issue:
- Your publication doesn't contain a "virtual metadata value" for the author. There should be a metadata value under
dc.contributor.authorwith an authority property that links to therelation.isAuthorOfPublicationmetadata (e.g. they both have authority property set tovirtual::1234). - Your REST API doesn't have the
relationships/search/byLabelendpoint deployed (as described here. However, this would most likely cause a bunch of console or other errors.
If those aren't the case, maybe you could make sure I can access the item for myself to take a better look, as I don't think this item is accessible on the 4science REST API?
There was a problem hiding this comment.
I've just forced this on the template:
<ds-related-items
[parentItem]="item"
[relationType]="'isAuthorOfPublication'"
[label]="'relationships.isAuthorOf' | translate">
</ds-related-items>
And the related author is showed. I've also this metadata in my response:
"metadata" : {
"dc.contributor.author" : [ {
"value" : "Oliveira, R. F.",
"language" : null,
"authority" : null,
"confidence" : -1,
"place" : 0
}, {
"value" : "Canario, Adelino",
"language" : "*",
"authority" : "virtual::21",
"confidence" : -1,
"place" : 1
}, {
"value" : "Carneiro, L. A.",
"language" : null,
"authority" : null,
"confidence" : -1,
"place" : 2
}, {
"value" : "Gonçalves, D.",
"language" : null,
"authority" : null,
"confidence" : -1,
"place" : 3
}, {
"value" : "Canario, Adelino",
"language" : null,
"authority" : null,
"confidence" : -1,
"place" : 4
}, {
"value" : "Grober, M. S.",
"language" : null,
"authority" : null,
"confidence" : -1,
"place" : 5
} ],
So, I've the "authority" : "virtual::21" attribute like you referred. I just think that might be a problem with the refactored: ds-metadata-representation-list component.
| .map((metadatum: any) => Object.assign(new MetadataValue(), metadatum)) | ||
| .map((metadatum: MetadataValue) => { | ||
| if (metadatum.isVirtual) { | ||
| return this.relationshipService.findById(metadatum.virtualValue).pipe( |
There was a problem hiding this comment.
I think the problem is within: this.relationshipService.findById(metadatum.virtualValue)
I have a metadatum virtual::21, and the metadatum.virtualValue will be 21
the response of https://host/server/api/core/relationships/21 is:
{
"id": 21,
"relationshipTypeId": 0,
"leftPlace": 1,
"rightPlace": 0,
"leftwardValue": null,
"rightwardValue": null,
"type": "relationship",
"_links": {
"relationshipType": {
"href": "https://host/server/api/core/relationshiptypes/1"
},
"self": {
"href": "https://host/server/api/core/relationships/21"
},
"leftItem": {
"href": "https://host/server/api/core/items/549aa8db-07ee-4e49-9789-822490089d61"
},
"rightItem": {
"href": "https://host/server/api/core/items/9cc6e4cd-756a-468d-b067-5ceff0df6978"
}
},
"_embedded": {
"relationshipType": {
"id": 1,
"leftwardType": "isAuthorOfPublication",
"rightwardType": "isPublicationOfAuthor",
"leftMinCardinality": 0,
"leftMaxCardinality": null,
"rightMinCardinality": 0,
"rightMaxCardinality": null,
"type": "relationshiptype",
paulo-graca
left a comment
There was a problem hiding this comment.
Thank you @Atmire-Kristof ! It works with your backend server. Still, not mine. Since I'm using DSpace master branch and testing with the default configurations on my local tests, I'm getting different results from what I've tested with your backend:

That said. I think this PR might depend on a particular PR, not yet merged on master.
tdonohue
left a comment
There was a problem hiding this comment.
👍 The code here looks good. I haven't had a chance to test it out though.
benbosman
left a comment
There was a problem hiding this comment.
I have tested the code against the latest REST master.
https://www.dropbox.com/s/fbudt5uwa0zhfzo/Schermafdruk%202019-11-08%2010.39.53.png?dl=1 is a sample list of relationships displayed when opening a test journal
After clicking "view more", this gets expanded: https://www.dropbox.com/s/io0jk8z9wgmd004/Schermafdruk%202019-11-08%2010.42.47.png?dl=1
Conflicts: src/app/+item-page/simple/item-types/shared/item-relationships-utils.ts src/app/+item-page/simple/item-types/shared/item.component.spec.ts src/app/+item-page/simple/item-types/shared/item.component.ts src/app/+item-page/simple/metadata-representation-list/metadata-representation-list.component.spec.ts



This PR refactors the way related items are fetched and displayed on item pages.
Fetching relationships per type
With the addition of the byLabel search endpoint on relationships as described here, I’ve refactored relationship-service’s getRelatedItemsByLabel to use this endpoint. This also means that relationships are now returned in a PaginatedList.
Item pages
I have moved the logic of fetching these related items for each entity type from their item pages (e.g. publication component) to
related-itemsandmetadata-representation-listcomponents instead. This clears up a lot of duplicate code on the item pages and allows for new related entities to be configured purely on the item’s template file.I've also updated the current mantis files to use the same configuration and metadata as their default variants.
View more/less
Because displaying lists of related items is now handled in two separate components (related-items and metadata-representation-list) and related items are wrapped in a paginated list, I was able to configure these components to add a “view more/less” link.
The “view more” link is only visible if the list contains more than 5 items (configurable with inputs).
Clicking “view more” will send out a new request, fetching and displaying all related items.
A “view less” link now becomes visible.
Clicking “view less” resets the list to only show 5 (or the configured amount).