Store table order and paging size a user select

[mPokornyETM]

fix #411
closes #404

Fixed:

• After few discussion with @uhafner it will be use the table.js script from DataTables. This allow to store user settings:
  • the order a user selects
  • paging size

Also we can spare a lot of code.

• Added column 'Free in %' in labels table. It allows the user to sort most reserved / locked resources at the moment.

What is not fixed:

• When user select one time the ordering it will be stored in browser storage and can not be removed (not by some UI action, can be removed from browser storage as well, but this is not common way) We can implement a button for that, but I thing it shall be implemented in data-tables-plugin instead (maybe it is time to contribute in other plugins too)
• The dark theme. I will create an extra issue for that, because it has nothing to do with First adopters complaints about new Lockable Resources Data Tables UI #411 I need more time for analysis, but this changes are important at the moment.

Note: I have try to store also filter text, but it provides more unclear view. There is no indicator in search field (that you has set it it) and you are wondering, why you see only few resources. Therefore I skip this idea.

Testing done

There are few java changes but the changes are hit 100% by code coverage, therefore no new automatic tests. I provide many manual tests and it looks pretty good.
Ordering and paging size are stored for both tables. It works in following cases:

• page refresh
• close browser and open page again
  (tested with Chrome Version 107.0.5304.121 (Official Build) (64-bit))

Proposed upgrade guidelines

N/A

Localizations

• English

Note: There is new key 'labels.table.column.percentage' which shall be translated by Crowdin. I tries my best to translate it in all supported languages, but I am not 100 % Sure (@gounthar maybe you can check French here)

Submitter checklist

• The Jira / Github issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
  • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during the upgrade.
• [ ] There is automated testing or an explanation that explains why this change has no tests.
• [ ] New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• [ ] New public functions for internal use only are annotated with @NoExternalUse. In case it is used by non java code the Used by {@code <panel>.jelly} Javadocs are annotated.
• [ ] New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease the future introduction of Content Security Policy (CSP) directives (see documentation).
• [ ] For dependency updates, there are links to external changelogs and, if possible, full differentials.
• [ ] For new APIs and extension points, there is a link to at least one consumer.
• Any localizations are transferred to *.properties files.

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There is at least one (1) approval for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• [ ] If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• java code changes are tested by automated test.

[uhafner]

• The dark theme. I will create an extra issue for that, because it has nothing to do with First adopters complaints about new Lockable Resources Data Tables UI #411 I need more time for analysis, but this changes are important at the moment.

This is tracked as https://issues.jenkins.io/browse/JENKINS-68677

[mPokornyETM]

• The dark theme. I will create an extra issue for that, because it has nothing to do with First adopters complaints about new Lockable Resources Data Tables UI #411 I need more time for analysis, but this changes are important at the moment.

This is tracked as https://issues.jenkins.io/browse/JENKINS-68677

@uhafner thx, I see the issue is open, But there are some parallel fixes. What shall be done to fix this issue also here?

[uhafner]

• The dark theme. I will create an extra issue for that, because it has nothing to do with First adopters complaints about new Lockable Resources Data Tables UI #411 I need more time for analysis, but this changes are important at the moment.

This is tracked as https://issues.jenkins.io/browse/JENKINS-68677

@uhafner thx, I see the issue is open, But there are some parallel fixes. What shall be done to fix this issue also here?

The last plugin that needs to be adapted is the data-tables-api-plugin. This plugin uses hard coded CSS values (BS5 light style), these CSS files need to be changed to read the Jenkins variables.

[mPokornyETM]

Great, that means, I can ignore it here and maybe (when I find some time) fix it in the data-tables-api-plugin.

[jimklimov]

Jelly changes look like magic - in a good sense, less hardcoding, more functional :)

But I can't quickly test it at the moment, the server where we had many resources to lock is currently busy with endurance testing a new product release (so can't restart it).

On a side note, could any recent changes elsewhere break the self-tests? Or did they happen to be timing-dependent?
https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Flockable-resources-plugin/detail/PR-415/9/pipeline/91

Expected "Locked resource reservedBy 1-5: null" got "Locked resource reservedBy 1-5: test2-1"

[mPokornyETM]

Jelly changes look like magic - in a good sense, less hardcoding, more functional :)

But I can't quickly test it at the moment, the server where we had many resources to lock is currently busy with endurance testing a new product release (so can't restart it).

On a side note, could any recent changes elsewhere break the self-tests? Or did they happen to be timing-dependent? https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Flockable-resources-plugin/detail/PR-415/9/pipeline/91

Expected "Locked resource reservedBy 1-5: null" got "Locked resource reservedBy 1-5: test2-1"

Sorry for delay, but I try to split the columns in extra jelly pages, otherwise it is too complex and hard to read. But I am currently stuck with the reset button. It looks so that the code can not be hit.
About the failed tests. Yes in normal case it is about timing. In normal case, when I publish PR I starts tests on my dev node as well. When it fails on Jenkins side in normal case helps 'restart failed steps' I dont like it, but I have not time to fix the test as well. Sorry.

[mPokornyETM]

Hm I see it is not good idea. Loading jelly pages takes too long. I must find other solution

[mPokornyETM]

There are 2 testcases, their both takes ~50 seconds on my node. In that case the whole test script achieved 180 seconds timeout on slow nodes. I will try to split this testcases to extra scripts to eliminate this scenario. It is very frustrating to make some changes, replays tests and hope that it do not achieved some timeout. I try to eliminate the time consuming there, but both are to complex for me. I hope the split works. Otherwise I will revert test changes here. Has nothing to do with my changes and waste my time. 😪