This reverts commit 7e519e11b7.
This commit added a test that upgraded from srp to bcrypt via
changePassword for a user with only an email address, in addition to the
test that existed for a user with a username. Having two such tests is
now silly because Meteor.changePassword no longer has different code
paths for email/username users.
DomRange now never removes elements except through the removeElement UI hook. If you write a hook that prevents removal, teardown still happens (e.g. templates stop updating).
This code also provides the basis for stopping updates to part of the DOM by triggering teardown without removal.
Before, DomBackend.removeElement would both trigger teardown and actually deparent the element. Now we have DomBackend.tearDownElement, which just triggers the jQuery teardown (which in turn triggers finalization of DomRanges that have been inserted in the DOM tree).
The flag to {node,members,range}Removed is now named “alreadyTornDown” and documented. Its purpose is to prevent redundant teardown walks through the DOM.
Previously we were using the current component to retrieve the template
instance, but what we actually want is the template instance of the
surrounding component that is a template.
This method returns the parent data context which surrounds the
helper call. This mirrors the effect of {{..}} in Spacebars. So
UI._parentData(2) is equivalent to {{../..}}.
This is for backwards compatibility with old standalone DDP clients
(like the Meteor command line tool). Note that we are not maintaining
back-compat with old standalone DDP clients that implemented SRP.
'password' can always be either a string or an object (indicating that
it's been hashed already with something). When the server receives a
string, it hashes it with SHA256 before bcrypt.
On Blaze, we copied functionality we had on Spark: Don't update
form controls (INPUT, TEXTAREA) if they are focused and their underlying
value reactively updates. This was never meant to be the eventual
solution -- we'd eventually have a way to define strategies for two-way
data binding. Maybe you'd be able to define a callback that notifies
the app when a change happens to a field that hasn't been saved yet.
Moreover, not only is the feature incomplete, but with Blaze it works
much more poorly than in Spark. Due to fine-grained updates, users
his this more frequently and don't seem to like the behavior
(in Spark you would only hit this behavior if you set up your
preserve rules exactly right, which many users did not do).
So, we're just ripping out this functionality. Now if a field gets
edited by some other user while you're focused it will just lose its
value. Focus will remain.
Fixes#1965
