Edit homepage news

[benbosman]

trafficstars

This PR provides a home page introduction text which can be modified and retrieved over REST. This is designed to access a list of all static pages (currently home page news only). These are pages not specific to any items. The design of the REST contract should allow it to be extended to e.g. images as well, or multiple home-page sections similar to the JSPUI. Because the XMLUI supports home page news per language, multiple pages can be created here as well.

[benbosman]

@abollini I think I can answer briefly on this to solve your concerns:

• Yes, the plan is to work with bitstreams
• And yes, the functionality will already immediately support storing more than just the home page news, but it's the UI section which will not be implemented for anything beyond the home page news.

I hope this clarifies the contract

[tdonohue]

@benbosman : I'd like to better understand the implementation suggestions/vision here before I can comment on this contract. While this new feature is important, there's a real risk of "scope creep" (or overengineering, as @abollini noted) if we are planning to overhaul how this already works.

As you are already aware, I'm trying to limit the amount of significant changes to the underlying DSpace (Java) API in DSpace 7 (as the real goal is to concentrate on the REST API and Angular UI). Therefore, I'd like to see a more detailed proposal / brainstorm (even just a wiki page of notes or Google doc) for how we'd implement this feature, so that I can provide better feedback.

[abollini]

Thanks @benbosman to confirm my understanding about your plan to use bitstreams here. Please note that there are many other comments and point of discussions in my review above where I will like to know your opinion. Specifically, I would like to receive clarification about how you plan to assign an uuid to the current news and why if they will be bitstreams we need a separate endpoint for them instead than just use / link the bitstream endpoint itself. Moreover, I will like to know what you think about the alternative approach that should be IMHO more easy to implement and more aligned with what we currently have and do for communities and collections.

[tdonohue]

Hi @benbosman : I would still like to better understand the higher level design/proposal here before I can comment further. I have too many questions about what you are proposing...here's just a few:

• Where would a Bitstream containing Homepage news be kept? Are you implying there's now a special type of Item (or Collection) that stores this information? Is a Bitstream now attached to a Site Object? If there can be more than one of these Bitstreams, how do you identify which one is the Homepage News file vs something else (Do individual Bitstreams need special names/titles)?
• What does the workflow for updating this information look like (for an Administrator)? How would Homepage News get updated? For example, is there an Admin UI, or are they expected to upload a (manually updated) Bitstream?
• Are we validating the content of these Bitstreams in any way? For example, presumably homepage news needs to be in HTML format, and not a Word document or PDF.

Generally speaking, I don't understand what the proposed process is for creating and updating these special bitstreams, nor where they are stored within DSpace's object model. So, I'd like to see the high level proposal defined in a Wiki page or Google Doc and linked into this PR.

[abollini]

Hi @benbosman thanks to have added some details. From your latest comments I understand that you plan to create a new Object "Page" that will be linked to a bitstream that will actually hold the content.

I don't see a reason to do that, it could be eventually done just using the bitstreams without the need to introduce a new object. The site object can expose links to such bitstreams similary to how collection and community deal with logo.

Again, I strongly suggest to don't introduce new things until we know why these new stuff is needed and useful. If we diverge from a current implementation (i.e. how the news and logo are managed at the collection and community level) I would like to see a clear path to end with a better uniform solution. If we are not satisfied from what we actually have we should clearly state that and set a goal for its improvement otherwise we will end with two different approaches and the next time a third could raise.

The natural implementation for this feature is imho based on the use of metadata and bitstreams as we have done for community and collections. Again, in this way we will solve the problem of multilanguages for the news (metadata) and we will deal with the multilingual issue of the "media" (images, videos, etc.) using some sort of links between bitstreams that is what we also need for (thumbnails-original files).

[tdonohue]

Closing as very old/outdated. This can be reopened in the future as necessary. This feature was requested again in https://github.com/DSpace/dspace-angular/issues/3200