Yodlee getSiteLoginForm API response changes between attempts - yodlee

There seems to be an inconsistency with the responses for Yodlee's getSiteLoginForm REST API function.
For a site that has a login field with radio buttons, sometimes the data coming back from Yodlee for that particular field will look like this:
{
"fieldInfoList": [
{
"validValues": [
"1",
"2",
"3",
"4"
],
"displayValidValues": [
"1",
"2",
"3",
"4"
],
"valueIdentifier": "OPTIONS",
"valueMask": "LOGIN_FIELD",
"fieldType": {
"typeName": "OPTIONS"
},
"size": 20,
"maxlength": 40,
"name": "OPTIONS",
"displayName": "Issue Number",
"isEditable": true,
"isOptional": false,
"isEscaped": false,
"helpText": "76367",
"isOptionalMFA": false,
"isMFA": false
}
]
}
and other times it looks like this:
{
"validValues": [
"1",
"2",
"3",
"4"
],
"displayValidValues": [
"1",
"2",
"3",
"4"
],
"valueIdentifier": "OPTION",
"valueMask": "LOGIN_FIELD",
"fieldType": {
"typeName": "OPTIONS"
},
"size": 20,
"maxlength": 40,
"name": "OPTION",
"displayName": "Issue Number",
"isEditable": true,
"isOptional": false,
"isEscaped": false,
"helpText": "76367",
"isOptionalMFA": false,
"isMFA": false
}
It's the same field but the valueIdentifier value has changed and the data isn't being enclosed in a fieldInfoList variable.
What would be the reason for this response data-set changing between two attempts if there's no difference in the code?
In addition to that, could a similar response inconsistency be affecting other API functions from Yodlee, and if so how does one deal with this uncertain variance?

We did analysis and Yodlee provides every time same response, no matter how many attempts you'll do. While I am assuming that you might be confused between getSiteLoginForm and getLoginFomForContentService, as both are two different APIs and belongs to approach i.e., Site Based and Container Based respectively. And the response you have mentioned first comes when you use getSiteLoginForm while the later one comes with getLoginFormForContentService.
Hope this helps as there is no issue with the API, these are two different response from 2 different APIs.

Related

How to update Product Custom Attribute with media_image type via REST API in Magento 2.4

I'd like to know how I can update the product custom attribute defined as media_image type via REST API in Magento 2.4.4.
My custom attribute is defined like the following:
{
"is_wysiwyg_enabled": false,
"is_html_allowed_on_front": true,
"used_for_sort_by": false,
"is_filterable": false,
"is_filterable_in_search": false,
"is_used_in_grid": true,
"is_visible_in_grid": true,
"is_filterable_in_grid": true,
"position": 0,
"apply_to": [],
"is_searchable": "0",
"is_visible_in_advanced_search": "0",
"is_comparable": "0",
"is_used_for_promo_rules": "0",
"is_visible_on_front": "0",
"used_in_product_listing": "0",
"is_visible": true,
"scope": "website",
"attribute_id": 185,
"attribute_code": "custom_pic",
"frontend_input": "media_image",
"entity_type_id": "4",
"is_required": false,
"options": [],
"is_user_defined": true,
"default_frontend_label": "custom_pic",
"frontend_labels": [
{
"store_id": 1,
"label": "Custom Picture"
}
],
"backend_type": "varchar",
"is_unique": "0",
"validation_rules": []
}
But I don't know how to update it and can't find the proper documentation.
I can update other custom attributes successfully by endpoint /rest/default/V1/products/{sku}
I tried the following so far:
Tried to pass a valid URL in value. But didn't work!
{
"attribute_code": "custom_pic",
"value": "https://xxxx/.../xxx.png"
}
Tried to base64 encoded string. (Because we can update product images by base64 encoded string.) But no luck!
Could you help me out, please?

Azure Devops API Release definitions expand recursively (I need workflowTasksfrom deployPhases from environments)

