v2.12 New 'collection' option for Accounts does not permit the name 'users' for a remote collection

[paulincai]

server.js

import { UsersDB } from '../../api/collections/users/server/users'

Meteor.startup(() => {
  Accounts.config({
    loginExpirationInDays: process.env.LOGIN_EXPIRATION_IN_DAYS || 30,
    sendVerificationEmail: false,
    collection: UsersDB
  })
})

A console.log() right above the following line:

meteor/packages/accounts-base/accounts_common.js

Line 46 in 1d6983c

this.users = this._initializeCollection(options || {});

should print my configuration options but the object is empty because the configuration was not yet applied and options are not passed. This results in the creation of a local collection 'users'.
Further down in AccountsCommon, the config(options) is being applied however, if you want to connect to a remote collection named 'users' of another Meteor instance, you can't because the other collection should not have the name 'users':

if (options.collection && options.collection !== this.users._name && options.collection !== this.users) {...}

meteor/packages/accounts-base/accounts_common.js

Line 288 in 1d6983c

if (options.collection && options.collection !== this.users._name && options.collection !== this.users) {

[paulincai]

It also seems that this happens:

1. In AccountsCommon a default collection is being initialized and this.users (Meteor.users) becomes this collection. (line 46)
2. Accounts configuration is called on startup.
3. In AccountsCommon the configuration is being applied (line 289) however, this.users (Meteor.users) remains assigned to the initial value from line 46.

Meteor.users should reflect the actual users collection while creating a local DB is not necessary.

For now I could just reinitialized Meteor.users with my new DB but that doesn't sound right:

export const UsersDB = new Meteor.Collection('otherUsers', { _driver })

Meteor.users = UsersDB
Meteor.users.attachSchema(User)

[Grubba27]

Yeah, that does not sound correct.
Thanks a lot for reporting.

[SamarthBagga]

Hi @paulincai I think I may have a probable fix for your issue. But the problem is that I am unable to replicate the issue on my local environment. The fix is to replace a line in the "accounts_common.js"-
Could you replace-

if (options.collection && options.collection !== this.users._name && options.collection !== this.users) { this.users = this._initializeCollection(options); }

with this -

if (options.collection && options.collection !== this.users._name && options.collection !== this.users) { this.users = options.collection; }

and then try to run the server and do the same thing. If this does not work or if there is some other problem could you guide me as to how I can replicate this issue?

[mcorbelli]

Any updates?

[nachocodoner]

I faced a problem customizing the Users collection name in my projects.

When you designate a different name for your users collection using options.collection, the default indexes expected for the new collection aren't created, including those from the main accounts package and others. This likely occurs because Accounts.config occurs after Accounts constructor, similar to the other issues mentioned here. To address this, configuring the custom collection name, especially for index issues, should happen at the level of settings.json config of the package. Or completely change the code flow. In my case, I had to fork the package and directly modify the code for my app to simplify and focus on my app development.

These issues need attention. Is anyone available to tackle them now? Otherwise we'll address them later when we have more capacity on the core team.