I would like to set a default user status, notActive, to all newly created user accounts. This status shouldn’t affect a users ability to login into their account, it will be used by administrators to control what the user can do once they have loggedin.
Is there a better way to manage this and if not how could I add it to the onCreateUser function, shown below.
I am currently using alanning/meteor-roles and I have three types of users; teachers, students, admin.
Thanks for your help.
Meteor.startup(function () {
console.log('Running server startup code...');
Accounts.onCreateUser(function (options, user) {
if (options.profile && options.profile.roles) {
//include the user profile
Roles.setRolesOnUserObj(user, options.profile.roles);
}
if (options.profile) {
// include the user profile
user.profile = options.profile
}
// other user object changes...
// ...
return user;
});
});
So I figured out the problem, I forgot to publish the new field so I couldn’t see it. A noob mistake. Here is the solution.
Meteor.startup(function () {
console.log('Running server startup code...');
Accounts.onCreateUser(function (options, user) {
if (options.profile && options.profile.roles) {
//include the user profile
Roles.setRolesOnUserObj(user, options.profile.roles);
}
if (options.profile) {
// include the user profile
user.profile = options.profile
}
// other user object changes...
user.accountStatus = "notActive";
return user;
});
});
Path: publish.js
Meteor.publish('allUsers', function (group) {
if (Roles.userIsInRole(this.userId, ['superuser'], group)) {
return Meteor.users.find({});
} else {
// user not authorized. do not publish secrets
this.stop();
return;
}
});
You might find these two sections of the guide useful:
Don’t use user.profile. It’s technically still a system field so you defo shouldn’t be overwriting it but adding to it instead. But anyway, for all the reasons mentioned in the post, it’s just bad to use it.
and
Use fields to restrict the data you publish. You already limit your publication to superusers but even then you should only send down the data they need, not everything. For security, sure, but also for performance.
Thanks for the info. I’m still learning so please correct me if I wrong. The field, user.profile, is safe to use as long as you’re not storing information about the user that you don’t want them to be able to edit, since it is, by default automatically writable. So it is fine to store things like, name and avatar. My solution, user.accountStatus = "notActive";, as far as i can tell attaches the field to user, not user.profile. So it can only be viewed / edited by the user if I give them the ability to do so.
Please correct me if I’m wrong here.
As for publishing, thanks for the heads up. I’m still trying to get my head around it. I think I will need to go back and make some changes.
The best practice is simply not to use user.profile. The fact that it is always available means it is dangerous, and therefore best left alone. It’s very simple to add your own property and build off of that or, better, just add some root level flags like isAdmin, hasDoneAThing etc.
As for learning about publications. Far and away the best thing you can do: read the guide.