Hi everyone,
I’m really happy to announce that we’ve just launched a possibility for Connect apps to register modules at runtime.
Read the docs here:
The initial release allows two module types to be registered dynamically (entity property extractions and issue fields) in Jira Cloud, but we plan to add more. If you have any specific requests, don’t hesitate to let us know.
That is indeed very cool and useful! 
Will this come for Confluence as well?
I’ll answer
I agree with Jon. For my personal use cases I’d especially like to see
Dynamic modules like these wouldn’t only allow for more customization of the app but also enable new and more creative ways of building apps.
If you’re adding more modultetypes - will the limitation of only 10 items be changed? Would it be possible to change it now to only have 5 of each type? 10 items will very quickly exhausted once you add web-items…
+1 on the dynamic web-hooks since it will allow us to start quickly enable the filtering mechanism since the current implementation of dynamic web hooks is severely reduced in functionality.
I expect apps to use only certain types of modules, not all of them at once, so a global limit for all types shouldn’t be that much different to a lower limit per type.
But of course, we can revisit the actual number in the future, if they prove too much of a hindrance. We started small because it’s always much easier to increase a limit than to make it more severe.
In Jira, we plan for the REST API to remain the only way of registering webhooks dynamically, since it’s optimized for the use case in terms of performance. If you find it too limiting, please create specific tickets in the ACJIRA project, we’ll surely see what we can do to improve it.
Nice. Dynamic registration of macros would allow some pretty significant improvements in UX for us.
We’ve just added a few new modules to the set of modules that can be registered dynamically in Jira Cloud. The entire set is now:
When it comes to webhooks, we still recommend using a REST API designed specifically for registering webhooks on the fly (see the documentation here). However, given that it has some limitations, we decided that registering webhook modules dynamically could still be beneficial.
Note that the total number of modules you can have registered dynamically is still 10. We are open to discussion in this matter, so please let us know in case it’s not enough for your use case. Likewise, if you would like to register any other module type dynamically.
I noticed that Confluence support for this was talked about at Atlas Camp (“Supercharge Your Pages - New Ways to Extend the Confluence Editor”), but not when it would become available? There is nothing in the documentation yet.
Hello, I’ve read the docs and I’m looking for some more information about how Jira does the indexing of dynamically registered and deregistered entity properties modules.
If I have a lot of issues e.g. 300,000, with issue properties and values in them, and I dynamically register an entity property making that issue property data available via an “alias” - how long does Jira take to do the indexing? Can we know when this process is done?
How long does it take Jira to unindex that data if I register the module?
Given that we can’t update a dynamically registered module, what happens if I deregister and then reregister the module in short succession (to, for example, add a new keyConfiguration extraction)?
I’m trying to determine whether to have a single module with many keyConfiguration extractions (and therefore incur some indexing penalty each time I add/remove an extraction), or multiple modules with one extraction each (thereby reaching the 50 limit sooner rather than later and potentially having to merge modules together).
It’s instantaneous. Under the hood there is no indexing done, the module just enables the search in JQL, the data is always indexed for all properties, regardless of what entity property modules are installed. I think this answers all the subsequent questions as well.