I have set YouTrack integration from Crashlytics setting. It's creating tickets in YouTrack as per level set. But I also want to set some fields automatically in all those tickets created on YouTrack by Crashlytics.
Fields like - State of that ticket (new/open) and Version number of the app crashed.
Is there any way to do that programmatically through any script or settings?
I'm not aware of Crashlytics -> YouTrack integration details, but if you can somehow distinguish the issues created by this integration, you can then modify them by a YouTrack workflow.
Related
I have a functioning Google Sheets Add-on that is listed in the Google Workspace Marketplace. I've made changes in the new Apps Script Editor and tested them locally, now I want to push them to my users.
The process as I understand it, to press "New Deployment"
add a description and press "deploy"
after which I copy the "Deployment ID" into the Google Workspace Marketplace SDK page,
and hit SAVE in the bottom.
It's been a few hours and I still cannot see it being live.
Is there a review process for updates like this? Or am I missing a step?
The previous version is still being served to users as far as I can tell.
Update in response to the comment from #ziganotschka
I am making a Google Sheets Editor Addon, and I'm only now understanding the difference between that and the Google Workspace Addon. I've resubmitted my store listing for review with Google Workspace Addon disabled, and removed the "Common" part of my manifest. I've updated the "version" number to correspond to the latest deployment.
Is it not possible to test a Sheets Editor Addon from the new editor without deploying it as a Workspace Addon? And should updating the version number be sufficient to roll out an update?
From the question
Is it not possible to test a Sheets Editor Addon from the new editor without deploying it as a Workspace Addon?
It depends on what kind of test do you want to do, if your Apps Script project is bounded or a standalone project and what do you Editor add-on does and how it does that.
I.E. you might test a simple edit trigger (onEdit) by using a function for mocking the edit event object and passing it to the onEdit function. To be clear this doesn't need to create a new version and for testing and add-on it's not necessary to make a new deployment.
And should updating the version number be sufficient to roll out an update?
It depends on if the Cloud project OAuth consent screen was set for external use or for internal use, in the new version requires new scopes.
Let say that you fixed typo on a variable name, in this case only creating a new version and adding the version number to the add-on configuration page will be enough, but if you added a sensitive API and you add-on is set for external use, then you will have to update the OAuth consent screen and wait for Google review and approval.
I'm not getting any crash report data on the application dashboard for an app that I had previously setup and configured on a different organization account. I'm able to upload and distribute builds but the crash report data goes to the previous account's dashboard. I thought deleting the app from the previous account dashboard would fix the issue but after deleting the app I'm not getting crash report data in either account now. I don't want to loose the uploaded builds or release history otherwise I would have tried deleting the app from both places and trying to configure it again from the account where I want to distribute builds and receive crash data.
Thanks for reaching out. It sounds like the old organizations API keys are still cached in your app. Please clean your app and check the info.plist and run script build phase (or if Android, AndroidManifest and/or fabric.properties file)
We have some legacy apps on the Fabric dashboard though not sure if we'd ever needed them again so we could delete them from the dashboard.
If we do republish them, can we undelete them later?
If not, could we get another Fabric key to republish them with?
If you re-onboard the deleted app, by installing one of the kits, and building and running your app, it will re-appear on your Fabric dashboard. The historical data won't be available though. If you recently deleted an app by accident and need to restore the original app and data, we can help you out at support#fabric.io
Having tried Upsource we don't have a compelling need for it at the moment, so I've removed it from our integration server to reduce the load.
Upsource has been removed as a service from Hub.
In YouTrack, if I go to Administration...Upsource Integration Settings, I still have a link between YouTrack and Upsource. I can disable it, but I can't see any UI that lets me delete the link between my YouTrack project and Upsource project.
On the VCS changes tab in YouTrack it then complains about Upsource integration being disabled.
How can I remove the Upsource link from YouTrack?
It's only possible to disable Upsource integration at the moment, not remove it. Here's the corresponding feature request: https://youtrack.jetbrains.com/issue/JT-35295
We have already delivered the 1.0 version of our Worklight application. By mistake we have disabled the Direct update feature by updating the attribute "connectOnStartup = false"
We dont want to redeploy the application to markets (AppStore/GooglePlay) again, but wanted to make our users to utilize the direct update feature. We do have the access to WL server.
Our issue is little different from the one which is already discussed here "IBM Worklight - How to disable Direct Update?"
How can we provide the direct update feature to our end users without redeploying the application to AppStore/Googleplay. And just by changing the Webresources of the application.
We are using the adapters in our application but no where we are explicitly calling the "WL.Client.connect".
The Direct Update feature is always enabled by default.
You need to edit your question and explain what it is you've done in your Worklight project.
The feature will not work if:
You have set connectOnStartup:false
You are not using WL.Client.connect
You are not invoking adapters
You disabled it via the checkbox in Worklight Console
Otherwise, the feature will work, and a check for Direct Update will be performed:
On application startup
On return to foreground
The application will need Re-deployment on the App stores.
So the solution to your problem is
Rebuild the Application with connectOnStartup:true.
Redeploy the Application on App Stores
Once the users download the updated application, future updates will go to the users directly.
While rebuilding, make sure that you change the Version of your application within ApplicationDescriptor.