Skip to content

field-parser not applying the visibility configuration #5854

@autavares-dev

Description

@autavares-dev

Describe the bug

When a metadata field is configured to have a limited visibility in the back-end, this configuration is not being applied in the front-end.

I noticed that there were some changes to the code related to this functionality on the front-end, but no equivalent changes were made on the back-end.

In the current front-end, the main code that applies the configuration in a given field is:

public static isHidden(visibility: SubmissionVisibilityType, scope: SubmissionScopeType): boolean {
return isNotEmpty(visibility)
&& visibility.hasOwnProperty(scope)
&& visibility[scope] === SubmissionVisibilityValue.Hidden;
}

and

export type SectionVisibilityType = 'main' | 'other' | 'submission' | 'workspace' | 'workflow';

export enum SubmissionVisibilityValue {
ReadOnly = 'read-only',
Hidden = 'hidden'
}

export enum SubmissionScopeType {
WorkspaceItem = 'submission',
WorkflowItem = 'workflow',
EditItem = 'edit'
}

However, the returned data from the back-end still returns in the same format as it was in 9.2 (blame is from 8 years ago).

Therefore, I'm not sure if it is a front-end bug or a back-end (maybe a missing PR?).

To Reproduce

Steps to reproduce the behavior:

  1. In the back-end, edit submission-forms.xml by adding to some field (dc.title for example) the following config:
<visibility>workflow</visibility>
<readonly>readonly</readonly>

This should make the existing field read-only (disabled) during submission.
2. Start/restart the DSpace backend.
3. Start/edit a submission.
4. The field will still be available for editing. If you try this same configuration in DSpace 9.2, the field will be disabled (works even if you use the DSpace 10.0 backend alongside the DSpace 9.2 frontend).

Expected behavior

The visibility configuration from the back-end should reflect in the forms fields.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugneeds triageNew issue needs triage and/or scheduling

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    🆕 Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions