Since I’ve removed autopublish, I cannot seem to access the entire users collection (my publication only returns the document of the currently logged in user). As far as I can tell it should be as simple as:
Any ideas as to how I can return all users? I have scoured the official documentation / SO to no avail. To be clear, I have no problem with the default fields returned.
Also, I know that it is not considered best practices or whatever to use the Meteor.users collection for storing user data – so what options do I really have for an autopublish-free Meteor app that needs public user profiles? All I can think of is create another collection whose documents have a one-to-one correspondence with the Meteor.users collection but I have no idea how to functionally implement this…
I think you will need to put up a repo for us to look into in order to better help out. Maybe you can create a super simple version on github on this issue, then you might find out answer along the way.
Why is it not a best practices putting properties in users collection? I assume the discussion is not putting data that is suppose to be ‘private’ (non editable by user) into ‘profile’ property, since it will get published by default. You still can add more props if you need to. That is what I know of.
Yeah I have no problem posting a repo to github if it comes to that, I just feel that in a way it’s not actually that complex (it seems that this behavior worked in earlier Meteor versions so I’m wondering if it’s a post 1.3 thing).
Regarding not storing things on the Meteor.users collection, I could just set allow/deny rules for any field so I don’t really see why people think it’s such an awful practice. That said, I do think that there is a benefit in creating a different mongo collection for Profiles (or whatever I end up calling it) since it also seems virtually impossible to trigger a .ready() method (and therefore render loading divs while waiting on data) on the Meteor.users collection.
Users = new Mongo.Collection('userdata')
var robert = Meteor.users.findOne({name: "robert"});
var robertsProfile = {
housesRobbed: 100,
carsStolen: 3
}
Users.upsert({_id: robert._id}, {$set:robertsProfile}});
//later in some method on the server
//this method is called when robert robs a house.
Users.update(this.userId, {$inc:{housesRobbed:1}})
//this.userId already refers to the logged in user!
Regarding the bug you mentioned, the answer above seems correct
You can store user data in Meteor.users. The problem is using the profile field within a user because profile is default writeable. This can be fixed with a simple Meteor.deny call.
I’m not quite sure what was happening, I think it was that my publications.js file was somehow not properly linked to the server, although I checked about a million times. I ended up just creating a new project and it worked pretty much without a hitch, even though it killed me to do that. @tathagatbanerjee sounds like the same deal as you.
Thank you very much to everyone for your help and suggestions, @kenken you saved my life with your mini wtf app (I appreciated the name) and @streemo I ended up (w/in my new app) creating a separate collection and your upsert trick was clutch for copying the id.