Currently, ``throwError`` is used for all manner of messages, including
errors, "success" messages, and "info" messages. This makes appropriate
styling of the error message difficult. In addition, the name
``throwError`` seems to create confusion, implying that an error will
actually be thrown (e.g. stopping execution when a user isn't logged in
[0][1]), when in fact it just displays a message.
Replace ``throwError`` with ``flashMessage``, and reliably include a
message "type" (e.g. "error", "success", "info") every time. rename
``lib/errors.js`` to ``lib/messages.js`` to more accurately reflect its
function.
This commit doesn't rename the message collection (``Errors``), nor the
template responsible for rendering the messages (``error_item.html``) --
that should probably still be done, but has higher likelihood of
trouble for existing alternate themes and installations.
[0] 6ccf7d7d47/client/views/users/user_edit.js (L43)
[1] 083a4c4dc4/client/views/users/user_email.js (L13)
Add the following hooks:
- ``addToUserSchema``: fields to add to the (currently unused) user
Schema
- ``postAuthor``: templates to use when rendering the post author in the
byline
- ``userProfileDisplay``: additional templates to add to the user
profile display.
- ``userProfileEdit``: additional templates to add to the user profile
editing form.
- ``userProfileFinishSignup``: additional templates to show in the view
for completing user signup (adding email, username, etc).
- ``userEditRenderedCallbacks``: Callbacks executed on "rendered" for
user_edit view.
- ``userEditClientCallbacks``: Callbacks used to further process user
properties before saving changes in user_edit view.
- ``userProfileCompleteChecks``: Functions called to determine whether
a user profile is "complete" (e.g. has email, username, and whatever
else).
These hooks facilitate package authors changing which profile fields are
displayed, which profile fields are required, and how to display
usernames next to posts.
We're using a fork with a different definition of "isAdmin" (using
``meteor-roles`` rather than the boolean user.isAdmin). ``lib/user.js``
provides abstracted methods for reading admin state, which makes it very
easy to change our definition -- except that the abstractions weren't
used universally.
This commit finishes the job of using the abstractions, and adds a few
new parts to also allow abstracting setting and updating admin-ness:
- setAdmin: sets admin status directly on a user object.
- updateAdmin: executes a mongo update to set admin status.
- adminMongoQuery: the query parameter for admin-ness, for composing
user queries with other fields.
- notAdminMongoQuery: the query parameter for not-admin-ness.
