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.
The option injectOptionsFromRemoteContext was added to LoopBack 2.x only
and is not available in LoopBack 3.x (and newer).
When a model with this option is encountered, we are printing a warning
message now, to let the user know about this change between 2.x and 3.x.
Define a new Model method "createOptionsFromRemotingContext" that allows
models to define what "options" should be passed to methods invoked
via strong-remoting (e.g. REST).
Define a new http mapping `http: 'optionsFromRequest'` that invokes
`Model.createOptionsFromRemotingContext` to build the value from
remoting context.
This should provide enough infrastructure for components and
applications to implement their own ways of building the "options"
object.
this is needed because we added allowArray flag to persisted model's
remoteMethod, but when relations try to rebuild such methods, it does
not carry over such flags
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 the definition of "data" argument to
{ type: 'object', model: modelName, ... }
That way strong-remoting passed the request body directly to the model
method (does not create a new model instance), but the swagger will
still provide correct schema for these arguments.
This fixes a bug where upsert in relation methods was adding default
property values to request payload.
Prevent apps from crashing when using `Model.nestRemoting` without
`{ hooks: false }` option.
Note that it is not possible to reproduce this bug using our current
Mocha test suite, because other tests modify the global state in such
way that the bug no longer occurs.
This patch fixes the method Model.getApp() that started to report
the following error after b61fae5 was landed:
assert.js:88
throw new assert.AssertionError({
^
AssertionError: undefined == true
at loopback/loopback/lib/model.js:392:7
at EventEmitter.<anonymous> (loopback/loopback/lib/model.js:222:9)
at EventEmitter.g (events.js:257:16)
at emitOne (events.js:77:13)
at EventEmitter.emit (events.js:166:7)
at EventEmitter.app.model (loopback/loopback/lib/application.js:157:9)
1) Add integration tests running change replication over REST to verify
that access control at model level is correctly enforced.
2) Implement a new access type "REPLICATE" that allows principals
to create new checkpoints, even though they don't have full WRITE
access to the model. Together with the "READ" permission, these
two types allow principals to replicate (pull) changes from the server.
Note that anybody having "WRITE" access type is automatically
granted "REPLICATE" type too.
3) Add a new model option "enableRemoteReplication" that exposes
replication methods via strong remoting, but does not configure
change rectification. This option should be used the clients
when setting up Remote models attached to the server via the remoting
connector.
- `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`.
Modify the files to export a model factory function accepting
a `registry` argument. This is a preparation step for per-application
models - see #1212.
Jürg Lehni
Raymond Feng
Rashmi Hunt
Farid Nouri Neshat
Candy
Piero Maltese
Flavien DAVID
Miroslav Bajtoš
David Cheung
David Cheung
Loay
Tim van der Staaij
Richard Pringle
Amirali Jafarian
Sonali Samantaray
Ryan Graham
Supasate Choochaisri
Tim Needham
Rand McKinney
Ritchie Martori
Miroslav Bajtoš
Edmond Lau
Miroslav Bajtoš