Skip to content

Comments

added alternative content tag and controls on bitstreams#4016

Open
oscar-escire wants to merge 8 commits intoDSpace:mainfrom
oscar-escire:Issue/3808
Open

added alternative content tag and controls on bitstreams#4016
oscar-escire wants to merge 8 commits intoDSpace:mainfrom
oscar-escire:Issue/3808

Conversation

@oscar-escire
Copy link
Contributor

@oscar-escire oscar-escire commented Feb 19, 2025

References

Description

This PR allows to set a tag in the list of bitstreams on item page to indicate if its an alternative content, you can set the tag on bitstreams of archived items or in the upload section edit bitstream of a itemworkspace.

Instructions for Reviewers

  1. Log with a user that can send new items.
  2. Add a bitstream to a new item
  3. Click on edit bitstream data, and you will se a checkbox to enable or disable alternative content tag
  4. archive the item.
  5. Check the item page to see alternative content tag on items file lists

Alternative:

  1. Log with a user that can edit archived items.
  2. Find and item with bitstreams
  3. click on edit item button
  4. Go to bitstream list page
  5. Edit a bitstream and you will se a checkbox to enable or disable alternative content tag
  6. Save changes
  7. Check the item page to see alternative content tag on items file lists

List of changes in this PR:

  • Enabled alternative content checkbox on upload section
  • Enabled alternative content checkbox on archived item's bitstream edit page
  • Enabled a badge tag to "alternative content" on the bitstream list.

Checklist

  • My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
  • My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
  • My PR passes ESLint validation using npm run lint
  • My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
  • My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
  • My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
  • My PR aligns with Accessibility guidelines if it makes changes to the user interface.
  • My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
  • My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
  • If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
  • If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
  • If my PR fixes an issue ticket, I've linked them together.

@tdonohue tdonohue added accessibility component: Item (Archived) Item display or editing labels Feb 19, 2025
@tdonohue tdonohue moved this from 🙋 Needs Reviewers Assigned to 👀 Under Review in DSpace 9.0 Release Feb 27, 2025
@atarix83 atarix83 requested review from steph-ieffam and removed request for atarix83 February 27, 2025 16:01
Copy link
Contributor

@steph-ieffam steph-ieffam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @oscar-escire I added a PR review directly on the Rest repository: DSpace/DSpace#10431 (review)

CC: @tdonohue @atarix83

@github-actions
Copy link

github-actions bot commented Mar 5, 2025

Hi @oscar-escire,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

@tdonohue
Copy link
Member

@oscar-escire : This frontend PR has merge conflicts. Could you find time to update this so that it's in a testable state again?

@oscar-escire
Copy link
Contributor Author

@tdonohue thanks! I have fixed the merge conflicts.

@github-actions
Copy link

Hi @oscar-escire,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

Copy link
Member

@tdonohue tdonohue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oscar-escire : Thanks for this contribution. I gave this a more thorough test today, and overall the basics work. But, similar to @steph-ieffam 's comments on the (obsolete) backend PR, I find the behavior a little odd overall.

