Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error on rendering DynamicForm when having a Date Field with internal name starting with underscore ("_") #1738

Closed
Lewin8687 opened this issue Jan 18, 2024 · 3 comments · Fixed by #1816
Assignees
Labels
status:fixed-next-drop Issue will be fixed in upcoming release. type:bug
Milestone

Comments

@Lewin8687
Copy link

Category

[ ] Enhancement

[X] Bug

[ ] Question

Version: [3.15.0]

Expected / Desired Behavior

The form should be rendered successfully.

Observed Behavior

The form dispears and errors show in the console.
image

Steps to Reproduce

  1. Create an extension using DynamicForm
  2. Add OOTB "End Date" or any date field named starting with a number (for example, "1Date") to a content type
  3. Add the content type to a document library
  4. Create a document out of the content type
  5. Attach the custom form to the list content type
  6. Add a date value to the new document from Details Pane
  7. Open custom form
  8. Issue: errors show up in console, the form shows and disappears.

Investigation

The reason could be the line to get the date value from the list item.
image

The key of the date field value in list item is not the same as field internal name. For example, for OOTB date field "End Date", internal name is "EndDate", but in list item, its saved as "OData__EndDate". Same to other fields which internal name starts with underscore "". SharePoint will prefix it with "OData_" to make DynamicForm unable to get the value.

@ghost
Copy link

ghost commented Jan 18, 2024

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

@ghost ghost added the Needs: Triage 🔍 label Jan 18, 2024
@NishkalankBezawada
Copy link
Contributor

Hello @Lewin8687,

I have found the issue, and will soon creating a PR on this.

@joelfmrodrigues @AJIXuMuK @michaelmaillot Please assign this to me.

Thanks,
Nishkalank

@NishkalankBezawada
Copy link
Contributor

NishkalankBezawada commented Jan 30, 2024

Hello @Lewin8687,

I have created a PR on this.

Problem statement

When a date column is created with an underscore or '_' at the begining, the form is not rendered correctly. For instance, if a column with name '_AccomplishedDate', '1AccomplishedDate' is created, and the list form is not rendered, instead it errors out.

Solution

On investigating the issue, I have created columns as below

Column Name Type Internal Name (Retrieved from Item)
1EFDate DateTime OData__x0031_EFDate
2EFDate DateTime OData__x0032_EFDate
_EFDate3 DateTime OData__EFDate3
12312EDate DateTime OData__x0031_2312EDate
%Test Text OData__x0025_Test
1Test DateTime OData__x0031_Test

Since the FieldInternal names are not matching with the Internal names of the columns, this issue is spotted.
By checking the FieldInternal name as below, and validating, the issue is resolved.

        if (fieldName.startsWith('_x') || fieldName.startsWith('_')) {
          fieldName = `OData_${fieldName}`;
        }

Screenshot

Issue1738

@joelfmrodrigues @michaelmaillot Kindly review the stated PR.

Thanks,
Nishkalank

@michaelmaillot michaelmaillot added status:working-on-it Known issue / feature being addressed. Will use other "status:*" labels & comments for more detail. type:bug and removed Needs: Triage 🔍 labels Feb 8, 2024
@AJIXuMuK AJIXuMuK added status:fixed-next-drop Issue will be fixed in upcoming release. and removed status:working-on-it Known issue / feature being addressed. Will use other "status:*" labels & comments for more detail. labels Feb 13, 2024
@AJIXuMuK AJIXuMuK added this to the 3.18.0 milestone Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:fixed-next-drop Issue will be fixed in upcoming release. type:bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants