Do not inject include twice, expand and validate include in aggregate

[verdier]

Refactor $injectScope to better checks existence of include in options.include based on the related association. This PR also fix a bug where include are not validated/expanded in model.aggregate.

Fix #4986
Fix #5121
Fix Cannot read property 'association' of undefined

[verdier]

@mickhansen could you review my pull request?

[mickhansen]

Applying the same scope twice should ideally not fail.
Looks like PR might break using multiple scopes?

[verdier]

You are right @mickhansen applying scope twice should be neutral. I'll have a look.

[verdier]

@mickhansen I have found the problem, $injectScope badly check the presence of the included model into options.include:

If $injectScope is called but options.include[i].as is defined and equal to the default value of the related association, the implementation does not detect that models are equal. This is fixed by checking the related association.as property.

To do that, I have made $injectScope an instance method.

[verdier]

@mickhansen every thing is green. I think it's ready to be merged.

[mickhansen]

Gonna need @janmeier to take a look on this one.

[verdier]

@janmeier @sushantdhiman this PR fix #4986 (like #5090) but is a better solution, because it check equality based on the related association.

Compared to this one, #5090 can result in false equality. If sameModel is true and item.as is defined but not scopeInclude.as include will be considered as equal even if item.as does not refer to the default association as. In this case includes are not equal, and both of them must be pushed in options.include.

@janmeier could you review?

[verdier]

@janmeier the new logic is here, every thing else is to have self available.

[mickhansen]

Preferred having it as a non-prototype method but @janmeier will have to review and decide.

[verdier]

Ok, waiting for @janmeier then

[verdier]

Reverted @mickhansen

[verdier]

The only job of $injectScope is to inject this.$scope into options.include. It's probably better that the method was on the prototype.

[mickhansen]

$injectScope's job was to inject an arbitrary scope into an arbitrary options set was it not?
However you are right that that's all it's doing at the moment.

[verdier]

Yep, but the used scope is alway set as this.$scope and, at the end, only this.$scope is injected. That should remain like this forever, otherwise it's probably an error. Setting $injectScope as instance method without scope parameter ensure that the function is not misused.

[mickhansen]

It's true that the current use of the method is like that. However i'm sure that the intention was for it work for arbitrary scopes and options. But @janmeier will have to say since he wrote it.

[verdier]

I suspect that just was for testing purpose, but waiting for @janmeier.

[janmeier]

I guess it was for testing purposes - I agree with @verdier that if you ever try to inject other than this.$scope its probably an error

[janmeier]

Just needs a couple of changelog entries, then this should be good to go

[verdier]

@mickhansen could you add the changelog entries?

[mickhansen]

@verdier You might aswell since this needs a squash aswell, just add a notice about fixing the issue at hand here and reference the PR/issues

[verdier]

No problem, I will do that tomorrow. I was thinking that's you who keep the
change log in sync.

You want me to squash the test commits?

Le lun. 4 janv. 2016 17:54, Mick Hansen notifications@github.com a écrit :

@verdier https://github.com/Verdier You might aswell since this needs a
squash aswell, just add a notice about fixing the issue at hand here and
reference the PR/issues

—
Reply to this email directly or view it on GitHub
#5106 (comment).

[verdier]

Squashed and changelog added @mickhansen.

[mickhansen]

Thanks @verdier