Subscription not returning anything

help
1

Hey everyone,

I am refactoring my publications and am running into a lot of trouble with 2 publications:

// Publication that returns the public profile of all users
// Used in a global iron router controller
Meteor.publish("publicProfile", function() {
  return Meteor.users.find(
    {},
    {
    fields: {
      'createdAt':1,
      'profile.name': 1,
      'profile.lastName': 1,
      'profile.avatarUrl': 1,
      'profile.language': 1,
      'data.team':1,
      'roles': 1,
      "emails":1,
      'status':1,
    }
    });
});

// Publication that returns all info about a single user for the admins
Meteor.publish("singleUser", function(userId) {
  return Meteor.users.find({_id:userId});
});

// OnCreated call in the admin panel
Template.admin_long_profile.onCreated(function(){
  var self = this;
  this.autorun(function(){
    var userId = Session.get('currentProfile');
    var handler = self.subscribe("singleUser",userId);

    // Get the current user
        if (handler.ready()) {
        self.user = Meteor.users.findOne({_id:userId});
        console.log(self.user);
        }
  });
});

Now, the problem is that even though I successfully subscribe to ‘singleUser’ (according to Kadira debug) the user object only contains the fields from the publicProfile subscription. Kadira debug even tells me that one document in my user collection changed. What could be the reason for this? It seems like a standard pattern and I haven’t ever had problems with subscribing to the same collection multiple times.

2

The trouble here is about it being the Meteor.users collection, not because of multiple subscriptions to the same collection, those are indeed fine.
From my experience, though not necessarily from reading the Meteor docs, I gathered that you always have to define which fields you want to publish for the Meteor.users collection. It seems that this one is, and probably sensibly so, restricted by default. Otherwise it’d be really easy to mess up and accidentally publish all user passwords.
So just always specify the fields you want published for that particular collection and it’ll work just fine. Can’t spot anything else off in your code.

3

Just publish it to another client collection.
I dont remember exact _ option to override target collection, but google should be able to help you.

4

Sadly this doesn’t seem to work…

Could the be an issues with 2 publications running the same query, but with different options?

Meteor.publish("ownProfile", function() {
  if (this.userId) {
return Meteor.users.find({_id:this.userId}, {
    fields: {
        'data':1,
        'createdAt':1,
        'roles': 1,
        'status':1,
        'emails':1
    }
  });
} else {
  this.ready();
}

Meteor.publish("singleUser", function(userId) {
  return Meteor.users.find({_id:userId}, {
    fields: {
      "emails":1,
      "data":1,
      "profile": 1,
      "createdAt":1,
      "status":1,
      "services":1,
      "additionalInfo":1
    }
    });
});
```
5

And you are absolutely sure that nothing else is going wrong, i.e. wrong or no userId, the .ready() never firing, the record not being in the DB etc?
Also, the msavin:mongol package is often helpful for looking at what’s going on with subscriptions, i.e. what’s currently on the client.

1 Like
6

I have added console.log inside the publication and it prints out the right id. I have also printed out the “user” object from inside the handle.ready() call and it contained the correct user object without the additional fields. Everything is working sans the publication of the additional fields for the single user…

7

Well, that only tells you that the other publication is working, but potentially nothing about the one you’re trying to debug. Disable the other one, see what happens.

8

Everything looks fine with your code. Meteor does not restrict the fields published from the user collection in any way and everything you are doing should work fine. If you call Meteor.users.find() and return it from a publish function, it will publish ever user with every field. Multiple publications of the same documents also should not affect each other at the top level keys, as the merge box will take care of this. Second level keys on the document will be completely overwritten, but that doesn’t affect you in this case.

The only thing I can think of is maybe look into another package that might be affecting this.

1 Like
9

So, things are starting to get weird. I commented out the “publicProfile” subscription and used the console to manually subscribe to the “singleUser” publication. And it worked -.- Somehow the publicProfile publication overrules the single user publication…

EDIT: actually, what I have done is I navigated to the Template and called Session.set() in the console. Everything worked fine, so there is no issue with the autorun function or the publication/subscription itself. The problem only occurs when publicProfile and singleUser are used in conjunction