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

incorrect hasREST function behavior for Sharepoint Online / 365 #180

Closed
vlad1025 opened this issue May 31, 2022 · 2 comments
Closed

incorrect hasREST function behavior for Sharepoint Online / 365 #180

vlad1025 opened this issue May 31, 2022 · 2 comments
Labels

Comments

@vlad1025
Copy link

First of all, thank you very much for this cool library! I use it very often in my projects!

So, now about a bug.

.hasREST function sometimes works incorrectly for SharePoint online sites.
And because of ,hasREST, some other function of $SP library fail - since they rely on hasREST().

==============================
DESCRITION:

.hasREST tries to open window.location.href.split("/").slice(0, 3).join("/") + "/_api/web/Url"

This is incorrect, because it opens ROOT company site api call. (https://[COMPANY].sharepoint.com/_api/web/Url)
And ROOT company site may be inaccessible because of lack of permission.

.hasREST should try to access the following URL: https://[COMPANY].sharepoint.com/sites/[SITENAME]_api/web/Url)

Probably you missed that location.href has "https://" with two slashes in the beginning )

"Slice(0,3)" should be replaced with "Slice(0,5)" To work correctly.

window.location.href.split("/").slice(0, 5).join("/") + "/_api/web/Url"

Regards

@Aymkdn
Copy link
Owner

Aymkdn commented May 31, 2022

Yes you're right, this part is not good. I'm on vacation in another country. I'll be back next week.

I'll make my best to publish a fix sometime next week!

@Aymkdn Aymkdn added the bug label May 31, 2022
Aymkdn added a commit that referenced this issue Jun 9, 2022
  - Added option `modify` to `$SP().getManager()`
  - Added `$SP().isSPO()`
  - Changed `$SP().ajax()` to better managed 401 error for the REST API calls
  - Changed `$SP().cleanResult()` when dealing with a date (`$SP().cleanResult("2022-01-19 00:00:00")` will now return "2022-01-19" instead of "2022-01-19 00:00:00")
  - Changed `$SP().toDate()` to ignore the timezone (e.g. `$SP().toDate("2022-01-19")` used to return different result based on the user's timezone, but now it returns the correct date at 00:00:00 in the current timezone)
  - /!\ Changed `$SP().getVersions()`: only compatible with REST API, and it returns a different result/outcome than before
  - /!\ Changed `$SP().hasREST()`: it will always return TRUE (it's possible to override the value) because REST API is around for a while now and I assume everyone is using at least SP2013 (see issue #180)
  - Fixed `$SP().isMember()` for the `url` option (see issue #175)
  - Removed support for IE10 in the bundle for browsers
@Aymkdn
Copy link
Owner

Aymkdn commented Jun 9, 2022

The new release (v6.2.0) will fix it.

@Aymkdn Aymkdn closed this as completed Jun 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants