Add a new model-level setting "replicationChunkSize" which allows
users to configure change replication algorithm to issue several
smaller requests to fetch changes and upload updates.
Fix `Role.isOwner()` to check both principalId and principalType.
This fixes a bug where users from different User model were treated
as owners as long as their user id was the same as owner's id.
Allow LoopBack applications to configure multiple User models and share
the same AccessToken model.
To enable this feature:
1) In your custom AccessToken model:
- add a new property "principalType" of type "string".
- configure the relation "belongsTo user" as polymorphic,
using "principalType" as the discriminator
2) In your User models:
- Configure the "hasMany accessTokens" relation as polymorphic,
using "principalType" as the discriminator
When creating custom Role and Principal instances, set your
User model's name as the value of "prinicipalType".
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.
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.
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
In strong-remoting 3.x, we have stricken the coercion of inputs
methods that are expecting an Object will nolonger accept an array
as input, to preserve backwards compatibility we have added flag
allowArray in remote arguments, which would accept an array of objects
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.
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.
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
*Re-mapping `updateAttributes` endpoint to use
`PATCH` and `PUT`(configurable) verb
*Exposing `replaceById` and `replaceOrCreate` via
`POST` and `PUT`(configurable) verb
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.
Fix `getIdFromWhereByModelId()` to correctly detect the situation
when "bulkUpdate" performs a write operation using a where filter
containing both id attribute but also all other model attributes.
This should significantly improve the performance of change replication,
because the cost of running rectifyAll is very high.
Improve the id-detection algorithm in the "after save" hook
to correctly handle "updateAttributes" as a single-model change
and DO NOT trigger full "rectify all" scan.
The decision which Promise implementation to use should be made by
LoopBack user, not by the framework.
This commit moves Bluebird reference from lib/utils.js to
test/support.js.
kobaska
Raymond Camden
ebarault
Miroslav Bajtoš
Miroslav Bajtoš
lschricke
Amir Jafarian
David Cheung
Candy
David Cheung
Loay
Kogulan Baskaran
Tim van der Staaij
Richard Pringle
gunjpan
Sonali Samantaray
Subramanian Krishnan
Samuel Reed
Rand McKinney
Ryan Graham
Simon Ho
Supasate Choochaisri
Tim Needham
Jue Hou
sghung@ca.ibm.com
Simon Ho
Sam Roberts
Chris Coggburn
Amir Jafarian
Rand McKinney
Miroslav Bajtoš
linguofeng
Miroslav Bajtoš
Richard Walker
Samuel Gaus
Christoph
Pradnya Baviskar
Raymond Feng
Ritchie Martori