@Arie V Not quite, but i see where you are going to.You are correct about the source model beeing set after creation, as it marks the start point for the next release. This is done so that at the next release we do not need to figure out what version marks the last release, and we just can start the creation process. Initial testing with the “obtain from database” option did not always have the desired result. I’m not sure if the option did not work because we did something wrong, but alas. The manual setting did give the correct results, so we went this route.
@Mark Jongeling great to hear. I’ll check the tcp for the hotfix. As for the 2023.2 version, is it an idea to add this as a parameter to the create deployment process flow. As a deployment package is created so that the software will be installable at a customer. And therefor it should be used as the start point for the next version. @Arie V Thank you for the insights. Now as for our build and deployment strategy for Thinkwise Applications. (As theses are linked).We use Azure DevOps for both the build, as the deployment of said applications. We have a simple build tool which runs the create deployment package task (start_deployment_package) trough indicium. When the build completes, we move the upgrade database scripts and the model to a git repo, and commit them.This triggers a new build which takes all database script & the model, and packages them as a build artifact.For deployment, we first run all the migration database scripts on the target database. We have tooling in place
Thats great to hear, thanks.
HI, Is there any indication when and/or if this problem is fixed, as we are experiencing the same error with the combination web UI and universal.
Yes that was it. I’ve upgraded indicium from version 2022.2.13.0 to 2022.15.1 and the problem is solved.Thanks
Ah, right i’ve missed this part of the docs. This was the setting i was been looking for.Thanks, this fixes our build process.
Hi Vincent,using response_mode=query is the missing link. The lib i’m using defaults to the form_post response type. After adding the correct configuration, the redirect works without an issue. for anyone with the same problem in .net using the Microsoft.AspNetCore.Authentication.OpenIdConnect .net package. Add the following line to the openIdconfiguration: Kind regardsEdwin
Ok found it. For future reference, I was looking for the card list configuration on the subject.
We have implemented Whatsapp integration with the use of the Twilio platform. Just like the facebook api itself, you can use the HTTP connector for the request. You communicate with the twilio servers in this solution. This has 2 benefits for us over the use of the direct FB api. Send a message with just one call to the webserver; it uses a token based scheme for sending messages, the actual interaction with FB is handled by twilio. Effectively this means we only have to send and parse just one request / response, making the processflow a lot easier to create and maintain. This allowes us to have an fallback to SMS when the number you are sending the notification to does not have WhatsApp.
hmm, how did i mis that… ok the “first” image is the one attached below
Hi Jasper, yes this probably would solve the issue. As the created foreign keys from the "base/generated" tables to "project" tables are no longer removed. Any idea when this feature is planned?
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
