Miscellaneous fixes

[LotteHofstede]

This PR solves some small remaining issues for the preview release.

It takes care of:

• Making sure clicking the search icon in the header actually directs the user to the search page
• Admin menu links that do not direct to a useful page yet, are greyed out
• The admin menu link to New --> Item now links the user to /submit
• Going to item/collection/community pages that don't exist, will now show you a 404 page instead of crashing

Update

The tests failed due to the dspaceObject -> indexableObject issue. So we merged in the MyDSpace PR to get them to pass.

Here you can see only the changes for this PR

[tdonohue]

@LotteHofstede and @artlowel : Overall, the changes here look straightforward (As noted in the description, most of the changes here are from the MyDSpace PR, which has now been merged to master)

However, in testing, one issue that I discovered is that when accessing a community/collection/item that doesn't exist, a 200 Response is returned (and often the 404 page is not appearing for me).

So, for example:

• http://localhost:3000/doesnotexist will return a 404 response and show the 404 page.
• http://localhost:3000/collections/doesnotexist will return a 200 response...I initially got the 404 page to appear, but now I'm seeing an odd response where I just see a "Recent Submissions" list of Items.
• http://localhost:3000/items/doesnotexist will return a 200 response, and I see a nearly empty page that says "Error fetching item".
• http://localhost:3000/communities/doesnotexist has the same behavior as /items. I get a 200 response with a message saying "Error fetching community"

The other changes all seem to work here. It's only the new 404 behavior that seems to be buggy.

[LotteHofstede]

@tdonohue After trying out the examples you gave, I realised you are actually testing something else than what I was referring to when I mentioned "item/collection/community pages that don't exist".
What I implemented was a 404 page for when - for example - an item has been deleted. This implicates that the URL you go to, still contains a valid UUID. The rest service will return a 404 error when this happens.

However, when you simply type any string as an identifier, like you did in your example, the REST service will detect that this is not a UUID and return a 401 status.
After consulting with @artlowel, I do think the "Error fetching ..." page seems to be appropriate, when the server doesn’t return a 404. I made sure the collection page now behaves similarly to the community and item pages.

[tdonohue]

@LotteHofstede : this now has merge conflicts with the latest master after I merged the Configurable Entities PR: #372

Could you get these cleaned up? If possible, this is also a good opportunity to simply rebase the PR against master -- that should decrease the size of this PR (easing the final review), since the MyDSpace and Configurable Entities PRs are now both merged.

[LotteHofstede]

@tdonohue I rebased my branch onto master. Could you verify everything now works as expected? Thanks!

[paulo-graca]

Thank you @LotteHofstede for these fixes, the code looks ok, well documented. I tested It and It worked as expected.

[Atmire-Kristof]

I've added an entities related fix to this PR:

There was a bug on certain entity pages (for example Journal), where the filtered search component wouldn't show up at the bottom of the page. This was due to a change in the MyDSpace PR on how SearchConfigurationService is used. It is expected to be using an Inject annotation.
The bug is fixed after adding an inject annotation (as well as a provider) to SearchConfigurationService in FilteredSearchPageComponent.

[tdonohue]

👍 I gave this another test today and it looks good to me. Thanks @LotteHofstede !