-
Notifications
You must be signed in to change notification settings - Fork 505
Fix for #1602 Insufficient collection information when submitting an article #3327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@im-shubham-vish : Thanks for the PR. Just a note that this is failing We require all PRs to pass lint formatting checks. |
|
Hi @im-shubham-vish , |
f79e97c to
dcea3ba
Compare
|
Hi @Leano1998, Please recheck once and let me know in case you've any feedback. |
tdonohue
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@im-shubham-vish : Thanks for this PR. I gave it a test today, and the basic functionality is working for me. I've verified, I see the entire hierarchy in the popup for "New -> Community", "New -> Collection" and "New -> Item". Here's what it looks like to me
The only issues that I have with this PR is the way in which you've duplicated the same test over and over in several of the spec files. I think it'd be much cleaner & smaller if you moved these tests to a single location...and Codecov (our test verification tool) would also likely stop complaining that it cannot find your tests.
If you can get your tests updated, I think this would be ready to merge.
| describe('JournalIssueSidebarSearchListElementComponent', | ||
| createSidebarSearchListElementTests(JournalIssueSidebarSearchListElementComponent, object, parent, 'parent title', 'title', '5 - 7'), | ||
| ); | ||
| function getExpectedHierarchicalTitle(parentObj: Collection, obj: ItemSearchResult): Observable<string> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of the repetition of the same getExpectedHierarchicalTitle() function in every test that is based off sidebar-search-list-element.
Why not move all this logic to the sidebar-search-list-element.component.spec.ts? It seems to me that single spec file could be updated to ensure it now checks properly for the hierarchical title instead of the single object's title. That way you don't have to copy this function into 9 other spec files.
| * and build a heirarchical name by concating the parent's names | ||
| */ | ||
| getParentTitle(): Observable<string> { | ||
| getHierarchicalName(): Observable<string> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted by CodeCov validation below (see the "files changed" tab in GitHub), you are missing specs for the changes to this sidebar-search-list-element.component.ts. Ideally, we should have tests in sidebar-search-list-element.component.spec.ts which verify the behavior of this new getHierarchicalName() method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My prior feedback has NOT been addressed on this getHierarchicalName() method. We need to add new tests to sidebar-search-list-element.component.spec.ts which prove that this method is properly building the hierarchical name at all times. Otherwise, there is a risk that it will accidentally break in the future & we won't realize it.
|
Hi @im-shubham-vish, |
|
@tdonohue Thanks for the feedback! I have implemented your suggestions and pushed the changes. Please review and let me know if you have any further feedback. |
tdonohue
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@im-shubham-vish : Thanks for the updates. I got back to this PR today. It still works when I test it manually. However, the tests don't appear to be running at all. I don't see the output of the tests when I run npm test, or in the GitHub logs. Are you getting these tests to run?
Overall, this code works. But, I still don't see the tests working properly. It's important to have new & working tests so that this code doesn't break in the future. See my inline comments below.
| createSidebarSearchListElementTests(JournalSidebarSearchListElementComponent, object, parent, 'parent title', 'title', '1234, 5678'), | ||
| ); | ||
| const expectedHierarchicalTitle = getExpectedHierarchicalTitle(parent, object); | ||
| if (expectedHierarchicalTitle) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This if clause in all tests appears to be skipping the test. When I run these tests locally (or look at the logs of the tests in GitHub), I cannot find any proof of the "JournalSidebarSearchListElementComponent" test being run below.
Are you sure these tests are running? Could we remove this if statement to prove they work?
| * and build a heirarchical name by concating the parent's names | ||
| */ | ||
| getParentTitle(): Observable<string> { | ||
| getHierarchicalName(): Observable<string> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My prior feedback has NOT been addressed on this getHierarchicalName() method. We need to add new tests to sidebar-search-list-element.component.spec.ts which prove that this method is properly building the hierarchical name at all times. Otherwise, there is a risk that it will accidentally break in the future & we won't realize it.
| if (expectedHierarchicalTitle) { | ||
| expectedHierarchicalTitle.subscribe((hierarchicalTitle: string) => { | ||
| describe('JournalSidebarSearchListElementComponent', () => { | ||
| createSidebarSearchListElementTests(JournalSidebarSearchListElementComponent, object, parent, hierarchicalTitle, 'title', '1234, 5678'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since all of these tests call createSidebarSearchListElementTests, couldn't we move the call to getExpectedHierarchicalTitle() into that existing createSidebarSearchListElementTests method? I don't see why we need to have the if or the subscribe above? Is there something I'm missing here?
|
@tdonohue We have incorporated the suggestions. Kindly review and if you have any feedbacks let us know. |
|
@tdonohue, |
|
@tdonohue, @EikLoe, |
|
@tdonohue, |
|
Hi @im-shubham-vish, |

Description
Fixes #1602
Insufficient collection information when submitting an article.
Instructions for Reviewers
Sometimes, the collections returned by the collection browser are indistinguishable because their names are identical to other collections and their parent communities.
For example, suppose you have two communities named "Institution A" and "Institution B," each with a subcommunity named "Reports." Both subcommunities have a collection called "Research Reports." If I want to submit an item to "Institution B > Reports > Research Reports," it's impossible to differentiate between the "Reports" subcommunity in "Institution A" and "Institution B" when searching for the "Research Reports" collection.
Expected Behavior
Instead of displaying only the name of the parent community, the interface should display the full hierarchy, similar to how it's done in XMLUI.
List of Changes in this PR:
• Added a method getHierarchicalName in sidebar-search-list-element.component.ts that returns the hierarchical name. Now, parentTitle calls getHierarchicalName instead of getParentTitle.
• Added a method createInstanceFromDSpaceObject responsible for creating an instance of DSpaceObject.
• Removed the maxlines argument from sidebar-search-list-element.component.html.
• Added some CSS to the content class in truncatable-part.component.scss.
Steps to Test and Reproduce the Behavior: