Pioneer: Applying for storage working group opening and final "Working groups" tab issues

[Lezek123]

Implements: #597

Note that the listing of user's active applications for storage working group etc. is not implemented yet, as there is another issue for that (#618)

ts-ignore issue
While working on this issue I removed the ts-ignore inside /joy-roles/src/flows/apply.controller.tsx as it is a very bad practice to use it, because it silences a lot of potential TypeScript errors during the build. It should have actually been caught by eslinter's ban-ts-ignore rule, but for some reason it wasn't (perhaps because it wasn't added as a valid-syntax comment, but actually a string value inside jsx).

This forced me to fix a few typing errors inside /joy-roles/src/flows/apply.tsx that were revealed once the ts-ignore was removed.

Other pre-existing UI issues
I also decided to list all the pre-existing Working Group tab issues I was able to find in #741 to allow better understanding of the problems that may occur during testing, but were not actually introduced in this PR (I'll try to tackle those once the Working Groups tab is fully adjusted to support Storage Working Group)

[Lezek123]

Updated to include #618 and some of the fixes from #741:

working-groups/my-roles page should now be fully adjusted to work with Storage Working Group. Although in issue #618 it wasn't planned to make it fully compatible (active roles were not considered), I decided to go for it, since it was very easy to implement at this point and makes the Pioneer's support for Storage Working Group complete.

Issues described in #741:

• Fixed the issue with neverending loading screen in case there are no openings available.
• Fixed the applying flow for openings with variable stakes and max. number of applicants specified. User should now be able to correcty determine the minimum stake he needs to specify to be considered when applying for such openings, as well as his position in the "applicants hierarchy" during the first step of the application. Note that if both stakes are set to AtLeast, a different component handles this step than when only one of them is set to AtLeast.
• Fixed role key name generation issue (keys with duplicate names should not be generated anymore)

[mnaamani]

I left a comment about using correct type in one of the tx calls.

Tested the UI. Only thing I noticed that is incorrect (perhaps its existing behavior) but when appliccations are withdrawn, the total number of applications on an opening still counts the withdrawn applications.

Otherwise all works as expected.

[Lezek123]

Added fixes according to the comments.

I noticed that there was a ts-nocheck clause inside Admin.controller.tsx which silenced a lot of useful TypeScript errors. I fixed those and it seems to have simultaneously fixed a few UI issues with the opening creation form at working-groups/admin (ie. there were some problems with changing the stake type between AtLeast and Exact, changing stake values etc. and they seem to be gone now).

I added ban-ts-comment rule to eslint to possibly avoid running into this problem again. There is one more occurrence of ts-ignore in /packages/react-components/src/AddressCard.tsx (which was purposefully silenced, so I just updated the eslint-disable-next-line clause there) and 2 ts-nocheck occurrences in storybook-related files inside joy-roles (which I silenced for now with eslint-disable-next-line, but marked with TODO: FIXME:)

[Lezek123]

Only thing I noticed that is incorrect (perhaps its existing behavior) but when appliccations are withdrawn, the total number of applications on an opening still counts the withdrawn applications.

I don't think I was chaning anything there, it looks like this number just represents total number of applications regardless of their current status (which can be Active, Unstaking or Inactive). It is also displayed for already filled openings etc., so it makes some sense, but I understand that pairing it with max_active_applications can be confusing and indicate that this number means active applications.

[Lezek123]

I actually found another issue related to those non-active applications.

Because the status of them wasn't checked inside myApplicationRank and openingApplicationRanks methods, it caused unreliable rank perdiction and incorrect minStake value when applying in case one of the previous applicants has withdrawn its application.

Should be fixed now.

[mnaamani]

I created an opening with an empty {} json for the human readable text so when I visit the my-roles page it crashes with the following error (I presume its due to not finding the expected properties on the parsed object):

Maybe we should handle badly formatted human readable text.

[Lezek123]

Updated with some UI adjustments following "Make lead hireable" changes (#726) that I already had on my branch locally.

Also merged nicaea to fix conflicts and added a method to parse human_readable_text with fallback to valid GenericJoyStreamRoleSchema object that has all required values set to Unknown in case the actual json is invalid.

[mnaamani]

This is a good rule to have:

'@typescript-eslint/ban-ts-comment': 'error'

might add it to #891 cc: @Gamaranto @kdembler

[kdembler]

That's a good one in general but I would use the option allow-with-description so we can use ts-ignore in specific cases. Recently I've worked with a library with stale typings and had to ignore typescript error to use some newer option.

[mnaamani]

It better to create github issues rather than TODO's in the code. We can label them with good first issue for contributors to find something simple and easy to work on.

[mnaamani]

I'm sure here you mean that you are not handling case when the transaction returns an error, but is still finalized?

[mnaamani]

Works as expected.
One enhancement that I would suggest is in the my-roles, to show in the current roles, the worker id.
This is needed by the storage providers when running their node.