About omelhus

omelhus · ‎05-07-2024

Just allow @export to export an Int to a Long. Pretty sure this doesn't work today.

omelhus · ‎05-07-2024

An alternative is adding coercing in @export. Let @export coerce from Int to Long, and Int/Long to Boolean using truthy and falsy.

omelhus · ‎03-07-2024

The correct scope for user authentication is "business-graphql-api:access-group-based", and for service auth it's " business-graphql-service-api:access-group-based". I've seen that some places in the documentation there's references to scopes used for Vismas internal staging environment. Also remember that there's different endpoints for user and service. Use https://business.visma.net/api/graphql for user and https://business.visma.net/api/graphql-service for service auth.

omelhus · ‎03-07-2024

Hey, I'm banging my head against some limitations with the async queries. You can only execute a maximum of 10 asynchronous query at a time and you can only start a new one 5 seconds after the previous one has been started. (Note: These numbers may be subject to change.) Say I need to import an ungodly amount of lines, I'm hitting the max upload size. When I try to split the file into parts and use background jobs I have to wait 5 s between requests for each part of the file? And I can enqueue a max of 10 jobs? What is the rationale behind these limitations?

omelhus · ‎02-07-2024

@Marius Bancila Maybe this issue should have a better error message?

omelhus · ‎02-07-2024

Awesome

omelhus · ‎02-07-2024

Wouldn't that break all queries ala "query x($cid: Int!) { useCompany(no: $cid)..."? Not sure how this can be done backwards compatible.

omelhus · ‎02-07-2024

Verify that your service or user has access to the company number you are trying to use. Use availableCompanies to check.

omelhus · ‎27-06-2024

Wow! Thank you!

omelhus · ‎24-06-2024

I second this. This is an implementation detail that we as api consumers should’t have to care about.

omelhus · ‎22-06-2024

Would also be great if useModel could take a numeric languageNo instead of (or in addition to) lang: Enum. This would let me fetch the correct translations based on the languageNo on an associate. If no match, fall back to the value provided in lang or something that makes sense.

omelhus · ‎21-06-2024

I have a use case where I need to get the associated vismaNetCustomerId for a vismaNetCompanyId. Would be nice if availableCompanies took a filter so that I could filter on vismaNetCompanyId and just @export the vismaNetCustomerId.

omelhus · ‎21-06-2024

Hey, I have this query where I need to use both useCompany, and fetch some things from the company table on useCustomer. Turns out the data type for "no" on useCompany is Int, whilst vismaNetCompanyId on the company table is Long. This means that I have to use two variables to get what I want. - Ole

omelhus · ‎20-06-2024

Hey, It would be cool if we could select tenant in Business NXT with a url param, and that way deep link to windows. Like https://business.visma.net/1/12345?customerId=81549300. - Ole

omelhus · ‎20-06-2024

Thank you!

omelhus · ‎20-06-2024

Thanks! My workaround broke this morning, so I figured you had fixed it 🙂

omelhus · ‎19-06-2024

Turns out I'm not able to update the fontName after all - it's just there in the schema taunting me. Please let me read and write fontName and fontStyle.

omelhus · ‎18-06-2024

Hey, I have a curious case of a few fields that I'm allowed to write to, but not allowed to read. The fields in questions is fontName and fontStyle on formElement. I really, really, really need to access the value of these fields, so that I can visualize the currently selected font. - Ole

omelhus · ‎14-06-2024

Enum is the way to go 👍

omelhus · ‎13-06-2024

Hey, To upload an image to use as logo on forms we have to attach a file using a processing on the integerCompanyVariables-table. This processing is not available in any usable way in the API. Also, I'm unable to find a way to download the image set for a variable. Can you add a processing to download the image as well? Cheers

omelhus · ‎13-06-2024

Magnificent!

omelhus · ‎13-06-2024

Well, this was the issue until I figured that out and just started sending a non-base64-encoded string instead. The issue with sending the non-base64-encoded string is that base64 preserves the windows-1252 or iso-8859-1 encoding that bnxt uses for its labels, but when I send it through the API they get mangled with the utf-8 encoding. I've managed to partially work around this by latin1 encoding the data first, but this does not totally solve the issue. Please fix so that I can send base64 in again.

omelhus · ‎13-06-2024

Hey, After the change where the fields marked with [B] in GraphQL automatically converts the value to base64 on the backend instead of accepting base64 the encoding fails. ÆØÅ etc just becomes useless. This kind of ruins the point of base64, and you need to either roll back the automatic conversion to base64, or check if the value that's being sent is valid base64 and NOT re-encode it. Cheers

omelhus · ‎05-06-2024

Hey, Usually only tables with databaseTypeNo = 3 are relevant from the model. If we are to stop using the xml model and rely on the API we need this information as well. Would be great if columns could include info about read/write access as well. Keep it up!

omelhus · ‎05-06-2024

That would be really good!

omelhus · ‎04-06-2024

Hey, In the UI I have the option to "insert line above" in the order line view. This will insert a line with an incremented lineNo, but a sortSequenceNo making it go to the line above. Would it be possible to open up for this in the API as well? Cheers

omelhus · ‎31-05-2024

This makes sense to me.

omelhus · ‎30-05-2024

Good! Visma added some more logging after I encountered this, so now maybe they’ll be able to figure it out. The update is successful even though the response says otherwise.

omelhus · ‎30-05-2024

Please include the visma trace id for this response, as this is bug that I haven't been able to reproduce, but have encountered myself. This is probably an issue somewhere between vbus an graphql, and must be investigated by Visma.

omelhus · ‎30-05-2024

I think the bigger issue is that this has been changed without any notice, no release notes, no heads up for integrations to change. We only notice when the integrations blow up after a release has been done, without notice.

Re: Inconsistencies in data type for companyNo/vis...

Re: Inconsistencies in data type for companyNo/vis...

Sv: Invalid_scope when fetching access token with ...

Limitations in async queries

Sv: Upload document to voucher errorfailedToFetchD...

Sv: Inconsistencies in data type for companyNo/vis...

Re: Inconsistencies in data type for companyNo/vis...

Sv: Upload document to voucher errorfailedToFetchD...

Sv: Setting sortSequenceNo on orderLine

Sv: Important Information on Changes in File Handl...

Sv: Inconsistencies in data type for companyNo/vis...

Filter on availableCompanies

Inconsistencies in data type for companyNo/vismaNe...

Selecting customer/tenant using a url parameter

Re: Fields that are writeable should always be rea...

Re: Encoding issues with base64 fields

Sv: Fields that are writeable should always be rea...

Fields that are writeable should always be readabl...

Re: Setting sortSequenceNo on orderLine

Mutation to upload file to IntegerCompanyVariables...

Re: Setting sortSequenceNo on orderLine

Re: Encoding issues with base64 fields

Encoding issues with base64 fields

Model info should include databasetypeno on table

Re: Setting sortSequenceNo on orderLine

Setting sortSequenceNo on orderLine

Re: Fields are cleared on update mutation

Sv: Fields are cleared on update mutation

Sv: Fields are cleared on update mutation

Re: Fields are cleared on update mutation

Useful pages

About Visma

Contact us

Follow us