Update files table in Projects

[Bubballoo3]

Fixes #3930. On hold until #4829 as this relies upon the existing work there in breakpoints. The major addition in _files.html.erb is an ERB equivalent to actionsBtnsTemplate in data_table.js, allowing us to perfectly replicate the look of the file action buttons.

The issue of the table overflowing was solved by removing rows that were less necessary. For private projects, we hide owner/mode, as these are not relevant there. For shared projects, we only show all columns at xl breakpoints, otherwise hiding the size and time items. This way the table stays lean enough at smaller screen size to stop overflowing, although long usernames can make it overflow slightly (singleton188 overflows by about 5px, bsingleton and johrstrom do not). This is still far better than the current version though, and I don't love the idea of clipping a username. To get as much space as we can, we also reduce the padding between the files table and the widget border and between the actions dropdown buttons and other items.

Finally I made a few QOL improvements, adding human size to the file sizes and formatting the mode to match the files app. I could not find a way to get the human size to use B in place of Bytes (which it does in the files app), so suggestions there would be appreciated

[Bubballoo3]

I have taken your feedback from #4829 (comment) and used the same javascript function as in the files app. Because it was a class method of DataTable and is nice to have available everywhere, I moved it to utils.js instead of trying to export it directly. Since space is at more of a premium here than in the files app, I also added a parameter for precision, allowing you to control the number of decimal places in the final number. I decided to go with rounded whole numbers for the project directory table.

[Bubballoo3]

No longer on hold as #4829 is merged

[johrstrom]

I think this table really needs to move if we're going to show all these things for shared projects.

You can see how the columns don't align with the headers when it changes/hides things.

My guess is the simpler approach would be to simply move it so it always has the real estate to show what it can show.

[Bubballoo3]

the columns don't align with the headers when it changes/hides things

🤦‍♂️ it should be hiding the time at that width, it must have broken in one of the merges, but is fixed now

My guess is the simpler approach would be to simply move it so it always has the real estate to show what it can show.

Does this mean you don't like the approach of showing less data at certain screen widths, or just that we need to strike a balance that ensures we have enough space for only the limited data that we want to show? The toggle piece is a bit delicate, but only because the headers and data are in different places (_directory vs _files) and the data changes depending on whether

• file is a directory
• project is private
• screen width is below breakpoint

But as long as we get those three conditions working together properly it should look pretty good at all sizes

[johrstrom]

My guess is the simpler approach would be to simply move it so it always has the real estate to show what it can show.

Does this mean you don't like

I mean like maybe it should have 100% of the width below the launcher + job elements. Something like this structure where it's got it's own row on any display.

| launchers | jobs  |
|       files       |

[Bubballoo3]

That's not a bad idea, but possibly tough to implement, as the current launcher section tends to stretch pretty far down (pushing down the files widget in your example, while the current arrangement tries to keep everything visible at the top. Now it's possible we could place workflows and launchers side by side and use this space a bit better, both of those columns are also collapsible which is kind of nice, but still more effort to reorganize that than get the files app working in the space it already has.

So I guess what I am asking is whether the current iteration with that bug fixed resolves your concerns or if it still feels too cramped. My opinion is that this works well for right now, but we definitely don't have space to add a third data item at those smaller breakpoints (why we show either size/time or owner/mode) so it could be forward-thinking of us to reorganize those now instead of waiting for the request. That being said, as we previously mentioned, these widgets are intended to be lighter versions of the full tools, so if someone wanted more data about the files they can still get it with 'Open in Files'

[johrstrom]

I'll take a look and think on it, but one thing is is that Launchers are vertically collapsible.