Does the Azure Devops REST API allow me to expand multiple levels? When using the release definitions I specifically need the workflowtasks, which are buried a couple of lists deep.
More context:
I'm optimizing an Azure Devops extension that scans pipelines for compliancy. Right now there's a rule that scans the workflowtasks. To get the information required on all relevant pipelines, we do the following call to the Azdo API for each release definition:
https://vsrm.dev.azure.com/{Organization}/{Project}/_apis/release/definitions/{definitionID}?api-version=6.0
This returns a completely decked-out release definition including environments like this:
"environments": [{
"id": 10,
"name": "Stage 1",
... etc
"deployPhases": [{
"deploymentInput": {
"parallelExecution": {
"parallelExecutionType": "none"
},
...etc
"rank": 1,
...etc
"workflowTasks": [{
"environment": {},
"taskId": "obfuscated",
"version": "2.*",
"name": "obfuscated",
"refName": "",
"enabled": true,
"alwaysRun": false,
"continueOnError": false,
"timeoutInMinutes": 0,
"retryCountOnTaskFailure": 0,
"definitionType": "task",
"overrideInputs": {},
"condition": "succeeded()",
"inputs": {
"template": "obfuscated",
"assets": "obfuscated",
"duration": "60",
"title": "",
"description": "",
"implementationPlan": "obfuscated"
}
}, {
"environment": {},
"taskId": "obfuscated",
"version": "2.*",
"name": "obfuscated",
"refName": "",
"enabled": true,
"alwaysRun": false,
"continueOnError": false,
"timeoutInMinutes": 0,
"retryCountOnTaskFailure": 0,
"definitionType": "task",
"overrideInputs": {},
"condition": "succeeded()",
"inputs": {
"changeClosureCode": "1",
"changeClosureComments": "Successful implementation",
"changeId": ""
}
}
]
}
],
...etc
}
],
But when I try and get the list as a whole, using the following URL:
https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/definitions?$expand=environments&api-version=6.0
My Environments arrays (there is one for each definition obviously) looks nothing like the previous one. It doesn't include deployPhases (not even as an empty array).
Since we have 2300 release definitions, you can Imagine how inconvenient it is to call the release/definitions/{definitionID} endpoint instead of the release/definitions one that fetches all of them at the same time.
Is there a way to expand the release/definitions call to fetch all environments including workflowTasks and maybe other stuff? Is there a syntax that allows for this? Something like $expand=environments>deployPhases>workflowTasks?
Is there a way to expand the release/definitions call to fetch all environments including workflowTasks and maybe other stuff? Is there a syntax that allows for this? Something like $expand=environments>deployPhases>workflowTasks?
I am afraid there is no such syntax allow you to fetch all environments including workflowTasks.
You could use the REST API with some powershell scripts to fetch all environments including workflowTasks:
The sample powershell scripts:
$url = "https://vsrm.dev.azure.com/{Organization}/{Project}/_apis/release/definitions/{definitionID}?api-version=6.0"
Write-Host "URL: $url"
$pipeline = Invoke-RestMethod -Uri $url -Method Get -Headers #{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Host "workflowTasks = $($pipeline.environments.deployPhases.workflowTasks | ConvertTo-Json -Depth 100)"
The output is:

Get specific fields from Rally API for Feature

I am fetching the data using below API :
https://rally1.rallydev.com/slm/webservice/v2.0/PortfolioItem/Feature/?fetch=ObjectID,FormattedID,Name,Parent&pagesize=2000
I don't want to fetch all fields in Parent. All I need Name,FormattedID,ObjectID,Parent.ObjectID,Parent.Name of Feature. A
{
"_rallyAPIMajor": "2",
"_rallyAPIMinor": "0",
"ObjectID": blabla,
"FormattedID": "F3792",
"DirectChildrenCount": 23,
"Name": "Phase 2: Fork Messages (New flow of messages that will feed data to 8 reports for D&P)",
"Parent": {
"_rallyAPIMajor": "2",
"_rallyAPIMinor": "0",
"_ref": "https://rally1.rallydev.com/slm/webservice/v2.0/portfolioitem/portfolio/blabla",
"_refObjectUUID": "8fae",
"_objectVersion": "67",
"_refObjectName": "blabla",
"ObjectID": blabla,
"FormattedID": "P1ABC",
"DirectChildrenCount": 13,
"Name": "blabla",
"_type": "PortfolioItem/Portfolio"
},
"_type": "PortfolioItem/Feature"
}
This is just the way the Web Services API works. Any fields included in the fetch will be returned on any object that has them. This is very useful for being able to hydrate fields on associated objects- Parent, Iteration, etc.

HERE Places API: not all items have PVID

I'm using HERE Places API.
Firstly I'm doing a search.
For Example this query :
https://places.cit.api.here.com/places/v1/discover/search?q=Test&at=35.6111,-97.5467&r=500&size=1&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg&show_refs=pvid&pretty
According to this documentation (Link) If I add show_refs=pvid to query string, in result I will get external id which I can use to query lookup endpoint.
But in result I get next response :
{
"results": {
"next": "https://places.cit.api.here.com/places/v1/discover/search;context=Zmxvdy1pZD1hY2ExNzk3NC0zYzg3LTU5NzQtYmZkMC04YjAzMDZlYWIzMWJfMTUwNjA3NjMzMTYyMl83NDY3XzM4NTAmb2Zmc2V0PTEmc2l6ZT0x?at=35.6111%2C-97.5467&q=Test&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg",
"items": [
{
"position": [
35.60369,
-97.51761
],
"distance": 2756,
"title": "Southwest Test & Balance",
"averageRating": 0,
"category": {
"id": "business-services",
"title": "Business & Services",
"href": "https://places.cit.api.here.com/places/v1/categories/places/business-services?app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg",
"type": "urn:nlp-types:category",
"system": "places"
},
"icon": "https://download.vcdn.cit.data.here.com/p/d/places2_stg/icons/categories/02.icon",
"vicinity": "200 NW 132nd St<br/>Oklahoma City, OK 73114",
"having": [],
"type": "urn:nlp-types:place",
"href": "https://places.cit.api.here.com/places/v1/places/8403fv6k-d1b2fde0616e0326e321a54b88cd9f53;context=Zmxvdy1pZD1hY2ExNzk3NC0zYzg3LTU5NzQtYmZkMC04YjAzMDZlYWIzMWJfMTUwNjA3NjMzMTYyMl83NDY3XzM4NTAmcmFuaz0w?app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg",
"id": "8403fv6k-d1b2fde0616e0326e321a54b88cd9f53",
"authoritative": true
}
]
},
"search": {
"context": {
"location": {
"position": [
35.6111,
-97.5467
],
"address": {
"text": "Oklahoma City, OK 73134<br/>USA",
"postalCode": "73134",
"city": "Oklahoma City",
"county": "Oklahoma",
"stateCode": "OK",
"country": "United States",
"countryCode": "USA"
}
},
"type": "urn:nlp-types:place",
"href": "https://places.cit.api.here.com/places/v1/places/loc-dmVyc2lvbj0xO3RpdGxlPU9rbGFob21hK0NpdHk7bGF0PTM1LjYxMTE7bG9uPS05Ny41NDY3O2NpdHk9T2tsYWhvbWErQ2l0eTtwb3N0YWxDb2RlPTczMTM0O2NvdW50cnk9VVNBO3N0YXRlQ29kZT1PSztjb3VudHk9T2tsYWhvbWE7Y2F0ZWdvcnlJZD1jaXR5LXRvd24tdmlsbGFnZTtzb3VyY2VTeXN0ZW09aW50ZXJuYWw;context=c2VhcmNoQ29udGV4dD0x?app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg"
}
}
}
In response no object references
Is it a bug or not every place has this external id?
I am responding as member of the team around HERE Places API.
Yes, not every place has a pvid. That is why I would suggest using the Sharing Id instead. I realize that the documentation should be improved to clarify that.
The Sharing Ids can be obtained by adding show_refs=sharing to either your search query or a place details request. It can be found in the field references. Once you have the sharing id you can you the lookup endpoint as you intended.
Take a look at:
https://places.cit.api.here.com/places/v1/places/8403fv6k-d1b2fde0616e0326e321a54b88cd9f53;context=Zmxvdy1pZD00YWU2ZWZjNi01ZjgzLTUwYTQtOTI4OS0xZjliMGMwNWY3NjBfMTUwNzA0NDE0OTc3NV84MTI5XzU1NDcmcmFuaz0w?app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg&show_refs=pvid
and
https://places.cit.api.here.com/places/v1/places/8409q8yy-6af3c3e50bcb4f859686797b2be5773d;context=Zmxvdy1pZD00YWU2ZWZjNi01ZjgzLTUwYTQtOTI4OS0xZjliMGMwNWY3NjBfMTUwNzA0NDE0OTc3NV84MTI5XzU1NDcmcmFuaz0w?app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg&show_refs=pvid
On those two examples, the only difference is the placeId.
In the docs, there's not a single reference saying that the external identifier is required or existant for every place.
Since it represents an external identifier, I believe we could assume that it's not required.
And it's what we just saw with your place (8403fv6k-d1b2fde0616e0326e321a54b88cd9f53): this one don't have any external identifier.
Based on your comments, what you need is the information about a place.
So, after you run your first query, you should get something like:
{
title: "Southwest Test & Balance",
position: [],
id: "8403fv6k-d1b2fde0616e0326e321a54b88cd9f53",
href: "https://[...]"
}
With this ID, you could access it:
places.cit.api.here.com/places/v1/places/8403fv6k-d1b2fde0616e0326e321a54b88cd9f53;context=Zmxvdy1pZD0zYTFlZjg5ZS02ZTY5LTUxYmEtYWFkYS1kY2UwZWMyNDdkMDBfMTUwNzEzNjUxNjI5N182NjExXzc2OTgmcmFuaz0w?app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg
Or directly using the href information.
This response already is giving you the ID and URL to access all the info of a single place.
You don't need any other external ID or reference.

is there a wikipedia api call that can retrieve restriction status of the article?

Otherwise I must do querySelector on the page content to find if there is a some kind of padlock and by try and error check what (id or class) is unique to that icon.
Other source to find is this info is to go on information page by adding $action=info to the url params. But then another problem comes in that the protection status is written in that's particular wiki language.
Using the API is the right way to do it, but you need to use action=query. The padlocks icons are inconsistent across wikis, and most wikis probably don't even have them.
If you use the right parameters for your API query, you should be getting the results you're looking for.
Example for the English Wikipedia:
https://en.wikipedia.org/w/api.php?action=query&prop=info&format=json&inprop=protection&titles=Elton%20John gives you this result:
{
"batchcomplete": "",
"query": {
"pages": {
"5052197": {
"pageid": 5052197,
"ns": 0,
"title": "Elton John",
"contentmodel": "wikitext",
"pagelanguage": "en",
"touched": "2015-10-02T03:49:24Z",
"lastrevid": 683730854,
"length": 115931,
"protection": [
{
"type": "edit",
"level": "autoconfirmed",
"expiry": "infinity"
},
{
"type": "move",
"level": "sysop",
"expiry": "infinity"
}
],
"restrictiontypes": [
"edit",
"move"
]
}
}
}
}
Here the protection array tells you that only sysops can move the page, and only autoconfirmed users can edit it.
If you make a similar query on another wiki, say the French Wikipedia: https://fr.wikipedia.org/w/api.php?action=query&prop=info&format=json&inprop=protection&titles=Malia%20Obama , you get this in response (trimmed):
"protection": [
{
"type": "edit",
"level": "sysop",
"expiry": "infinity"
},
{
"type": "move",
"level": "sysop",
"expiry": "infinity"
}
],
"restrictiontypes": [
"edit",
"move"
]
In this case, sysops are the only one who can move and edit the page.