Thanks Pawel!
You are right. Putting “isInline” within “edit” and Wrapping the component in a Modal works fine!
I didn’t put enough thought into the “isInline” property. I should have looked it up, but for me it did make sense to put “isInline” at the root of the module. Similar to “readOnly”, it could have effects outside of the edit UI itself.
That being said, I also expected there to be a schema for each module and that forge lint would check the manifest against it. However, I do understand that the versioning of that schema would be difficult.
But honestly: Why the approach with isInline? You essentially deprecated the default behavior for custom field edit without any feedback for developers. The snipped in the documentation of jira:customField without isInline in jira:customField:edit is essentially broken until you make isInline the default.
An easy improvement would be to add a warning to forge lint that makes sure you use isInline in jira:customField:edit until isInline is the default. That would have informed me that I am deploying deprecated functionality. But from my point of view, the main problem with the isInline approach is that long term you are trying to make the exactly same manifest behave differently across versions just for the sake of keeping it clean I guess? Why not jira:customField:editv2 for example?
Anyways, thanks for clarifying the use of isInline and also showing the use of CustomFieldEdit, which is very much confusing as well.
Kind regards,
Maximilian Seidler.