[WIP] More flexible file actions API in web UI

[PVince81]

Description

Make it possible to register functions instead of action specifications.
The function takes a FileInfoModel as input and decides whether to return an array of matching actions or not. This way it is possible to customize file actions based on any kind of attributes of the file model.

Related Issue

Required for #30106 list pending shares.

Motivation and Context

Required for #30106 list pending shares where the file actions for pending shares would depend on the share state.

How Has This Been Tested?

Not yet.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

Merging #30478 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #30478   +/-   ##
=========================================
  Coverage      61.5%    61.5%           
  Complexity    18487    18487           
=========================================
  Files          1090     1090           
  Lines         61050    61050           
=========================================
  Hits          37551    37551           
  Misses        23499    23499

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 664d985...24dfe32. Read the comment docs.

[PVince81]

Fixed the tests, but I'm a bit worried about a potential memory leak. After fixing some errors I noticed that I could run all tests with 2 GB memory but with recent changes I need to set it to 3 GB to avoid phantomjs crashes.

• worry about memory leak
• worry about this not being the best solution as it introduces additional overhead by having to iterate over all action returning functions

Maybe a simpler solution would just be to:

1. add an optional isVisible handler for every action which receive the current file to find out whether or not to render the action
2. add a global handler onAfterGettingActionsList(actions) which would allow handlers to modify the actions list and add/delete entries when needed.

[PVince81]

Basically we have two requirements:

1. the ability to hide actions that were already registered for specific file properties (conditional filtered)
   and
2. the ability to display specific actions based on specific file properties

tried to think of simpler ways to do it:

• Approach 1:

  • hacky: create a subclass of FileActions and override getActions or _defaultRenderAction to pre-filter existing actions
  • define a FileActions entry for "all" but filter out actions (here: accept/reject) in the render method. or put the logic in _defaultRenderAction

• Approach 2:

  • like Approach 1 but provide a hook to filter actions called after getActions() inside the display() method.

• Approach 3:

  • this PR
  • but changes too much and will likely break many things

[PVince81]

I went with approach 2 in #30106.

Anything else is too complicated and prone to errors. We'll likely want to rewrite file actions from scratch and ditch the legacy stuff at some point instead of working around it...

[phil-davis]

Removed backport label since this PR is closed/superceded

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.