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

FilePicker: Site Tab does not load document if we access SharePoint site in different language than default language of the site #724

Closed
kalpeshvaghela90 opened this issue Nov 5, 2020 · 5 comments
Assignees
Labels
status:fixed-next-drop Issue will be fixed in upcoming release. type:bug
Milestone

Comments

@kalpeshvaghela90
Copy link

Category

[ ] Enhancement

[X ] Bug

[ ] Question

Version

Please specify what version of the library you are using: [ 1.16.0 ]

Expected

FilePicker - Site Tab should work doesn't matter in which language we are accessing site.

Observed Behavior

If SharePoint site's default language is English, and if you access site in any other language then Site tab will show list of document library but if we click on any library then it doesn't get document from that document library (specially in case of default library i.e. Site Pages, Site Assets, Document Library) if document library title is multi lingual.

Steps to Reproduce

  1. Create one site collection in English language
  2. Deploy web part/extension which does have File picker used
  3. Access site in different language than default language English
  4. Open File Picker and click on Site Tab and select default library i.e. Site Assets/Documents/Site Pages
  5. It will not show any documents

Submission Guidelines

I went through code and found that document library are being accessed using GetByTitle method.
image

It should not use List Title in order to get query in document library but it should use either list server relative URL or List Id

Thanks!

@ghost
Copy link

ghost commented Nov 5, 2020

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

@ghost ghost added the Needs: Triage 🔍 label Nov 5, 2020
@AJIXuMuK AJIXuMuK added status:tracked Triaged and are being investigated further and removed Needs: Triage 🔍 labels Nov 9, 2020
@AJIXuMuK AJIXuMuK self-assigned this Nov 9, 2020
@AJIXuMuK
Copy link
Collaborator

AJIXuMuK commented Nov 9, 2020

Thank you @kalpeshvaghela90 for reporting that issue!

AJIXuMuK added a commit that referenced this issue Nov 21, 2020
@AJIXuMuK AJIXuMuK added status:fixed-next-drop Issue will be fixed in upcoming release. type:bug and removed status:tracked Triaged and are being investigated further labels Nov 21, 2020
@AJIXuMuK AJIXuMuK added this to the 2.2.0 milestone Nov 21, 2020
@AJIXuMuK
Copy link
Collaborator

Hi @kalpeshvaghela90,

I have implemented the fix. Could you please test it in beta version?

@nbelyh
Copy link
Contributor

nbelyh commented Nov 30, 2020

@AJIXuMuK Now it seems that the folder browser stopped working altogether when navigating from the "Sites" view 😄 (works only on the root site). It throws an exception here (404, file not found), on any locale, /sites/AnySite/ url:

image

try {
let restApi = `${this.context.pageContext.web.absoluteUrl}/_api/web/GetList('${listUrl}')/RenderListDataAsStream`;

The thing is, it tries to do this: getList('/Shared%20Documents')
When it actually it probably should do this: getList('/site/AnySite/Shared%20Documents')

Looks like getList() expects full relative url, not a partial one.

I guess the link line above should be changed like this maybe?

      let restApi = `${this.context.pageContext.web.absoluteUrl}/_api/web/GetList('${this.context.pageContext.web.serverRelativeUrl}/${listUrl}')/RenderListDataAsStream`;

AJIXuMuK added a commit that referenced this issue Nov 30, 2020
@AJIXuMuK
Copy link
Collaborator

Thank you @nbelyh! Good catch!

Now it should be fixed.

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

No branches or pull requests

3 participants