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

Data Importer - not able to handle property names such as "cq:tags@[]" #1561

Closed
2 tasks done
ncordeiro opened this issue Nov 14, 2018 · 3 comments
Closed
2 tasks done
Assignees
Milestone

Comments

@ncordeiro
Copy link

ncordeiro commented Nov 14, 2018

Please note that the fix for the issue is to update the DataImporter class in the package com.adobe.acs.commons.mcp.impl.processes at line 61 setting the enableHeaderNameConversion to true
Alternative way would be to avoid passing it in the constructor since the Spreadsheet java constructor sets it to true in the class

Required Information

  • [6.4 ] AEM Version, including Service Packs, Cumulative Fix Packs, etc: sp2
  • ACS AEM Commons Version: 3.18.3
  • Reproducible on Latest? yes/no- yes

Expected Behavior

I am using the data import feature to update asset's properties,

property names in the header of an excel, of the format propertyname@[] such as cq:tags@[] should be stored in aem as cq:tags and not cq:tags%5...

The value stored in aem is not cq:tags or any propertyname but a representation of(maybe creating a valid property name of @[]) "@[]"

Links: https://adobe-consulting-services.github.io/acs-aem-commons/features/mcp-tools/data-importer/index.html

Actual Behavior

The aem property name should be stored as cq:tags without parsing the "@[]"

Steps to Reproduce

  1. Create an excel with property name(test@[] or cq:tags@[]) in the header
  2. Import the excel using data import in the MCP uploading the excel file and choosing create/overwrite property
  3. Check the metadata property name

Attaching the sample excel sheet data
image

@badvision badvision self-assigned this Nov 14, 2018
@badvision
Copy link
Contributor

Good sleuthing! Sorry about that. I'll get something in for 4.0.0, but if you beat me to it I'll approve the pull request post-haste.

@badvision badvision added this to the 4.0.0 milestone Nov 14, 2018
@ncordeiro
Copy link
Author

ncordeiro commented Nov 15, 2018

@badvision : done . thanks Brendan

@badvision
Copy link
Contributor

Let me know if my patch is acceptable @ncordeiro. I think the approach I took in #1579 allows some flexibility as well as addressing the root issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants