Display Tasks assigned ONLY to individual user

Hello! I have a fairly basic question that I cant seem to figure out. I have built a fairly simple CRM/Task manegment application. I need managers (users with the role manager) to be able to assign tasks to individuals. Those individuals have a role of “Reporters” I need every reporter to ONLY be able to see tasks assigned to their user ID (via a hidden autoform field) but Managers and admins to be able to see ALL tasks.

what is the best way to approach this? Does anyone have an example? I also have a code example with more details here: http://stackoverflow.com/questions/41064485/meteor-display-tasks-only-assigned-to-current-user

If you think it’s worth the infrastructure, this roles package can help you manage permissions via roles. Then in your pub/sub you can basically say “if this user isn’t in the manager/admin role, then only publish tasks assigned to this userId”.

Thanks! Yes I am using the roles package now. I have already added the rules for role viewing. I guess the part that is tripping me up is two-fold. In my Schema I am returning the label and value like this:

	label: c.profile.firstName + " " + c.profile.lastName,
	value: c.profile.firstName + " " + c.profile.lastName,

My issue is that I need the value to be the actual persons name that prints to the list.

My second issue is that how would the actual syntax look for what you are reffering too? Would if be something like:

{{#if isInRole 'administrator, manager' }}
//show all list items
{{else //? not sure how this would look}}
///this is the part I am stuck on

Hope that makes sense…I am a little new to Blaze and still sorting this part of it out.

I had thought of using this: https://atmospherejs.com/raix/handlebar-helpers
I could use an additional form field to grab the userID as a value, but I would somehow have to make that make sense in the form…dont think there is any good way to do that…kinda sucks…

Okay, so reading through your SO post, you definitely shouldn’t be publishing all the data. Also, your label looks good, but your value should be the userId. Then your publish should look like:

Meteor.publish('tasks', function () {

  // If the user is in one of the privileged roles, we can send them the whole set of objects
  if (Roles.userIsInRole(this.userId, ['manager','admin'])) {
    return Tasks.find();

  // Otherwise, we scope the returned objects to those where the inspector matches this user's id
  } else {
    return Tasks.find({ inspector: this.userId });

Let me know if that helps?

1 Like

That helps a part of it BIGTIME! But what I still dont understand it if the Value is the UserId then how will I get the user firstName + lastName to print to the page? That is sort of my catch 22…unless I am missing something.

That is kind of up to you and how you want to handle redundancy in your database. Besides the assignment form, where else do you need the name to print?

Basically the two main options:

Store the first and last name of the user on the task as well. So you’d have something like inspectorId, which is the userId, and inspectorName, which would be the concatenated string of first name last name.

However, you have to keep your information updated then, as this is mongo. For example, if a user update his/her profile, then your data would no longer match. When a user updated his/her first name, for example, you’d have to use something like a collection hook to comb through your tasks collection and look at the inspectorId, match that userId, then update the inspectorName.

This is actually not as complicated as it sounds.


Use a helper/function to retrieve the data based on the inspectorId. This requires that the user data be available, which implies a subscription that may be overkill for what you are trying to do.

hmmm ok the users actual first + Last name is being printed to each task in a separate route/template. The idea is that the manager adds the task and assigns it to an inspector.

Just curious but would there be a way to pass the userId from the existing user select into a hidden form field? That feels like it would be the perfect approach…although I do see what your getting at with the user updating their info. I would love to see an example of how this would look…sorry still a little new to Mongo in general.

I guess I don’t understand what you’re trying to accomplish with the hidden input? In general, I think you’ll find that many inputs will have a structure like:

  <option value="{{_id}}">{{name}}</option>

You will pretty much always want to store the _id of the doc you are referencing. Then you need to decide if you want to reference that _id and look up the related data, or store that data redundantly and update it when the original doc is updated.

Yeah, I think I wasnt fully understanding where you were going with that, but I do now! Ok I will tinker some more, but your publish suggestion pretty much solves my issue!

1 Like