| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |/ |
|
|/
|
|
| |
with invitation
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Only invited user can register in strict mode,
Set mail server in admin panel,
Switch strict mode in admin panel,
Invite people to system in admin panel
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one is a pretty strange chain of events:
* fetching /.sandstorm-login via accounts-sandstorm's rendezvous protocol
causes a user to be created in the users collection
* models/users.js has hooks to create a board and lists when a user is created
* models/activities.js has a hook to create activity entries when a list is
created
* this hook does not handle not having no boardId, which results in attempting
to run the hook with boardId: 'false'. 'false' does not have a title
attribute, which causes the whole method call to throw an exception.
* This makes the initial login fail.
While there may be other bugs, the simple fix is to not create the board and
lists when running under Sandstorm, where you only have one board anyway.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot rely on the automatic userId setting of the collection hooks.
If a user is created during invitation, the userId field will contain
the id of the inviting user.
This fix this, by mocking the CollectionHooks.getUserId function and
returning the userId of the new user for all new documents after
creating the user.
|
| |
| |
| |
| |
| |
| | |
The duplicated logic was nessessary because the before.insert hook was
not called before validation, when inserting was initiated on the server.
Using autoValues fixed this problem.
|
| |
| |
| |
| | |
Replace before.insert hook with SimpleSchema and autoValue.
|
|/
|
|
| |
The name of the profile field was changed log ago. This fixes the
remaining wrong references.
|
|
|
|
| |
The ES5 reduce method also needs a initial value. This bug was
introduced in aa974aa54ab6e5b7db7450206d12b44ffb3a0306.
|
| |
|
| |
|
|
|
|
|
|
| |
Meteor support that use case for us, we don't need to implement our
own validate strategy on top of that. This was also discussed as part
of the #454 review.
|
|
|
|
|
|
|
|
|
|
| |
The bug comes for 9154b06 which this commit partially reverts. The
synchronization between the user document profile and the Sandstorm
HTTP headers is still not perfect. Having a clean model may requires
the `accounts-sandstorm` to expose a hook to modify the user document
just after the `services.sandstorm` credentials are updated.
Fixes #460
|
|
|
|
|
|
|
| |
As discussed in #370 and announced in the official Eslint-meteor
plugin repository (https://github.com/dferber90/eslint-plugin-meteor),
it is recommended to not use this plugin anymore has the author has it
is currently broken and the author has abandoned it.
|
| |
|
|
|
|
| |
to quit
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add rules for eslint-plugin-meteor.
Use local version of eslint and eslint-plugin-meteor, instead of
relying on global versions. Ensures consistent versions of eslint and
eslint-plugin-meteor for all developers.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 07cc454 (ie the switch to Meteor 1.2) we includes the `es5-shim`
polyfill to support methods like `Array.prototype.forEach` in a
consistent way across all supported browsers (IE8+).
MDG recently released a blog post recommending the use of these native
methods instead of underscore [0]. We know follow this recommendation.
This commit also favor some ES6 features (argument defaults,
destructing assignment) in places where we didn’t use them.
[0]: http://info.meteor.com/blog/es2015-get-started
|
|
|
|
|
| |
We now delegates more user attributes sync (avatar and permissions) to
this package instead of doing it ourselves.
|
|
This commit uses a new package that I need to document. It tries to
solve the long-standing debate in the Meteor community about
allow/deny rules versus methods (RPC).
This approach gives us both the centralized security rules of
allow/deny and the white-list of allowed mutations similarly to Meteor
methods. The idea to have static mutation descriptions is also
inspired by Facebook's Relay/GraphQL.
This will allow the development of a REST API using the high-level
methods instead of the MongoDB queries to do the mapping between the
HTTP requests and our collections.
|