We are unable to retrieve Deposit, Transactions, Statement and Transfers using Quickbooks online API.
Environment: C#
You can refer the QBO Entity docs.
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/030_entity_services_reference
What do you mean by 'unable to retrieve' ? Are you getting any exception ? In that case, please mention the details in your post.
You can try all QBO Endpoints using APIExplorer tool.
https://developer.intuit.com/apiexplorer?apiname=V3QBO
You can try the sample .net application as well.
https://github.com/IntuitDeveloperRelations/QuickbooksV3API-DotNet
Thanks
You can retrieve the deposit from the QBO using the below script:
QueryService<Deposit> DepositQueryService = new QueryService<Deposit>(context);
var ListDeposit = DepositQueryService.ExecuteIdsQuery("Select * From Deposit MaxResults 1000").ToList();
This will help you.
Related
I was looking at a setting from Get-MSOLCompanyInformation - hoping to get the company's ReleaseTrack through an API.
I am somewhat guessing this would be part of the company "State" from the Get-MSOLCompanyInformation documentation, but I don't really see any graph-scopes that seem applicable
Anyone know which permission and endpoint I would query for that value?
The nearest similar MS Graph API for Get-MSOLCompanyInformation cmdlet would be organizations resource type.
Sample Request:
https://graph.microsoft.com/beta/organization
Use "Get-MgOrganization" Cmdlet
Reference:
https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.directorymanagement/get-mgorganization?view=graph-powershell-beta
I'm trying to get all the users which are there in a project,
I went throught this API https://docs.atlassian.com/software/jira/docs/api/REST/7.9.2/#api/2/user-findAssignableUsers, but idk why I'm getting {"errorMessages":["Internal server error"],"errors":{}}.
I also followed this article https://community.atlassian.com/t5/Answers-Developer-Questions/List-of-users-in-project-REST-API/qaq-p/536820 but I'm getting 401 unauthorised, as I don't have admin rights, I can't use the plugin mentioned in the above article. I'm stuck :( . I'll be thankful if anyone can help me.
Thanks.
First of all as Mech suggested, you will need to have admin access to the project to get required details. REST API uses exactly the same permissions as that of the normal JIRA UI.
If you want to fetch all the users(including different project roles) who have access to the respective project, then you need a chain of Jira REST Api calls as below,
Using this api to fetch all the available roles for a project,
GET /rest/api/2/project/{projectIdOrKey}/role
You will get some response like,
{
"Administrators": "http://www.example.com/jira/rest/api/2/project/MKY/role/10002",
"Users": "http://www.example.com/jira/rest/api/2/project/MKY/role/10001",
"Developers": "http://www.example.com/jira/rest/api/2/project/MKY/role/10000"
}
Then for each of the project roles(fetched in the first step), call the below jira rest api to give the respective list of users by passing the role id and project key,
GET /rest/api/2/project/{projectIdOrKey}/role/{id}
This is how you can get all project memebers (users) :
https://{YourCompanyName}.atlassian.net/rest/api/3/user/assignable/search?project={JiraIdProject OR JiraProjectKey}
I need to take a count of each group from Azure AD using Graph API. Can anyone tell me how to achieve it
I also faced the similar issue. When I ran the end point mentioned in https://learn.microsoft.com/en-us/graph/api/group-list-members?view=graph-rest-1.0&tabs=http#example-2-get-only-a-count-of-all-membership I got "$count is not currently supported."
However, if you notice the documentation clearly, it asks us to send in the ConsistencyLevel as eventual in the REST header. I got the correct response when I sent the header along with the call:
GET https://graph.microsoft.com/v1.0/groups/{id}/members/$count ConsistencyLevel: eventual
There is currently no Microsoft Graph endpoint to get the number of users.
You could list members by using:
GET https://graph.microsoft.com/v1.0/groups/{id}/members
And then handle the count of the members in your code.
See the reference here. Try it quickly with Microsoft Graph Explorer.
I'm trying to fetch information about meeting rooms such as capacity and office.
I have the resource email address and MS ID.
I can view this information in Outlook but cannot when using the endpoint https://graph.microsoft.com/v1.0/users/{resource id}
Is this possible using the current API?
Any help appreciated.
You have to add one more attribute in graph endpoint to fetch room details as mentioned in the below example :
https://graph.microsoft.com/beta/users/{resource id}/findrooms
Reference : https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/user_findrooms
I am trying to restrict page access based on logged in user's AD Groups. I have issues with following codes.
var tenantId = incomingPrincipal.FindFirst(GraphConfiguration.TenantIdClaimType).Value;
//create Azure Graph Api client to make api calls
var client = Helpers.AzureGraphAPIFunctions.GetActiveDirectoryClient(tenantId);
IGroup group = client.Groups.Where(x => x.DisplayName == groupName).ExecuteSingleAsync().Result;
These codes work fine and get me the AD Group by groupName but sometimes throws exception
"Tenant information is not available locally. Use the following Urls
to get the information."
{"odata.error":{"code":"Directory_BindingRedirection","message":{"lang":"en","value":"Tenant information is not available locally. Use the following Urls to get the information."},
"values":[
{"item":"Url1","value":"https:\/\/directory-s1-ch1.directory.windows.net"},
{"item":"Url2","value":"https:\/\/directory-s1-sn2.directory.windows.net"},
{"item":"Url3","value":"https:\/\/directory-s1-co1.directory.windows.net"},
{"item":"Url4","value":"https:\/\/directory-s1-bl2.directory.windows.net"}
]}}
Any ideas?
Thanks
Folks,
We're currently investigating this issue (you should not be seeing this error). It looks like a regression. Will update this thread when I have more info.
UPDATE:
This issue should now be resolved. We made an update to our gateway logic that broke some of our retry/redirect logic. We've now put some monitors in place also that should detect this issue much faster (should we make the same mistake again).
Apologies for those of you who were affected by this incident.