Please clarify “can’t” in this context. Remember that offices aren’t published to the client unless you subscribe to it (or use the autopublish package).
My mistake, autopublish does only publish "username, profile, and any fields in services" from the users collection, so you need to use the publish/subscribe procedure.
A user document can contain any data you want to store about a user. Meteor treats the following fields specially:
[…]
profile: an Object which the user can create and update with any data. Do not store anything on profile that you wouldn’t want the user to edit unless you have a deny rule on the Meteor.users collection.
[…]
It does not encourage you to only use the profile field.
@Peppe_LG: At the same time, wouldn’t you agree that for the “rapid prototyping” use case, this is a true statement? While autopublish is a part of the the application, it doesn’t make sense to modify any other field because then you have to write a custom publish. And when you are outside of the “rapid prototyping” stage and writing a publish statement, would you rather publish just the username, profile, and services, or would you rather whitelist every field you need and then rewrite all of your code that accesses those fields?
You are correct in stating that the documentation says nothing about which fields to modify. Therefore, I modify my previous statement to be, “IMHO, the profile field is the only one you should modify for a meteor user”
@jchristman, I mostly agree with what you’re saying. While prototyping, do whatever you want (the quicker the better), but for a real application, I do see use cases for adding new fields instead of extending the profile field. For example, you may want to store information about the user the user should’t be able to see.
@Steve, I don’t see the harm in storing private user information in it, such as theme settings, desired number of items/page, etcetera. If a hacker changes these, it only falls back on himself.
Sure, he can try to bring down your app by successfully writing big amount of useless data in the profile field, but if he’s out to get you, that seems like a pretty poor attempt.
@Peppe_LG: there is no harm in using profile. What is annoying is that it is a special case, an exception in the overall Meteor picture. So I think it is best to advise newcomers to not using it (until it is removed from Meteor).
I think this is exactly how you decide whether or not to store your additional information in profile. If you want it on the client, why wouldn’t you put it on profile?