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:
- 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.
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:
dspace-angular/src/app/submission/utils/visibility.util.ts
Lines 19 to 23 in 7f59f6c
and
dspace-angular/src/app/core/submission/models/section-visibility.model.ts
Line 12 in 7f59f6c
dspace-angular/src/app/core/submission/models/section-visibility.model.ts
Lines 4 to 7 in 7f59f6c
dspace-angular/src/app/core/submission/submission-scope-type.ts
Lines 1 to 5 in 7f59f6c
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:
submission-forms.xmlby adding to some field (dc.title for example) the following config: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.