Changing the 'status' default property name

i've just tried a nice package called "meteor-user-status"

from https://github.com/mizzao/meteor-user-status

and i have some problem with the default 'status' property

can i change the default 'status' property name??

"status" : {
    "online" : false,
    "lastLogin" : {
        "date" : ISODate("2018-07-19T16:26:02.326+07:00"),
        "ipAddr" : "127.0.0.1",
        "userAgent" : "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
    }
}

coz it replaced when I made a user seeder.. Like this :

if (Meteor.users.find().count() === 0) {
 var i = 0;
 for (i = 0; i<users.length ; i++) {
  Accounts.createUser({
    username: users[i].username,
    email: users[i].emails[0].address,
    password: 'secret',
    profile : users[i].profile
  });

  Meteor.users.update({ "emails.0.verified": false }, {
    $set: {"emails.0.verified" :true, status: 'a', roles: users[i].roles}
  });
}

}

because, my 'status: a' is to make the users can login to the app

thanks a lot

In order to your response that you are not really able to refactor your field there are still some options left for you.

Other packages

There are other status packages that deal with user status. Maybe they use a different approach of storing the information than using status on a user.

See https://atmospherejs.com/?q=user-presence

Refactoring partially

This would be a merge of both structures. The package you use saves an object on the status.

Thus a refactor could be from

status: 'a' to status: { a: true } wherea` would not clash with the other fields of status as long as it has a name different from all other status fields.

Maybe you can convince your architect to consider this option.

Fork and customize the package

You could fork the package and make a local copy of it. If your local package version is higher than the version on atmosphere, meteor will use the local one in favor when no version is specified.

In your local package you can now use a different field name than status.

And if you find a way to customize the field name while keeping it backwards compatible you could even create a pull request an GitHub and thus improve the package so others won't get into the same trouble.