| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
We use this field to prevent adding attachments' related activities automatically only. Then this field will be removed.
|
| |
|
| |
|
|
|
|
|
|
| |
New site url
New contact email
New year!
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
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.
|