Is there a way to add google plus reviews to our website? Ideally it would be great if there was a way to have the reviews automatically update on our site as they came in.
So far I haven't really found anything. Does anyone have any ideas?
The Google Maps Places Details Api response includes up to five reviews. I'm not aware of any other Google APIs that provide access to Place reviews.
{
...
"reviews" : [
{
"aspects" : [
{
"rating" : 3,
"type" : "quality"
}
],
"author_name" : "Simon Bengtsson",
"author_url" : "https://plus.google.com/104675092887960962573",
"language" : "en",
"rating" : 5,
"text" : "Just went inside to have a look at Google. Amazing.",
"time" : 1338440552869
}
]
...
}
Related
I need help retrieving flight offers and seat map information for Delta Comfort+ seats using the Amadeus flight APIs.
I've seen Comfort+ described as "both fare and ancillary seat purchase options" that are "booked in W and S classes", and this site gives methods for recognizing a Comfort+ offer using the fare basis code.
I think I've tried most or all of the parameters in the Flight Offers Search API (shopping/flight-offers) and haven't been able to get back any results I can identify as Comfort+ using those methods.
I've also tried the upsell API (/shopping/flight-offers/upselling), which I can get to return main cabin offers based on a submitted basic economy offer, but nothing higher.
And in the seatmap API (/shopping/seatmaps), I'm only seeing seats in the economy section and not those in the Comfort+ section... probably because I've only been able to submit economy flight offers to it.
If anyone could point me in the right direction, I'd really appreciate it. Thanks!
---- added in response to jabrena's request --------------------------
After a bunch of trial and error, I was able to locate a Comfort+ offer and retrieve a seatmap of the Comfort+ section of the main cabin. The steps were:
search flight-offers using pricingOptions.noPenaltyFare=true or pricingOptions.refundableFare=true. (Without these pricingOptions, the returned offers couldn't be upgraded to comfort+ using the upselling API)
submit one of the returned flight offers to the upselling API
locate a returned offer with a fareDetailsBySegment.class of S or W and submit it to the seatmap API.
Here is the flight-offers call (using the Node SDK). The upselling and seatmap calls were populated as I described above
amadeus.shopping.flightOffersSearch.post(JSON.stringify({
currencyCode: "USD",
originDestinations: [
{
id: "1",
originLocationCode: 'MSP',
destinationLocationCode: 'ARN',
departureDateTimeRange: {
date: '2022-04-14'
}
},
{
id: "2",
originLocationCode: 'ARN',
destinationLocationCode: 'MSP',
departureDateTimeRange: {
date: '2022-04-18'
}
}
],
travelers: [
{
id: "1",
travelerType: "ADULT"
}
],
sources: [
"GDS"
],
searchCriteria: {
maxFlightOffers: 200,
additionalInformation: {
brandedFares: true
},
allowAlternativeFareOptions : true,
flightFilters: {
carrierRestrictions: {
includedCarrierCodes: [
"DL",
"AF",
"KL"
]
}
},
pricingOptions: {
noPenaltyFare: true
}
}
})).then(function (response) {
resolve(response);
}).catch(function (response) {
resolve(JSON.stringify(response));
});
Couple points:
I tried the offers API's pricingOptions in a bunch of different combinations. Using pricingOptions.noPenaltyFare=true or pricingOptions.refundableFare=true were the only ways I could get back offers with the classes that would cause the upselling API to return Comfort+ offers
using the PREMIUM_ECONOMY cabinRestriction returned offers that are a class above Comfort+, with seats located outside of the Comfort+ section
using pricingOptions = 'noRestrictionFare=true' returns class Y (full fare), but submitting that to seatmap returns only the non-comfort+ seats, and submitting a Y class offer to the upsell API returned only 1st class (Delta One) and economy amenities... not a Comfort+ option
This feels a little random, and I'm not confident that this is the best way to approach this... Is there any documentation that can help reduce the guesswork?
Thanks!
When using Google Vision to run text detection on a menu, the response from their API is way too large and returns way too much data that I don't need. I just want the text from the menu, not all the coordinates that come with the response. I can't find anything about narrowing down the response in any documentation i've read. Does someone know how to specify what fields get returned in the response?
Heres my request:
POST: https://vision.googleapis.com/v1/images:annotate?key=<MY_KEY>
BODY:
{
"requests": [
{
"image": {
"content": "...base64-encoded-image-content..."
},
"features": [
{
"type": "TEXT_DETECTION"
}
]
}
]
}
I figured it out. I could not find any documentation on how to do this, I had to just guess for like half an hour. If someone knows of any documentation on this let me know.
Anyway you can use the "fields" parameter to narrow down the response like so:
POST: https://vision.googleapis.com/v1/images:annotate?key=<MY_KEY>&fields=responses.fullTextAnnotation.text
This will only return the menu text from the Google Vision text detection API
I want to search all the nearby places within a bounding box using e,g
https://maps.googleapis.com/maps/api/place/nearbysearch/json?bounds=41.35,-81.8|41.54,-81.5&key='mykey'
but received this:
{
"html_attributions" : [],
"results" : [],
"status" : "INVALID_REQUEST"
}
Any idea on how to make the correct call?
Thanks
If I POST an issue transition like this:
{
"fields" : {
"resolution" : {
"name" : "Fixed"
}
}
}
...I get this error:
{
"errorMessages" : ["Missing 'transition' identifier"],
"errors" : {}
}
This seems to imply that I need to include a transition ID along with my list of changed fields. https://stackoverflow.com/a/14642966/565869 seems to say the same. Fine.
However, transition IDs appear to be global. It's not enough to look up the highest transition ID for this issue and increment it; such an ID is probably in use elsewhere. At some expense, I could get the highest transaction ID used anywhere in the system; this might be 68,000 at this moment. But if I were then to use transaction ID 68,001 there's a real chance that a GUI user would attempt a transition of their own and use this ID before I could.
I could use transaction IDs in the range of 1,000,001 and up, but if the JIRA web GUI uses the highest previously used transaction ID when generating new IDs I'll just collide in this range instead of the 68,000 range. I could use 69,000 and trust that there won't be a thousand transitions in the length of time it takes to get the highest transaction ID.
These both seem terribly clumsy, however. Is there no way to post a transition and let JIRA generate its own unique ID? I don't need to retrieve the generated IDs, I just want to update issues' statuses and resolutions.
You're getting mixed up a bit. So lets see if I can explain it better for you.
To transition a JIRA Issue, you use the Transition ID to identify what transition to apply to the issue. You aren't specifying an ID for a transaction or a transition ID to identify that the transition occurred, JIRA takes care of this for you.
The easiest way to understand it is to see it.
So first you can look at what transitions are available to an Issue by doing a GET to the API Call:
/rest/api/2/issue/${issueIdOrKey}/transitions
Example:
/rest/api/2/issue/ABC-123/transitions
Which will show something like this:
{
"expand": "transitions",
"transitions": [
{
"id": "161",
"name": "Resolve",
"to": {
"description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.",
"iconUrl": "https://localhost:8080/images/icons/statuses/resolved.png",
"id": "5",
"name": "Resolved",
"self": "https://localhost:8080/rest/api/2/status/5"
}
}
]
}
So you can see only 1 transition is available for issue ABC-123 and it has an ID of 161.
If you were to browse to that JIRA Issue through the GUI, you would see only 1 Transition available and it would match the API Call. In fact if you inspected the element you should see it having an a tag and in the href something like action=161
So should you want to transition this issue, you'll need to do a POST to the following URL:
/rest/api/2/issue/ABC-123/transitions
With JSON like this:
{
"update": {
"comment": [
{
"add": {
"body": "Bug has been fixed."
}
}
]
},
"fields": {
"assignee": {
"name": "bob"
},
"resolution": {
"name": "Fixed"
}
},
"transition": {
"id": "161"
}
}
Which uses the transition ID found from the call that shows all transitions. I also update the resolution and assignee and add comments at the same time.
That make a bit more sense?
I need to add some customization to BurnDownApp.
and I want to retrieve all User Stories for Release from 'Release Combobox' + All Users stories which linked to Portfolio Item features which linked to release.
In default implementation I can retrieve only User Stories which linked to Release:
find: {
"_TypeHierarchy": { '$in' : [ -51038] },
"Children": null
}
I tried to use this query:
find:{
$and:
[{"_TypeHierarchy": -51038, "Children": null},
{"_TypeHierarchy": { '$in' : [ -51038, -51006 ] },
"Children": null
"Feature.Release.Name": "%ReleaseName%"}]
}
but it doesn't work
How I should change query for get needed data?
Link to BurnDownApp on github: https://github.com/RallyApps/app-catalog/tree/master/src/apps/charts/burndown
Even though a WS API query (Feature.Release.Name = "r3") will work:
https://rally1.rallydev.com/slm/webservice/v2.0/hierarchicalrequirement?workspace=https://rally1.rallydev.com/slm/webservice/v2.0/workspace/12345&query=(Feature.Release.Name = "r3")
This will not work in Lookback API.
This Lookback API query "Feature":7777 will work. In this example 7777 is ObjectID of a feature:
https://rally1.rallydev.com/analytics/v2.0/service/rally/workspace/12345/artifact/snapshot/query.js?find={"_ProjectHierarchy":22222,"_TypeHierarchy":"HierarchicalRequirement","ScheduleState":"Accepted","Feature":7777,"_PreviousValues.ScheduleState":{ "$lt":"Accepted"}},sort:[{"ObjectID": 1},{_ValidFrom: 1}]&fields=["Name","ScheduleState","PlanEstimate","Release"]&hydrate=["ScheduleState"]
If you want to get features in the custom app dynamically based on a release combobox selection you may:
Use wsapi data store to find those features (get their OIDs), and then
Use snapshot to get historical data on stories that associated with features. Filtering them based on "Feature": {$in:[7777,8888,9999]} in the find should work.