How can we tune a custom app logo ?
Can this be done on the fly via the API ? Meaning, could I update the logo for each notification ?
Or is that a static image that should be configured somewhere ?
it’s not possible to set the image per-message (https://jira.atlassian.com/projects/STRIDE/issues/STRIDE-1911), but you can set it permanently for the app on https://developer.atlassian.com/apps -> Your app -> Three dots menu next to app name -> Edit App details.
this solution obviously does not work.
Is that because it’s beta ?
Non of our custom apps appeared here : https://developer.atlassian.com/apps/
Is that because our environment is a sandbox and we’ve not officially migrate from hipchat to stride ?
We have a bunch of rooms where we sent notification using API : this means we already have few apps keys.
looking forward to reading from you
you must be using API tokens. Sorry I misunderstood you and thought you were using full apps.
Unfortunately, you’re out of luck for now, then. This does not currently exist.
Understood. But can we achieve the same if we build a full app as with API token app ?
As far as I’ve understood, full apps’ capabilities are a strict superset of what you can do with API tokens.
But they are also more involved, since you’ll have to provide a server component to handle at least the lifecycle events. And that has to be hosted somewhere and so on…
So if you really only want to send notifications to Stride on occasion, I’d say stick with API tokens and live with not having a logo. But if you want to do something more involved like ChatOps or bots, go for a full app. They’re not that hard to get started with and gain you a lot more control.
Yes I figured out how to create and install my app.
I also had a look at the page about getting a token for it.
And eventually, yes I noticed the kind of blocking point so far that could be the lifecycle.
thanks a lof for you help, I’ll close that ticket.
Sorry Tobi, me again.
Where can i have the full documentation for apps ?
Is there a way to increase or even make infinite the “expire_in” argument received in the response of the demand of token?
This seems to be by default, 3600 seconds.
Full app documentation can be found here: https://developer.atlassian.com/cloud/stride/
There is no way to extend the lifetime of an access token. You’ll have to request a new one every hour (or when you do a request and notice that the old one expired). Some libraries (like the stride-node-client) will take care of that for you.
If I had to make an educated guess, I’d say that’s a security feature. If one such token got into the wrong hands, an attacker could read message histories, read out user profiles, etc. With an API token, all they could do is send messages, so there’s no risk of privacy loss, so it’s okay for these to be long-lived.
Thanks again for this accurate reply.
I fully agree with you regarding the security issue why this has been set this way. I came to the same conclusion.
And as you, I think that it’s a kind of bazooka given all the authorizations you’ve have to be granted prior sending any messages.
Anyway thanks for the link to stride-node-client, I might consider it.
Kind regards and good luck for the badge, you definitively deserve it.
A point of clarification. As it’s implemented now, if you don’t need the installation events, and don’t declare them in the descriptor, you can proceed without them. Without the installation events your app won’t know where it’s been installed. This would facilitate a bot that just responds to messages, but not much else. This setup isn’t very useful for bot’s that send messages to rooms due to external events, and it also prevents the bot from giving a helpful description of it’s capabilities upon installation.
Hi Jon, not sure how I should link your remark and the fact I would have like not to hassle with “expire_in” settings.
@jross Did not know that. May i suggest amending the descriptor docs with that information?
@b2t Not having to provide the lifecycle endpoints would make this whole thing a lot easier if you really only want to send messages to a single room on a single site.
You could probably statically host the descriptor (which would be very short with no modules and no lifecycle section) and the code that submits the messages would have to get an access token and before actually submitting a message.
It’s still a little bit more involved than just sending off messages with an API token, but just barely. Just amend your sending function to get an access token first and you’re done.
Jon, please correct me if I’m wrong here.
Thanks for clarification.
Will see… not very fond of generating traffic for “nothing”. We could have a lot of notifications and this will simply double them.
@tobitheo I only just experimented with it and found that information out, so modifying the doc’s will happen soon to correct it.
I think you could be correct about statically hosting. I’ve yet to try hosting a descriptor anywhere but the same place as the service.
You can see a lot implementations of the Application Card using the Hello World Demo App in glitch.
Once it’s installed, you can @ mention the bot and with
@hello world glitch 4 and it will reply back with a lot of examples of the Application Card features.
You can inspect the different mention cards using the Message builder and modify them live to see changes.