Added get group challenges route and initial tests

[TheHollidayInn]

This address Get challenges for group and tests in #6509. I didn't see much logic here that needed to be abstracted, @paglias . Let me know if you disagree.

[crookedneighbor]

The _.findIndex syntax is a little clunky in the expectation. There's got to be a better way to write that expectation.

[TheHollidayInn]

Yea, I agree. I was trying to use the chai .include, but the object aren't equal. I'll look through the documentation a bit. Maybe, we can extend chai to use lodash.

[crookedneighbor]

The chai things plugin might be helpful. http://chaijs.com/plugins/chai-things

[KristianTashkov]

@blade when I suggested the same plugin you said you prefer not to have it 😢

[KristianTashkov]

On a more constructive note, in such cases I do:

let challengeIds = challenges.map((challenge) => {
  return challenge._id;
});

expect(challengeIds).to.include(challenge._id);

[paglias]

@TheHollidayInn the PR looks good, a few things:

1. To keep consistency with how tasks are fetched I would rename api.getChallenges to api.getUserChallenges and use an url like GET /challenges/user.
2. I just realized both in getUserChallenges and getGroupChallenges we want to populate the leader and group data (the code is already there but commented). For populating the leader instead of hard-coding profile.name in the selected fields you can import nameFields from '../../models/user'; as we're doing when populating the group leader

[paglias]

I just noticed we don't have tests for getUserChallenge either so it may be a good occasion to add them!

[paglias]

Actually don't add population, I'm not sure if it's really needed. We'll add it later if it becomes necessary

[crookedneighbor]

@KristianTashkov I thought you might say that. 😄

I don't recall the exact details of why you wanted to use it, but I don't think the assertions looked quite as messy as these do. In any case, I think you were right, this would be a good plugin to add.

[TheHollidayInn]

So, Chai Things does not play well with Chai Keys: chaijs/chai-things#24 .

[crookedneighbor]

If we can't use chai-things, I'd prefer this to be something like

let foundChallenge1 = _.find(challenges, { _id: challenge._id });
expect(foundChallenge1).to.exist;

[paglias]

@TheHollidayInn why you added this check? challenge.hasAccess should haveve been enough

[KristianTashkov]

From what I undestand, you should be able to join challenges in public guilds without being a member of the guild and I guess this fixes it. But probably this logic should be put in hasAccess

[paglias]

That's right, good catch

[paglias]

And yes, this logic should be in hasAccess

[TheHollidayInn]

@KristianTashkov Yep, this is exactly the case.

I'll move the logic. :)

[TheHollidayInn]

Actually, it seems the challenge.canView callas hasAccess, so basically, we only need to check viewAccess.

[paglias]

Except for my last comment it looks good!

[TheHollidayInn]

Updated!

[paglias]

@TheHollidayInn thanks!

in the end i preferred to use a modified hasAccess that will work with public guilds too so it's almost the same as canView except that it doesn't return true if you're already a member of the challenge because that's handled separately by challenge.isMember and in case will return a userAlreadyInChallenge error.

[TheHollidayInn]

Sounds good, thanks!