Closes: CORE-1243
These are all the places that we are using in line styles that w
ould be affected in right to left. This change does absolutely nothing
to our existing left to right CSS it just flips it in right to left.
Test plan:
Because this change does not change anything for our left-to-right users
We can safely merge it without having to manually check these pages
Just likewe did With the other automated CSS changes
Change-Id: I62841f4b47925b4d9594c3ca914fa3e5d53fd7b0
Reviewed-on: https://gerrit.instructure.com/145447
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
with the new css stuff, we don't actually use
jammit so jammit_css has been renamed to css_bundle.
we left an aliased jammit_css and marked it deprecated
so these all still worked but spit out a deprecation warning.
Change-Id: Ib74037711f559f64851d9379644479587c1f83f2
Reviewed-on: https://gerrit.instructure.com/55888
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
test plan:
1. set up a new password policy via the console, e.g.
a = Account.default
a.settings[:password_policy] = {:min_length=>6, :max_sequence=>3, :max_repeats=>3, :disallow_common_passwords=>true}
a.save!
2. go to /register and sign up as a student
3. make sure the password policy is enforced, i.e.
1. confirm that the password must be at least 6 chars
2. confirm that the password cannot be a common one (e.g. football)
3. confirm that the password cannot contain a run of 4 or more chars
(e.g. abc123lol is ok, abcd1234 is not)
4. confirm that the password cannot have the same char repeated 4 or
more times (e.g. aaa000bb is ok aaaabbbb is not)
4. verify the password policy is enforced when changing your password as
an existing user (via user profile/settings)
5. verify the password policy is enforced when adding a login for a user
6. verify the password policy is enforced when resetting your password
(via forgot password on login page)
7. invite a new user into a course, and as that user verify the password
policy is enforced when you set up your account
Change-Id: Ie619fc255dc940249676bf5e510ce68eaf17441c
Reviewed-on: https://gerrit.instructure.com/19104
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jon Jensen <jon@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
in order to not have to support buttons with .ui-button AND
.button AND .btn classes this simplifies and and makes our
codebase more consistent by deprecating the .button class
with .btn
Change-Id: I4802d785a47b36aa477f302e6ac8c87715db8a62
Reviewed-on: https://gerrit.instructure.com/15194
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
fixes#5573, #5572, #5753
* communication channels are now only unique within a single user
* UserList changes
* Always resolve pseudonym#unique_ids
* Support looking up by SMS CCs
* Option to either require e-mails match an existing CC,
or e-mails that don't match a Pseudonym will always be
returned unattached (relying on better merging behavior
to not have a gazillion accounts created)
* Method to return users, creating new ones (*without* a
Pseudonym) if necessary. (can't create with a pseudonym,
since Pseudonym#unique_id is still unique, I can't have
multiple outstanding users with the same unique_id)
* EnrollmentsFromUserList is mostly gutted, now using UserList's
functionality directy.
* Use UserList for adding account admins, removing the now
unused Account#add_admin => User#find_by_email/User#assert_by_email
codepath
* Update UsersController#create to not worry about duplicate
communication channels
* Remove AccountsController#add_user, and just use
UsersController#create
* Change SIS::UserImporter to send out a merge opportunity
e-mail if a conflicting CC is found (but still create the CC)
* In /profile, don't worry about conflicting CCs (the CC confirmation
process will now allow merging)
* Remove CommunicationChannelsController#try_merge and #merge
* For the non-simple case of CoursesController#enrollment_invitation
redirect to /register (CommunicationsChannelController#confirm)
* Remove CoursesController#transfer_enrollment
* Move PseudonymsController#registration_confirmation to
CommunicationChannelsController#confirm (have to be able to
register an account without a Pseudonym yet)
* Fold the old direct confirm functionality in, if there are
no available merge opportunities
* Allow merging the new account with the currently logged in user
* Allow changing the Pseudonym#unique_id when registering a new
account (since there might be conflicts)
* Display a list of merge opportunities based on conflicting
communication channels
* Provide link(s) to log in as the other user,
redirecting back to the registration page after login is
complete (to complete the merge as the current user)
* Remove several assert_* methods that are no longer needed
* Update PseudonymSessionsController a bit to deal with the new
way of dealing with conflicting CCs (especially CCs from LDAP),
and to redirect back to the registration/confirmation page when
attempting to do a merge
* Expose the open_registration setting; use it to control if
inviting users to a course is able to create new users
Change-Id: If2f38818a71af656854d3bf8431ddbf5dcb84691
Reviewed-on: https://gerrit.instructure.com/6149
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
added checks to extractor for some common typos/oversights (and more line numbers)
Change-Id: I7a2b080cf2a26cb6711539220fe2486a1a4f04b5
Reviewed-on: https://gerrit.instructure.com/4581
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Ryan Shaw