Loopback: Properties won't override while extending from User model.

[peek4y]

I'm trying to extend from User model.

 "properties": {
      "id": {
      "type": "string",
      "id": true,
      "required": true,
      "defaultFn": "uuid"
    },
    "email": {
        "type": "email",
        "required": false
     },
    "countryId": {
      "type": "string",
      "required": true
    }
 }

So, email required false, does not make any change at all, I still get validation error saying email is null.

Any idea how to override properties?

[richardpringle]

@peek4y, it's not that the property isn't overridden, it's that any sub class of the User class still performs validation on email regardless. Is there any particular reason you don't want to include email?

It might almost be easier to build your own "user" model rather than extend the existing one. For now, I will throw a feature label on this issue.

Sorry I couldn't be more helpful!

[peek4y]

Ok thanks for the explanation.

Well, all i need is mobile number for validation sometimes and I really dont need the email.

[richardpringle]

@peek4y, go down to the verify email section on this page to see how to turn email verification off. It's a part of the options parameter of your user model in the model-config.json config file.

[peek4y]

So, this should skip email validation during sign up right?

Sorry, din't get time to try it out.

[richardpringle]

Yeah it should. I actually haven't had time to try it out either to be honest... Let me know how it goes

[peek4y]

Nope, it doesn't work :cry:

"message": "Theuserinstance is not valid. Details:emailcan't be blank (value: undefined);emailis null (value: undefined)."

[richardpringle]

Definitely a bug then, I'll take a look

[peek4y]

:+1: Thanks!

[richardpringle]

@peek4y, sorry that was silly of me. That is for _verifying_ not _VALIDATING_**. The built-in User model actually depends on email for some of its functionality so it doesn't really make sense to be able to remove it.

Instead, you can take a look at the User model code and copy some of its functionality for your own model.
https://github.com/strongloop/loopback/blob/master/common/models/user.js
https://github.com/strongloop/loopback/blob/master/common/models/user.json

[peek4y]

Hmm, that doesn't sound right to me. I was wondering if there could be a simpler way to solve this.

[richardpringle]

I mean a workaround would be to insert a dummy email but currently, we do not support extending the user model without an email at all. I have left a feature tag on this issue so that we could potentially disable the email validation, but realistically, this isn't in high demand (not to say that is wouldn't be useful in certain cases).

In your case, you could extend or use the built-in user model and get your user to provide their email upon registration. From there, you do not need to use an email address to login.

[peek4y]

Got it :+1: will go with a workaround. Hoping to see this feature soon :smile:

[Emiya0306]

@richardpringle @peek4y I think it is a good feature that can select special fields to do login. Make it more flexible and more powerful! 👍

[ataft]

Reading through the various Google groups, gitter posts, loopback issues (e.g. #1137), this post, and more, it does seem that there is fairly high demand to make email optional. Thus, removing required from the built-in User model and not doing validation if it's not used.

Any shot of getting this issue resolved in an upcoming release?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ataft]

Ms. Stalebot, this thread and the corresponding "User model without email or username" #1137 thread have a ton of +1's and thumbs up, so clearly indicate that this is a desired item by the community.

[richardpringle]

@ataft, I'm not actually working on LoopBack anymore buuuuut, it's my guess that if this issue hasn't received any love thus far, it probably won't receive any anytime soon. The best you could hope for is better User extensibility in LoopBack 4.

In the meantime, I strongly suggest creating a PR! I mentioned what files would need to be changed above.

The simplest thing you could do is write a single test where you create a user without an email address... then write some code to make it pass! I'm sure the LoopBack team can/will help you along the way.

As for the stalebot, I think it's just a poke to see if anyone still cares to make the issue backlog a little more manageable. As you can see, the stale label was removed as soon as you commented.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

[Vandivier]

Does stalebot reopen? Is the Loopback 3 team open to a pull request on this issue?

[richardpringle]

@kjdelisle ^

@Vandivier, I'm sure the LoopBack team is always open to pull requests!

[richardpringle]

FYI, I'm no longer on the LB team... just thought I would make that clear

[ali1tokan]

in case of we made a model like user on our own can we use the access token built in... and if so do we have to persist it to the data source for example mysql like that model we made.... or keep it in the memory..

[kjdelisle]

Pull requests welcome!

Though, I would say that you'd probably be better off suggesting this as a part of the next major version of loopback: https://github.com/strongloop/loopback-next

We're looking for more community contributors, and since we're still in alpha, there's plenty of room for change!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.