Model configuration `schema` is not taken into account by the populate() query.

[benoitbzl]

Hello, I set my model config file with schema: false to prevent attributes filtering of the documents retrieved from mongo DB (for different reasons, the models in sails are not always defining all attributes of a document). But the join document retrieved by a populate() query does not follow that schema: false configuration, and the attributes of the joined document are filtered according to the model.

For example, in database there are the two documents in different collections:

collection user: { _id: "a user ID", tenant: "a tenant ID", theme: "a theme ID" } with a sails model like (this is not a real sails model but just an illustration): { id: { type: "string" }, tenant: { model: "Tenant" } }

collection tenant: { _id: "a tenant ID", lang: "fr", configuration: "A configuration" } with a sails model like (this is not a real sails model but just an illustration): { id: { type: "string" }, configuration: {type: "string"}}

a query like: sails.models.user.findOne({ id: "a user ID" }).populate('tenant') returns a user document like: { id: "a user ID", theme: "a theme ID", tenant: { id: "a tenant ID", configuration: "A configuration" }}

The lang attribute of the tenant has been filtered out as it is not defined by the tenant model, but the theme attribute of the user has been preserved as expected.

Node version: 14.18.3 Sails version (sails): 1.5.2 ORM hook version (sails-hook-orm): Sockets hook version (sails-hook-sockets): Organics hook version (sails-hook-organics): Grunt hook version (sails-hook-grunt): Uploads hook version (sails-hook-uploads): DB adapter & version (e.g. sails-mysql@5.55.5): sails-mongo Skipper adapter & version (e.g. skipper-s3@5.55.5):

---

[sailsbot]

@benoitbzl Thanks for posting! We'll take a look as soon as possible.

In the mean time, there are a few ways you can help speed things along:

• look for a workaround. (Even if it's just temporary, sharing your solution can save someone else a lot of time and effort.)
• tell us why this issue is important to you and your team. What are you trying to accomplish? (Submissions with a little bit of human context tend to be easier to understand and faster to resolve.)
• make sure you've provided clear instructions on how to reproduce the bug from a clean install.
• double-check that you've provided all of the requested version and dependency information. (Some of this info might seem irrelevant at first, like which database adapter you're using, but we ask that you include it anyway. Oftentimes an issue is caused by a confluence of unexpected factors, and it can save everybody a ton of time to know all the details up front.)
• read the code of conduct.
• if appropriate, ask your business to sponsor your issue. (Open source is our passion, and our core maintainers volunteer many of their nights and weekends working on Sails. But you only get so many nights and weekends in life, and stuff gets done a lot faster when you can work on it during normal daylight hours.)
• let us know if you are using a 3rd party plugin; whether that's a database adapter, a non-standard view engine, or any other dependency maintained by someone other than our core team. (Besides the name of the 3rd party package, it helps to include the exact version you're using. If you're unsure, check out this list of all the core packages we maintain.)

  ---

Please remember: never post in a public forum if you believe you've found a genuine security vulnerability. Instead, disclose it responsibly.

For help with questions about Sails, click here.

[eashaw]

@benoitbzl This is the intended behavior today https://github.com/balderdashy/waterline/blob/98e4b7cf2f16611c56a2542ddb2b92a56928ad94/lib/waterline/utils/query/process-all-records.js#L131-L149

Have you seen this information in our documentation?

I discussed this with @mikermcneil and he recommends using schema: true

[benoitbzl]

Hello. For different reasons we cannot use the schema: true configuration in our case. We must disable the schema verification and result filtering. This works for the parent documents (attributes are not filtered), but it does not for the populated (child) documents (some attributes are filtered). If this is the intended behavior, it should be clearly stated in the documentation that the schema: true configuration does only apply to parent documents.

[eashaw]

@benoitbzl we agree that this should be documented, we'll update the documentation.