The fix introduced in previous commit was relying on the default
merge algorighm applied when a child model inherits relation config
from the parent.
This commit changes the check to use a more reliable approach
based on the relation metadata configured by the child model.
In the present implementation `verifyUserRelations(Model)` assumes that
`Model.relations.accessTokens` is always set, and as a result may
crash when trying to access `polymorphic` property of that relation.
It seems the intention is to check whether the the following conditions
are met:
1. a model has a hasMany accessTokens relation
2. that relation is polymorphic
This commit fixes the problem by accounting for the case where the
accessTokens relation was not correctly set up.
Add API allowing applications to hide a Model from the
REST API and remove all references to it, allowing Garbage Collector
to claim all memory used by the model.
Fix the code resolving OWNER role to correctly handle the situation
where the target model has multiple "belongsTo" relations to the User
model.
Introduce a new model setting "ownerRelations" that enables the new
behavior. When "ownerRelations" is set to true, then all "belongsTo"
relations are considered as granting ownership. Alternatively,
"ownerRelations" can be set to an array of the relations which
are granting ownership.
For example, a document can "belongTo" an author and a reviewer,
but only the author is an owner, the reviewer is not. In this case,
"ownerRelations" should be set to "['author']".
Emit a new method "remoteMethodAdded" whenever a new method is added,
typically when `Model.remoteMethod` or `Model.nestRemoting` is called.
The method is emitted both by the Model affected and the application
object.
Modify `app.enableAuth()` to verify that (custom) User and AccessToken
models have correctly configured their hasMany/belongsTo relations
and print a warning otherwise.
In strict mode, creating properties on strings is not allowed.
As a result, creating a new datasource fails with the following
error:
TypeError: Cannot create data source "db":
Cannot create property 'name' on string 'mongodb'
In this commit, we fix the code to assign the connector name only
if the connector is an object (not a string).
Add "returnOnlyRoleNames" option to Role.getRoles
Currently the return type of Role.getRoles() method is inconsistent:
role names are returned for smart roles and role ids are returned for
static roles (configured through user-role mapping).
This commit adds a new option to Role.getRoles() allowing the caller
to request role names to be returned for all types of roles.
Notable side-effects:
- loopback no longer exports "caller" and "arguments" properties
- kv-memory connector is now properly added to the connector registry
- the file "test/support.js" was finally removed
Fix a typo in "app.enableAuth" that caused the method to not detect
the situation when e.g. the built-in User model is already attached
to a datasource.
Current implementation of `app.model(modelName, settings)`
works as a sugar for model creation. In 3.0, this is
not supported anymore. This implementation reports an
error when sugar is used for model creation.
Includes:
- Updated app.model() method
- Fixed test cases reflecting the change
Modify `app.enableAuth` to automaticaly setup all required models
that are not attached to the app nor a datasource.
Users wishing to use this option must provide the name of the
data-source to use for these models.
Example usage:
var app = loopback();
app.dataSource('db', { connector: 'memory' });
app.enableAuth({ dataSource: 'db' });
app.use(loopback.rest());
app.listen(3000);
Process `settings.methods` and `config.methods` as a key-value map
where the key is the method name and the value is an object describing
the method in the format expected by strong-remoting.
Example: a static method `Model.create`
"methods": {
"create": {
"isStatic": true,
"accepts": {
"arg": "data", "type": "Car",
"http": { "source": "body" }
},
"returns": { "arg": "data", "type": "Car", "root": true }
}
}
This patch is based on the code proposed by @mrfelton in #1163.
- `loopback.registry` is now a true global registry
- `app.registry` is unique per app object
- `Model.registry` is set when a Model is created using any registry method
- `loopback.localRegistry` and `loopback({localRegistry: true})` when set to `true` this will create a `Registry` per `Application`. It defaults to `false`.
Express has recently deprecated `req.param()` to force developers
to be explicit about the source of the value. To avoid deprecation
warnings, this commit replaces all calls of `req.param()` with a
simplified inline version.
Enhance the error objects with a `code` property containing
a machine-readable string code describing the error, for example
INVALID_TOKEN or USER_NOT_FOUND.
Also improve 404 error messages to include the model name.
Allow the developer to pass custom `remoting` options via Model
settings, e.g.
PersistedModel.extend(
'MyModel',
{ name: String },
{
remoting: { normalizeHttpPath: true }
});
Also add `options` arg to `app.handler`, this object is passed directly
to strong-remoting handler.
When running on Unix and no hostname is specified, use `0.0.0.0`
as the hostname instead of `localhost`.
When running on Windows and the hostname is either not specified or
it is `0.0.0.0` or `::`, use `localhost` in the URL. The reason is
that Windows cannot open URLs using `0.0.0.0` as a hostname.
Nora
Miroslav Bajtoš
Mohammed Essehemy
virkt25
mcitdev
ryanxwelch
Kevin Scroggins
Justin Ross
pierreclr
Zak Barbuto
Daijiro Wachi
Flavien DAVID
Miroslav Bajtoš
ebarault
Loay
Candy
gunjpan
Subramanian Krishnan
Ryan Graham
Simon Ho
Supasate Choochaisri
Sam Roberts
Rand McKinney
Simon Ho
Miroslav Bajtoš
Ritchie Martori
Ron Edgecomb
Ryan Graham
Rob Halff
Fabien Franzen