Open haraldronge opened 8 years ago
Just guessing, but since collection hooks simply wraps the mutator methods, instanceof won't work when comparing against Mongo.Collection. I've not used ongoworks:security but it sounds like it's doing its job, but it's not making an exception for collection-hooks (for which I don't blame them really). Either the security package needs to make an exception for collection-hooks or someone let me know what to change to avoid this error (I'm guessing mongol has a technique for this). Pull request welcome
I had the same problem and made it work (in development, at least) by manually adding collection-hooks before ongoworks:security. It seems that the order in which these are installed/loaded makes a difference.
Thanks.
Good to hear that it can work.
I seem to remember we tried changing the order, but I will try
again.
Instead I cloned the package, installed it manually and added an
exception.
Alas, does not work for me. Changing the order makes no difference. I'll stay with my previous solution.
I can try to take a look at this error and see if I can replicate/fix it. We also have no issue when we use ongoworks:security with collection-hooks but I would be glad to add an exception for collection-hooks.
Can you confirm that this is still happening after 0.9? I think the changes in that version could have fixed that.
When uninstalling either ongoworks:security or meteor-collection-hooks problem is solved and server starts up. Funnily enough with msavin:mongol (unrelated!) installed the conflict goes unnoticed! Only once you deploy to production (mongol being debugonly) the conflict surfaces.
W20160312-16:23:21.509(1)? (STDERR) Error: The collections argument must be a Mongo.Collection instance or an array of them W20160312-16:23:21.510(1)? (STDERR) at packages/ongoworks_security/lib/server/security-api.js:67:1