I was wondering if there is any means to programmatically close flags created by your app, from another iframe (after the creating iframe has been destroyed).
Here is our scenario:
- Our app is running as an issue glance iframe
- User is in backlog view with issue “TEST-1” selected- our app creates a flag like so:
const flag = AP.flag.create() - normally we can just close this flag with
- User selects issue “TEST-2” - our original iframe is destroyed and our app creates another flag for “TEST-2” (now we have no reference to the flag on TEST-1 and cant close it)
- User goes back to “TEST-1” and we have no way of closing / replacing the original flag on “TEST-1” if it still exists, we are forced to create a 3rd flag - now we have two for “TEST-1”
I guess any of the possible solutions would be great:
- some event to fire which will close the flag with a given id (assuming flag was created by our own addon)
- some way to manually specify timeout, that persists even after iframe is destroyed - obviously we can automatically close, but the default timeout is much too short for our purpose, users do not have time to read the flag.
- Some way to manually close flags by id
- some callback that can be fired when our iframe is closed - so we can tidy up our flags directly
I have searched through the documentation and checked the source code here: Bitbucket but wondering if any others have run into the same issue - or know of a solution?
That’s an interesting scenario. There is currently no direct ability for flags to be closed programmatically by an iframe other than the one creating it. In the options you pass to the
AP.flag.create() method, what value do you set the
close field to?
You may also wish to look at the flag design guidelines. If the default auto close period is too short, perhaps you could simplify the content or use a different mechanism to notify the user.
We currently set the value of close to ‘manual’, because unfortunately the automatic time is too slow (we would probably use auto if it was a bit longer, or could be configured)
I can understand, we should ideally just have simpler content, but in my opinion once we have two actions in the flag, it is an uncomfortable amount of pressure on the user to choose quickly before it disappears.
Probably our only option left is to rethink the ui and how we are notifying users, but it is unfortunate as the flag mechanism works very well for us in server and data center case - and also when in normal issue views (as opposed to backlog / boards).
Actually, there’s an AC ticket about something related: https://ecosystem.atlassian.net/browse/AC-2519. Can you have a look?
Hi @richard.white and @david2,
There do seem to be solutions to this, but they require work on our side. In addition to the get method proposed in AC-2519, it would probably be possible to allow the app to pass in an
id option which the app then later pass to the
close operation. We could automatically namespace these IDs on a per app basis. ID clashes probably wouldn’t be a big issue and the ID wouldn’t replace our internal flag identity scheme.
The only problem is that I’m not sure the team who owns this functionality have bandwidth for this, but I will make sure they are aware.
It’s really disappointing that [ACJS-1133] - Ecosystem Jira (formerly known as AC-2519) has been just closed as “won’t do” with no explanation whatsoever… @dmorrow
Hi @techtime ,
I’ve followed up with the team.
Thank you. Effectively, at the moment there is a UI component that is almost completely useless anywhere on the application screens e.g. Jira Issue View – not only we can’t control how long they are visible, we can’t close them, but also as a result can’t really have meaningful callbacks to our application logic function after the initial iframe is destroyed (since the default visibility timeout is too short, and if the user does manage to click on anything we display – we can’t close the flag)