I have one member in a team drive that was suspended, but now it is active.
When I list permissions:
https://www.googleapis.com/drive/v3/files/{drive-id}/permissions?supportsTeamDrives=true&useDomainAdminAccess=true&fields=permissions(type%2Crole%2CemailAddress)
I get:
{
"permissions": [
{
"type": "user",
"emailAddress": "",
"role": "organizer"
},
{
"type": "user",
"emailAddress": "***#***",
"role": "reader"
}
]
}
Is this a correct behavior to return an empty 'emailAddress' for users that were suspended? How can I get user mail in this case?
Related
When querying archival node for transactions with EXPERIMENTAL_tx_status method, some transactions have no receipts while having receipts_outcome. How is that possible, and how is that transaction different from others?
If I understand correctly, receipts_outcome are the results of applying receipts. According to explorer, this transaction has Convert Transaction To Receipt part, so there should be some receipts generated.
According to documentation
A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
A good mental model is to think of a Receipt as a paid message to be executed at the destination (receiver). And a Transaction is an externally issued request to create the Receipt (there is a 1 to 1 relationship).
My query
{
"jsonrpc": "2.0",
"id": "2",
"method": "EXPERIMENTAL_tx_status",
"params": ["7beNxrbHxMRspJWT9NeEVwx719kVcmY9tRdPG9SYro26", "bumbleee99.near"]
}
Response
{
"jsonrpc": "2.0",
"result": {
"status": {
"SuccessValue": ""
},
"transaction": {
"signer_id": "bumbleee99.near",
"public_key": "ed25519:DFM5GRGbpNkk4XkhcFnRUFeKG8a3nzTH8NwZp754pC48",
"nonce": 59080995000003,
"receiver_id": "bumbleee99.near",
"actions": [
{
"AddKey": {
"public_key": "ed25519:CUoNs153GHrPZ9F8HpvhzFr1mwuUFUdGQsRNE2CTNjVH",
"access_key": {
"nonce": 0,
"permission": "FullAccess"
}
}
}
],
"signature": "ed25519:15v34qoyCHSvSL5uLcaPqD9vXvjcPrCaZVStCMms8e58C62z2UHiazwUXzHajPEgdHpwn7s4J9dd5UPmtvzbYgM",
"hash": "7beNxrbHxMRspJWT9NeEVwx719kVcmY9tRdPG9SYro26"
},
"transaction_outcome": {
"proof": [
{
"hash": "ECKDm5FVhzit7Wqs9sEyBB9NtuTrVRZmWwcxkkg2yUh4",
"direction": "Right"
},
{
"hash": "E4VXdwsNj3fZCbP6y9YH3M5oZHPDcdArqU9kbZJa95Qp",
"direction": "Right"
}
],
"block_hash": "ASY6HgDUQUXUa99L7dPEfghKEnEk5SNkwQrx24u3Fobz",
"id": "7beNxrbHxMRspJWT9NeEVwx719kVcmY9tRdPG9SYro26",
"outcome": {
"logs": [],
"receipt_ids": [
"JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ"
],
"gas_burnt": 209824625000,
"tokens_burnt": "20982462500000000000",
"executor_id": "bumbleee99.near",
"status": {
"SuccessReceiptId": "JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ"
},
"metadata": {
"version": 1,
"gas_profile": null
}
}
},
"receipts_outcome": [
{
"proof": [
{
"hash": "8RwCWE9HgqenPKv8JW9eg2iSLMaQW82wvebYSfjPbdTY",
"direction": "Left"
},
{
"hash": "E4VXdwsNj3fZCbP6y9YH3M5oZHPDcdArqU9kbZJa95Qp",
"direction": "Right"
}
],
"block_hash": "ASY6HgDUQUXUa99L7dPEfghKEnEk5SNkwQrx24u3Fobz",
"id": "JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ",
"outcome": {
"logs": [],
"receipt_ids": [],
"gas_burnt": 209824625000,
"tokens_burnt": "20982462500000000000",
"executor_id": "bumbleee99.near",
"status": {
"SuccessValue": ""
},
"metadata": {
"version": 1,
"gas_profile": []
}
}
}
],
"receipts": []
},
"id": "2"
}
You could see that both transaction_outcome.outcome.receipt_ids and transaction_outcome.outcome.status are pointing to a receipt with ID JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ. I've tried querying node about this receipt with EXPERIMENTAL_receipt method like this
{
"jsonrpc": "2.0",
"id": "2",
"method": "EXPERIMENTAL_receipt",
"params": {"receipt_id": "JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ"}
}
yet the node returns error indicating, that there is no receipt with given ID
{
"jsonrpc": "2.0",
"error": {
"name": "HANDLER_ERROR",
"cause": {
"name": "UNKNOWN_RECEIPT",
"info": {
"receipt_id": "JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ"
}
},
"code": -32000,
"message": "Server error",
"data": {
"name": "UNKNOWN_RECEIPT",
"info": {
"receipt_id": "JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ"
}
}
},
"id": "2"
}
TL;DR the receipt is a local receipt
The transaction from your example is a simple AddKey action where the sender is the receiver (remember this, it's important)
"Execute" transaction (means to convert the transaction into a Receipt)
Apply the Receipts
As the result of the conversion of the transaction into a receipt is your transaction_outcome
"outcome": {
"receipt_ids": [
"JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ"
],
"status": {
"SuccessReceiptId": "JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ"
},
This receipt is about to be applied and the predecessor_id and the receiver_id are equal. In nearcore such receipts are called local receipts (sir - sender-is-receiver) and those receipts are not stored in the nearcore database.
We emulate them on NEAR Indexer Framework side (that's why you can see Receipt JDnBrxh6L9KFgVUEg6U8d39rEUEmbvLQ5tZQUmJTMyFJ on the transaction details page on NEAR Explorer)
And because nearcore doesn't store such receipts in the database you got UNKNOWN_RECEIPT from the RPC.
I am implementing my Alexa Home Skill using AWS Lambda.
Given the following request I receive when I try to detect new devices on Alexa Skil test page:
{directive={header={namespace=Alexa.Discovery, name=Discover, payloadVersion=3, messageId=0160c7e7-031f-47ee-a1d9-a23f38f87a9e}, payload={scope={type=BearerToken, token=...}}}}
I respond with the following:
{
"event": {
"payload": {
"endpoints": [
{
"displayCategories": [
"SMARTPLUG"
],
"capabilities": [
{
"type": "AlexaInterface",
"interface": "Alexa",
"version": "3"
},
{
"type": "AlexaInterface",
"interface": "Alexa.PowerController",
"version": "3",
"properties": {
"retrievable": true,
"supported": [
{
"name": "powerState"
}
],
"proactivelyReported": true
}
},
{
"type": "AlexaInterface",
"interface": "Alexa.EndpointHealth",
"version": "3",
"properties": {
"retrievable": true,
"supported": [
{
"name": "connectivity"
}
],
"proactivelyReported": true
}
}
],
"manufacturerName": "mirko.io",
"endpointId": "ca84ef6d-53b1-430a-8a5e-a62f174eac5e",
"description": "mirko.io forno (id: ca84ef6d-53b1-430a-8a5e-a62f174eac5e)",
"friendlyName": "forno"
}
]
},
"header": {
"payloadVersion": "3",
"namespace": "Alexa.Discovery",
"name": "Discover.Response",
"messageId": "c0555cc8-ad7a-4377-b310-9de9b9ab6282"
}
}
}
Despite that, for some reasons Alexa answers that it did not find any new device.
I may be mistaken but I am pretty sure it used to work before I decided to add the Alexa.EndpointHealth interface.
Your response object looks right to me, except the extra "endpoint" field.
"endpoint": {
"endpointId": "INVALID",
"scope": {
"type": "BearerToken",
"token": "INVALID"
}
}
There's no such field in the Alexa.Discovery documentation. Try removing it and see if it resolves the issue.
I'm trying to create new users with Slack SCIM API. I've managed to create a new user without password but the invite email was newer sent. I've send following post to https://api.slack.com/scim/v1/Users
{
"schemas": ["urn:scim:schemas:core:1.0",
"urn:scim:schemas:extension:enterprise:1.0"],
"userName": "samplename",
"nickName": "samplename",
"name": {
"familyName": "sample",
"givenName": "name"
},
displayName": "sample name",
"emails": [
{
"value": "sample.name#gmail.com",
"type": "work",
"primary": true
}
],
"userType": "sample",
"title": "sample",
"active":true
}
I can see the user created in the user list but never got the actual invite. (yes I checked spam). Is there even a way for this user to login?
I'm trying to use the https://outlook.office.com/api/v2.0/me/findmeetingtimes endpoint documented on the MSDN Outlook Calendar website. When I call the endpoint with the following payload:
{
"Attendees": [
{
"Type": "optional",
"EmailAddress": {
"Name": "Studio 3",
"Address": "PDXICSTUDIO3#rogueInc.onmicrosoft.com"
}
}
],
"TimeConstraint": {
"ActivityDomain":"Unrestricted",
"Timeslots": [
{
"Start": {
"DateTime": "2018-10-30T19:30:00",
"TimeZone": "UTC"
},
"End": {
"DateTime": "2018-10-30T20:30:00",
"TimeZone": "UTC"
}
}
]
},
"ReturnSuggestionReasons": "true",
"IsOrganizerOptional": false,
"MaxCandidates": 99
}
I get an empty meeting time suggestions response with the reason provided as "AttendeesUnavailable". It doesn't seem to matter whether I declare the type of the attendee as "optional", "required", or "resource" as specified in the attendeeBase Resource Type documentation. This seems like a bug with the GraphAPI and I'm unsure as to how to proceed.
I used to be able to use the IBM SBT getContacts API from either a perl script (with authentication provided in the request) or an internet browser (authentication popup would appear) and it would return the data in JSON format as documented on the IBM Connections Developers API reference page:
http://www-10.lotus.com/ldd/appdevwiki.nsf/xpAPIViewer.xsp?lookupName=API+Reference#action=openDocument&res_title=Contacts_getContacts_API&content=apicontent&sa=true
Recently, however, the API call has been returning a 403 forbidden status. If I sign in to the IBM Connections Cloud before trying to use the API via a browser, it is converted to:
https://apps.na.collabserv.com/mycontacts/home.html
Does anyone know what I need to do to get the API to work again?
Thanks.
The best API to use are
https://apps.na.collabserv.com/lotuslive-shindig-server/social/rest/people/#me/#all?filterBy=type&filterOp=equals&filterValue=contacts&format=json
You'll get a list of the following entries back...
{
"photos":
[
],
"telephone": "",
"profileUrl": "",
"mobilephone": "",
"orgs":
[
{
"value": "CONTACTS",
"type": "Source"
},
{
"value": "Mentorship Expressway",
"type": "Org"
}
],
"website": "",
"id": "na.collabserv.com:contact:160000909070",
"fax": "",
"connectedToId": 201238541234,
"addresses":
[
],
"emailAddress": "asdfasdf#us.ibm.com",
"websites":
[
],
"objectId": 160000909070,
"type": "FRIEND",
"jobtitle": "",
"updated": "2014-07-01T16:44:21.000Z",
"ims":
[
],
"emails":
[
{
"value": "CONTACTS",
"type": "Source"
},
{
"title": "Primary Email",
"email": "asdfasdf#us.ibm.com"
}
],
"org":
{
"name": "Mentorship Expressway"
},
"displayName": "asdfasdf",
"address": "",
"companyId": 22285,
"phoneNumbers":
[
{
"value": "CONTACTS",
"type": "Source"
},
{
"title": "MOBILE",
"phone": "+ asdfasdf"
}
]
}