First, I want to document what I had to do to get this to work properly (as it's not documented in this PR).

  1. Installed this PR (obviously)
  2. Add the required "dc.type" field to the "bitstream-metadata" form in the submission-forms.xml (on the backend):
          <row>
                <field>
                    <dc-schema>dc</dc-schema>
                    <dc-element>type</dc-element>
                    <repeatable>false</repeatable>
                    <label>Type</label>
                    <input-type>onebox</input-type>
                    <hint>Enter a type of file</hint>
                    <required></required>
                </field>
            </row>
  1. Then I built & ran this PR in production mode: npm run build:prod && npm run serve:ssr

The end result is that I see this new "Alternative Content" checkbox in both the Submission Form (when editing the bitstream) and in the Edit Item form (again when editing a bitstream)

alternative-content

However, a bug that I noticed is that if I submit an Item though with files marked as "Alternative Content", the files show up oddly on the Item Page. It appears these "Alternative Content" badges have no style? In the below picture, all three files have an "Alternative Content" badge, but it's white on a white background.

item-page

Another small bug is that, in the Submission Form, the action buttons next to Bitstreams are no longer next to each other. Here's how it looks currently in our codebase:

current-file pn

But, here's how it now looks in this PR:

new-file

Overall, this feature works at a basic level, and the above bugs are relatively small.

That said, I do have two larger concerns.

  1. I find the checkboxes for Primary Bitstream & Alternative Content to be odd. The Primary Bitstream was previously a switch, and now it's become a checkbox (but only one file can be checked). The "Alternative Content" is a checkbox, but multiple files can be checked, and it doesn't display in the Submission Form next to each file (like the Primary Bitstream does).
    • I don't have a great solution here, but I think the toggle for "Primary Bitstream" should not be changed to a checkbox. I'd rather they both be toggles instead of checkboxes,
  2. I feel the way this "Alternative Content" is stored in metadata is potentially "fragile". Currently, if you check that checkbox, the Bitstream will have a dc.type set to alternative content. This is more fragile than how we store the "primary bitstream" flag because it's possible that sites will already use dc.type on their Bitstreams for a different purpose.
    • A better approach would be to either store this value in a database column (like primary bitstream) or create a new dspace.bitstream.type metadata field (in our internal dspace schema) which could be used to store this value. That way, we are not using a dc.* field that other sites may already use, and we make it clear this is an internal use metadata field (as all other dspace.* fields are)

Finally, one other note inline below.

bitstream$ = observableOf(this.bitstream);
}
if (isAlternativeContent) {
updatedBitstream.setMetadata('dc.type', undefined, ...['alternative content']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like how this value of alternative content has to be hardcoded in many areas of this PR. It'd be better to use a single constant that could be referenced in all areas. Since this is a hardcoded value, it also could be shortened to something like alt-content

Alternatively, this value could be moved to the backend as a constant (but that might require a new endpoint of some sort to tell the backend when a bitstream should be flagged as "alternative content")

@oscar-escire
Copy link
Contributor Author

Hello @tdonohue, thanks for your comments. I generally agree with you, I think the recent merges have affected the PR's views.

I'll be working on an update and will share it in the coming days.

@tdonohue
Copy link
Member

tdonohue commented Apr 2, 2025

@oscar-escire : Just a brief note. This unfortunately missed our feature merger deadline for 9.0. Since it's a new feature, I'll have to unfortunately move it to the next major release (10.0). You're still welcome to work on it, but I don't see a way to get this into 9.0 because it'll miss our 9.0 Testathon (starting next week), which is required for all new features.

@tdonohue tdonohue moved this to 👀 Under Review in DSpace 10.0 Release Apr 2, 2025
@tdonohue
Copy link
Member

@oscar-escire : We are just beginning a more detailed review process for 10.0 for all "new feature" PRs. If you can rebase this on latest main (to resolve the merge conflicts) that would allow us to consider this for 10.0. Thanks!

# Conflicts:
#	src/app/item-page/simple/field-components/file-section/file-section.component.html
#	src/app/submission/sections/upload/file/edit/section-upload-file-edit.component.ts
@oscar-escire
Copy link
Contributor Author

@tdonohue: I have updated the PR so that it can be considered for DSpace 10 and have applied the following observations:

  1. Adjust the interface so that the switches are displayed correctly (it should be noted that this is a bug in the version; there is a recent adjustment in _global_styles.scss that causes the styles for the switch to not be applied correctly):
.form-check-input {
  border-color: unset;
  appearance: auto; /* Reset to browser's default appearance */
}
  1. Add a constant to facilitate code maintenance and avoid hardcoding text in multiple places.

  2. Change the metadata from dc.type to dspace.bitstream.type: in this case, should we include an additional PR to add the field to the bitstreams form? And additionally: should we hide that metadata in the form to prevent changes to the value? Currently, if it is added, it is displayed as an additional input in addition to the switch.

Is there anything else we should consider? Perhaps this function could be enabled or disabled with a configuration or something similar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: 👀 Under Review

Development

Successfully merging this pull request may close these issues.

3 participants