Hotfixes > Trash - The "Restore" button is not functioning

[pcenov]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Observed behavior

The "Restore" button is not working when trying to restore folders or resources from Trash.

restore.mp4

Expected behavior

It should be possible to restore deleted folders and resources

Steps to reproduce the issue

1. Sign in to Hotfixes
2. Go to a channel and delete a folder or a resource
3. Select the "Open trash" option from the ellipsis button
4. Attempt to restore the deleted folder or resource

Usage Details

• OS: Windows 11
• Browser: Chrome, Firefox
• URL: https://hotfixes.studio.learningequality.org/en/
• Caused by changes made in: Release v2025.09.29 #5318

[pcenov]

@radinamatic

[marcellamaki]

This is a regression from current production studio

[marcellamaki]

The immediate "undo" snackbar when moving an item to the trash does still work and properly reverts the item to it's previous place in the channel/folder, so my guess (purely hunch) is that this is about the restore button itself

[akolson]

The restore button not working is definitely related to #5349, with the underlying issue being #5322. The immediate "undo" I suspect is flaky based on the position of which resource is being removed. I tried to remove a resource and it seemed to work so it might require further investigation. cc @marcellamaki @pcenov

[marcellamaki]

okay - so, i think we maybe have two options. we can revert the change that Blaine implemented and see if there is another option for addressing that which doesn't cause these regressions, or we do some sort of additional override for this handful of places where it's causing a problem. i'm leaning towards option (1), mainly because I'm concerned that even with Peter's diligent testing, there may be a handful of places in the UX that we don't catch, that could totally prevent a workflow from happening. But, open top option (2) also, or other ideas. What do you think, @akolson?

[akolson]

1. seems like the more logical option. We could easily fix this by adding an override for the static z-index value in KIconButton. This should help with other z-index wars we've had to deal with elsewhere. Happy to here thoughts about this. Tagging @MisRob @AlexVelezLl for more KDS specific thoughts

[MisRob]

If I can understand you're trying to think about how to resolve #5266 while avoiding global z-index trouble. Using appendToOverlay could help:

<KIconButton ... />
<KTooltip appendToOverlay />

Not sure if this was tried already. If I recall Vuetify conflicts actually inspired appendToOverlay option, and saw it helped.

Alternatively, yes we could override z-index - I'd recommend adding appearanceOverrides to KTooltip though please. Not to KIconButton. tooltip prop is rather for simpler use-cases we don't need to modify. There's no need to add new props such as tooltipZIndex or tooltipAppearanceOverride to KIconButton, when we can use them next to each other:

<KIconButton ... />
<KTooltip `appearanceOverrides={ zIndex: ... }` />

^ This is a very simple change we can add to KDS quickly. @AlexVelezLl recently did similar update for KTextbox.

[MisRob]

@akolson and if you're already certain that appearanceOverride on KTooltip will help with the other issues we recently chatted, please proceed right away, even if appendToOverlay helped. I don't think those two options I mentioned are exclusive. You're familiar with both use-cases, so feel free to try out and choose what you consider best.