Implement file actions menu

[skjnldsv]

Fix #7

---

Issues, please give your insight

• Actions are not really reactive, clicking favourite does not change the menu item
• What would be the behaviour of clicking rename? Closing the slideshow?
• Lots of the actions require that the file is in the list, but the slideshow doe snot care about this and does not pursue loading the main files list. I'm not sure how to handle this case. Shall we scroll down while pressing next on the slideshow?
• How to properly detect the file deletion? If I click delete from the menu, it gets deleted in the backgroud, but how can I make the main app to know? I want to avoid creating dedicated edge-cases on the viewer (like if action === 'delete') because it would be a nightmare to manage. Thoughts?
• The popovermenu get hidden by the sidebar when opened. I can't get my head around this, since the modal is fixed, any children zindexes is ignored, therefore the sidebar can be under or above the whole modal, but cannot be between two element of the modal content! 🤷‍♀️

[ChristophWurst]

Have the issue been addressed?

[skjnldsv]

@ChristophWurst No, I'm asking for input 😁

[juliusknorr]

Actions are not really reactive, clicking favourite does not change the menu item

This needs some deeper digging into apps/files/js/tagsplugin.js. But I fear that we won't be able to easily reuse the existing tagsplugin and get reactivity. A quick test with forcing the rerendering of the actions computed property after executing the action didn't have any effect, since the tagsplugin seems to manually change the element of the rendered popoer in the file list.

What would be the behaviour of clicking rename? Closing the slideshow?

👍 Otherwise we could also introduce some editing view in the modal header (where the filename is), but not sure if we should have this logic added to the viewer.

Lots of the actions require that the file is in the list, but the slideshow doe snot care about this and does not pursue loading the main files list. I'm not sure how to handle this case. Shall we scroll down while pressing next on the slideshow?

I'd say so, although we will need to extend FileList.scrollTo to disable the details view.

How to properly detect the file deletion? If I click delete from the menu, it gets deleted in the backgroud, but how can I make the main app to know? I want to avoid creating dedicated edge-cases on the viewer (like if action === 'delete') because it would be a nightmare to manage. Thoughts?

The only way I see here, would be to use backbone events on the files list collection to trigger update of the viewer if the file list data changes.

The popovermenu get hidden by the sidebar when opened. I can't get my head around this, since the modal is fixed, any children zindexes is ignored, therefore the sidebar can be under or above the whole modal, but cannot be between two element of the modal content! woman_shrugging

The sidebar has a z-index of 10001 so it still has precendence as the modal has 9998. Anyway we should close the modal if we show the sidebars or take some other action that is happening in the main files view.

[skjnldsv]

Otherwise we could also introduce some editing view in the modal header (where the filename is), but not sure if we should have this logic added to the viewer.

Yes, this is out of scope for the viewer I'd say.

I'd say so, although we will need to extend FileList.scrollTo to disable the details view.

Let's see if I can select the file like that.

The only way I see here, would be to use backbone events on the files list collection to trigger update of the viewer if the file list data changes.

Doable externally with pure js events?

The sidebar has a z-index of 10001 so it still has precendence as the modal has 9998. Anyway we should close the modal if we show the sidebars or take some other action that is happening in the main files view.

Or disable the menu when the sidebar is opened?

[juliusknorr]

Doable externally with pure js events?

Not with our current file app implementation.

Or disable the menu when the sidebar is opened?

I think the modal should still overlay the sidebar as well and be closed once the sidebar is accessed. Otherwise we run into overlaying issues on bigger images/smaller screen size:

[jancborchardt]

Very nice!! :)

• The 3-dot menu should be directly on the right of the file name, not next to the close X. It belongs to the file (name). → scratch that, this will get janky because of file name length variations. Let’s just keep these actions on the right.
• The share action should be outside of the menu, just like it is in the list view. Or if it’s in the list view, it needs to be further up, directly after favorites.
• Why is "Comment" another action there? Let’s not add more stuff in this already long menu. ;) As soon as finally the Activity+Comments+Versions timeline is done, it will be reachable via "Details" anyway. 📑 Sidebar: combine file Activity and Comments into »Activity« timeline tab (possibly also "Versions") server#658

[jancborchardt]

@skjnldsv guessing this is on hold cause of other commitments? Is this still on for 17, or likely not?

[skjnldsv]

@jancborchardt Yes this is still pending :'(
Though I could use a bit of insights from @NastuzziSamy 🤗
How do you get the full action list on a file and how do you properly trigger the action?

Looks like a great idea to tackle during the hackweek ;)

[skjnldsv]

@juliushaertl Samy still uses a copy of the current menu html dom.
Do you have proper pointers for me to get the menu from the Filelist js '''api'''? 🙏

[juliusknorr]

FileList.fileActions.getActions('image/jpg', 'file', OC.PERMISSION_ALL) should work for that. The main issue is that the actions always require the file list entry as context attribute, as already mentioned last week. 😞

I'm not sure right now how we could fetch the file list in the background properly apart from a hacky call to FileList.scrollTo(filename). After that you could use FileList.findFileEl(filename) to get the actual row.

[szaimen]

Sry but any update here?
Would be really nice to get this feature!

[skjnldsv]

@szaimen would be nice :)
But it actually requires some server fixes so that actions are properly implemented ;)