Hi There,
We have been going over the documentation on forge development and we were reviewing the risk assessment example here: Bitbucket
If we only had one drop down selection, does it always have to pop up as separate screen to enter the information? Is is possible to change the behavior so that you can select it just like a normal drop down custom field?
Thanks
Hi @FabianLim and welcome to our community,
At this stage, inline editing for custom fields is not possible but we have a feature request here that you can follow for updates: [FRGE-243] - Ecosystem Jira
Caterina
Thanks for the clarification.
@CaterinaCurti any movement on this? I tried it out again this morning and while it looks like the render: native helps with the issue create path, the editing still launches in a modal. This is problematic when using collection: list to get a Select custom field because the options get clipped when it’s in the modal-dialog, creating a UX and Accessibility nightmare.
We are working on custom fields inline edit support at the moment. Can’t give you any estimates on when exactly it will be ready though.
Could you please let me know why the dropdown options are clipped? I’d expect that with render: native that shouldn’t happen because components are rendered on the host without any isolation. If this issue happens with custom ui (contents is rendered inside the iframe), what you could try is to add a bit of whitespace below the dropdown, so when the options are shown, they aren’t clipped. This is a workaround of course, but there is no better option at the moment. I’d recommend to use UI kit 2 (render: native) for small (UI wise) modules like custom fields, because it eliminates many UX issues and is also faster.
Thanks,
Vitalii
I am trying to migrate old CustomField and CustomFieldEdit (UI Kit 1) modules to the new UI Kit, and I can confirm that the dropdowns are clipped. As a workaround, I needed to add padding, which makes the modal look funny—a big modal with a single-line field.
There are also many other problems, especially when it comes to validation. For example, on the Create Issue view, the platform validates required fields, but on the Edit view, it does not. You need to write the validation yourself. In fact, on the Create Issue view, you can’t add validation because the onSubmit method from useForm won’t be executed, so you end up with a completely different implementation based on the context where the view is rendered.
And the problems don’t stop there.
We’ve got your report about the regression and will start working on the fix shortly. Also I’ve just talked to the developer who’s working on the inline custom field edit, and they have confirmed that dropdown options won’t be cut in the new version.
Thanks,
Vitalii
This is using render: native and the latest UI Kit 2 components. Happens just using a Modal and Select. I was on the Atlaskit/Design System team and helped build the Select component 
— the problem is that the menu is clipped by the scroll container — the component allows for “portalling” the menu, which we did in 90% of the implementations to avoid the clipping. I’m guessing it’s not done in the Forge version because of the iframes. However when using render: native there’s no iframe so portalling should be safe to use.
Adding padding to the bottom is not a reliable workaround as it fails as soon as the users zoom their UI or if they’re working on a smaller display without much vertical space (like a laptop). Portalling is the go
You are 100% right here, adding padding is not the way forward, it was just a suggestion to temporary workaround the issue. I’ve mentioned in the message above that in the inline edit this problem doesn’t exist (we just need to finish the feature). I have also passed the info about clipping dropdown option to the team that works on UI Kit components.
Thanks,
Vitalii
I just saw the new inline edit component is released, however using this with the custom field still opens the editing in a modal. Will this be changing soon? It would be nice if we had some control over what happens when you click the value on the issue…
Also if it’s all render: native then it shouldn’t need to be in a modal right? Just swap the view to edit and render that in-place.
Yep, it will change soon, we are still working on it. In the final version the edit will happen inline.
Thanks,
Vitalii
Hi Vitalii,
I’ve had a play with the new inline-edit components and while they work okay they’re inaccessible. There’s no label associated with the input that shows up, and if you do a custom one (eg not the easy one with just specifying it in the manifest) there’s no API to associate the field with the text for the field on the issue page. This is really important for compliance, and it’s preventing me from using inline-edit until it’s resolved as my app is all about accessibility compliance. If I refactored to use inline-edit then my app would be unusable for someone with a screen reader.