[SOLVED] The current user should not always be bound to Meteor.users

core
1

When developing a user administration tool where search and paging are performed, I am using the Meteor.publish in angular-meteor where I pass in the selector and find options (for sort and paging)

Given a publish to a subscription ‘all-user-list’ with some paging information for the simple example:

Meteor.publish('all-user-list', function (selector, options) {
  return Meteor.users.find(selector, options);
});

The subscription and query against the Meteor.users table will always have the current user. It might need some work, but I don’t think the Meteor.users and the current user really should not be tied together otherwise this issue would arise.

It could be that angular-meteor does it but I am not sure as of yet.

2

Try this package: https://atmospherejs.com/percolate/find-from-publication

This is a general fact about Meteor publications and Minimongo - all of your currently subscribed to data is pushed to the client. It’s not a specific issue about users.

2 Likes
3

By the way always think about security when publishing user data: http://guide.meteor.com/accounts.html#publish-custom-data

1 Like
4

@sashko That package was perfect. Works very well. Wish it was part of core now :smiley:

1 Like
5

We mention it a bit in the guide: http://guide.meteor.com/data-loading.html#pagination

But I agree that core should have something like this.

6

The bigger issue here is that you need to realize that you most likely still need to filter your Meteor.users collection on the client with selector and options. Publications just move documents from the “real” Mongo instance on the server into MiniMongo on the client.

If multiple publications are publishing different sets of data (for example, accounts-base is publishing Meteor.users.find(this.userId);, and your all-user-list is publishing some other set of users), you’ll need to filter your client-side queries against MiniMongo to specify exactly which documents you want, instead of just Meteor.users.find().

Hopefully that helps a bit. I’ve definitely seen my share of issues around this kind of thing…

7

That’s correct. I kind of had the feeling it was like that when I saw how the collections worked, I was hoping subscriptions would be different but alas it was what I sort of expected. Thankfully @sashko suggestion for the package solves the issue.