Commit Graph

6 Commits

Author SHA1 Message Date
David Cheung ddb5327e64 Update tests for strong-error-handler
Fix rest-adapter related test case switching to strong-error-handler
Only affect the test-cases calling rest methods
2016-06-07 13:26:18 -04:00
Supasate Choochaisri 04e26fae5c Separate error-checking and next/done logic from other logic in the test suite
Signed-off-by: Supasate Choochaisri <supasate.c@gmail.com>
2016-05-05 11:12:48 +07:00
Ryan Graham 6964914bab
update copyright statements 2016-05-03 15:50:21 -07:00
Miroslav Bajtoš f9702b0ace Use eslint with loopback config
Drop jshint and jscs in favour of eslint.

Fix style violations.

While we are at this, reduce the max line length from 150 to 100.
2016-04-06 10:45:30 +02:00
Miroslav Bajtoš cf2acb3cd2 Conflict resolution and Access control
Add end-to-end unit-tests verifying enforcement of access control during
conflict resolution.

Implement two facade methods providing REST API for Change methods used
by conflict resolution:

    PersistedModel.findLastChange
    GET /api/{model.pluralName}/{id}/changes/last

    PersistedModel.updateLastChange
    PUT /api/{model.pluralName}/{id}/changes/last

By providing these two methods on PersistedModel, replication users
don't have to expose the Change model via the REST API. What's even
more important, these two methods use the same set of ACL rules
as other (regular) PersistedModel methods.

Rework `Conflict.prototype.changes()` and `Conflict.prototype.resolve()`
to use these new facade methods.

Implement a new method `Conflict.prototype.swapParties()` that provides
better API for the situation when a conflict detected in Remote->Local
replication should be resolved locally (i.e. in the replication target).
2015-04-14 08:23:24 +02:00
Miroslav Bajtoš 9c5fe088e3 AccessControl for change replication
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.
2015-04-07 19:53:58 +02:00