dspace-angular
dspace-angular copied to clipboard
The linkName in the `@link` decorator doesn't assign the value on the correct property
Describe the bug
When you have an @link with a linkName that differs from the property to which you added the decorator, the embedded data will not be linked to that property, but instead, it will be linked to a new property with the name defined in linkName.
To Reproduce Steps to reproduce the behavior:
- In the
item.model.tsclass, rename theaccessStatusproperty to, for exampleaccessStatusValue, and update the@linkto@link(ACCESS_STATUS, false, 'accessStatus'). - Fix the usages of
accessStatusinAccessStatusBadgeComponent, addaccessStatusto the list ofBROWSE_LINKS_TO_FOLLOW, and add a pipe with atakeand aconsole.logto log the page of items inBrowseService#getBrowseItemsFor. - Now go to the
/browse/dateissuedpage and check your console. You will see that the value is not set on theaccessStatusValueproperty, but onaccessStatus.
Expected behavior
The embedded data should be saved on the property to which you added the @link decorator.
Related work
I discovered this bug during #2480. After implementing this fix, it will be important to check that these changes still work as expected. The current implementation now only checks if the property with the linkName has a value, but when this is fixed, this should be updated. Otherwise, some followLinks will never be automatically invalidated when their parent is invalidated.
@alexandrevryghem I'm unable to replicate the issue you're experiencing, or perhaps I'm misunderstanding your point. When I utilize the following code:
@link(ACCESS_STATUS, false, 'accessStatus')
accessStatusValue?: Observable<RemoteData<AccessStatusObject>>;
The accessStatusValue in my item correctly receives an assigned Observable:
Could you please provide more details or guide me to where I should be looking to reproduce the issue?
@pcg-kk: I created https://github.com/DSpace/dspace-angular/commit/bb13004dfd719eb7d99af74e186b28987af2c095 with proof of how it doesn't work with some logs. This time I tried renaming the thumbnail property to thumbnailBitstream and I am still able to reproduce the error, and the thumbnails also don't render anymore because of this. This isn't really a big bug because now all the properties probably have the same name as the linkName otherwise they don't work/are not used. I only opened this ticket in order to remember that these changes need to be adapted when this eventually gets fixed, I'm also not sure we really have to allow this customisation since I don't really see the benefit in it.