Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

Any side effect? I mean, removing ALL "click" events from the filelist might cause issues

Any side effect? I mean, removing ALL "click" events from the filelist might cause issues

There shouldn't be any side effects. From what I gather, the code is designed to attach the relevant events each time the file list gets initialized.

CI now approves of my changes, but I noticed that there may still be an issue deeper within the code.

Here's the specific line in the code:

The first time _createRow() is called, fileData.shares[0].expiration is null as expected from /ocs/v1.php/apps/files_sharing/api/v1/shares. However, after clicking the element (and subsequently calling the _createRow() again), fileData.shares[0].expiration is an integer 0. I can look into this when i have more time, but maybe this is not even an issue at all?

I think we should look into it, at least to know why that change happens (maybe it makes sense, or maybe we can't do anything about it)
I'm ok if we want to merge in order to release this fix "soon" because I don't expect any additional bug, but I'd rather fix the real issue (if there is an issue) than putting a band-aid because there could be other related bugs.

I've identified the reason behind it returning a value of 0 instead of null after clicking. When you click the element, it fetches the attributes from the model, which, in turn, retrieves the data from the jQuery object: https://github.com/owncloud/core/blob/b451ac539617129632f262cabc61e84a0ec8e579/apps/files/js/filelist.js#L448C3-L457

The reason you get the integer 0 is because of these specific lines in the code:

I'd need to check the documentation... If the API is documented to return null if no expiration is set (which makes sense), and then the web UI converts the value to 0 for its own purposes, I think it's ok, but there should be a comment explaining why this is needed. The obvious alternative would be to handle the null value differently, which I think it's the natural thought.

I'd write a comment with a brief explanation, at least to know that we need to handle those 2 values.

file changelog/unreleased/41056: title is too long (max 80 characters) 🤷 @steelcuts

@steelcuts I took the freedom to finalize this pr

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information