[BUG]: Incorrect display of hashlists in the super hashlist table

[gpascal123]

The same hashlists are usually displayed, although different hashlists are assigned to each superhashlist.

In addition, the API returns incorrect entries, sometimes several hashlists are returned, although only one hashlist is assigned to the super hashlist.

API call that returns incorrect results:
http://localhost:8080/api/v2/ui/hashlists?maxResults=25&startsAt=0&expand=hashType,hashlists&filter=format=3&ordering=-_id

In the assignment table (HashlistHashlist) of the database, the hashlists are correctly assigned to the super hashlists, there are no multiple assignments.

[gluafamichl]

There are two bugs:

• Frontend does not show the correct names of the hashlists, fixed with PR for issue [BUG]: Incorrect display of hashlists in the super hashlist table #1109 on frontend
• The method getManyToOneRelation in the new API does not handle ManyToOne correctly, all duplicate entries are removed from the results. As soon as a hashlist is contained in more than one superhashlist, the mapping is wrong, because entries are missing in the intermediate mapping. Still has to be fixed.

[gluafamichl]

From my understanding, the function getManyToOneRelationViaIntermediate() in the AbstractModelAPI should be renamed to getManyToManyRelationViaIntermediate, because we are dealing with many to many relations. A superhashlist may refer to several hashlists, but a hashlist can belong to several superhashlists.
And it should be fixed, because if we have a real many to many relationship the assignment from childs to parents is wrong.

• Superhashlist A contains hashlist X
• Superhashlist B contains the same hashlist X and hashlist Y
  => Hashlist X is only assigned to Superhashlist B, the relation from X to A gets lost in the API

[jessevz]

Hi I am pretty sure these API issues are already fixed within the fork im working at, but it is good to test for when we are in the review phase