canvas-lms/app/models/brand_config.rb

224 lines
6.6 KiB
Ruby
Raw Normal View History

#
# Copyright (C) 2015 - present Instructure, Inc.
#
# This file is part of Canvas.
#
# Canvas is free software: you can redistribute it and/or modify it under
# the terms of the GNU Affero General Public License as published by the Free
# Software Foundation, version 3 of the License.
#
# Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
# A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
# details.
#
# You should have received a copy of the GNU Affero General Public License along
# with this program. If not, see <http://www.gnu.org/licenses/>.
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
class BrandConfig < ActiveRecord::Base
include BrandableCSS
self.primary_key = 'md5'
serialize :variables, Hash
OVERRIDE_TYPES = [:js_overrides, :css_overrides, :mobile_js_overrides, :mobile_css_overrides].freeze
ATTRS_TO_INCLUDE_IN_MD5 = ([:variables, :parent_md5] + OVERRIDE_TYPES).freeze
validates :variables, presence: true, unless: :overrides?
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
validates :md5, length: {is: 32}
before_validation :generate_md5
before_update do
raise 'BrandConfigs are a key-value mapping of config variables and an md5 digest '\
'of those variables, so they are immutable. You do not update them, you just '\
'save a new one and it will generate the new md5 for you'
end
get sub account branding and custom css/includes working fixes: CNVS-24787 fixes: CNVS-23964 fixes: CNVS-23957 - Handle parent account custom css/js for new_styles test plan: * set up a root account, child account, and grandchild account * use theme editor to set a custom css/js file for each (eg: for css `* {color:red}` and for js 'console.log("from grandchild")` * make a course & a group in the grandchild account * load a page in that course and group and make sure you see grandchild account's branding, and root's, child's, and then grandchild's css loaded on the page (grandchild should be loaded last so you see it's css effects override root or child's and you should see the console.log from root then child then grandchild) * view a page in "child". it should have root and child's css/js but not grandchild * as a user that only has enrollments (account associations) in "child", go to the dashboard. you should see css/js for both root and child but not grandchild fixes: CNVS-25051 Opening Theme Editor for sub-accounts shows incorrect theme preview test plan: * Go to a sub-account in theme editor and change settings so the Branding is different and save. * the preview on the right should reflect your changes both after you "apply" and "save" (and not just show the preview of the root account's branding) fixes: CNVS-23406 - global JS and CSS files are being included when Global CSS/JavaScript includes is false test plan: * go to /accounts/self/, and go to theme editor and upload a css_override * see that that css is loaded on pages * back in root account settings disable Global CSS/JavaScript includes * check that the css is no longer loaded. * do the same thing checking a subaccount's custom css fixes: CNVS-25558 - load whole chain of custom css/js in native app api requests test plan: * make api request for a wiki page in course in a subaccount that has custom css/js within a root account that also has custom css/js * you should see both the root account's css/js and the child account's returned in the response to test grandchild js issue jeremyp found: * go to theme editor for a grandchild account * choose a js override file (like: `console.log('first')`) * preview & apply * you should see "first" in console * go back to theme editor, pick a new file (like: `console.log('second')`) * preview & apply * you should only see "second" in console. not "first" Change-Id: I8d9047948f5da94be41e0205844629a170f980af Reviewed-on: https://gerrit.instructure.com/68249 Reviewed-by: Simon Williams <simon@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-12-05 00:57:07 +08:00
belongs_to :parent, class_name: 'BrandConfig', foreign_key: 'parent_md5'
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
has_many :accounts, foreign_key: 'brand_config_md5'
All of the stuff from the save_a_theme dev branch this commit is the result of squashing a bunch of others together. this is everything that was already on the dev/save_a_theme branch as well as the "Add specs" commit. I left the test plans from some of the squashed commits in case they are helpful for QA Test plan: - Recompile assets, restart Canvas and clear browser cache - Go to Admin > [Your school name] - Click on Themes in the context menu - You should now see a collections page with a theme card for all the themes you have in Theme Editor: http://screencast.com/t/lb5vozF7 - Note: it might be my database, but on my end, I don't see a theme card for my Canvas default theme. There are also some brand colors missing for my theme cards. I'll be interested to see if you hit the same thing. These are issues that we can resolve with Ryan when he is back. - You should be able to click on the Apply and Delete buttons and see the confirm-overlays. We still need final copy for these. Test plan: - Go to your institution's Settings page and click Themes on the context menu. - You should now see a page listing all the default and user-created themes in your Canvas installation. - Clicking on each theme will open it inside theme editor. - The current/active theme will be correctly styled with a green outline change redirect targets and messages in theme editor test plan: exiting theme editor should redirect you back to the /accounts/x/themes page instead of /acounts/x make room for footer in theme editor test plan: in theme editor, scroll the preview to the bottom you should be able to scroll all the way, without having the bottom cut off by the footer remove "theme editor" button from account user/course search this is not needed since "Themes" now shows up in the left nav. test plan: turn on the 'Course and User Search' feature flag go to accounts/x you should not see a "theme editor" button on the right aka, not like this: http://cl.ly/2G2C3p3s3n0C fix "Exit" button in theme editor we were warning "you will lose unsaved changes" even when you hand not made any changes add specs to "Save A theme" stuff closes: CNVS-27961 test plan: do a whole regression test on the theme editor don't show both "k12 theme" and "canvas default" as options fixes: CNVS-25495 description (and test plan): if you are a k12 school, rather than seeing both "Canvas Default" and "K12 Theme" as options on the tiles of system themes to start from, you should now just see "Canvas Default". if you pick that, it should show the k12 theme. Change-Id: I5c2512e576dcb2aedaa899e17080d9c106e159ca Reviewed-on: https://gerrit.instructure.com/78163 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2016-01-19 03:29:32 +08:00
has_many :shared_brand_configs, foreign_key: 'brand_config_md5'
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
def self.for(attrs)
attrs = attrs.with_indifferent_access.slice(*ATTRS_TO_INCLUDE_IN_MD5)
return default if attrs.values.all?(&:blank?)
new_config = new(attrs)
new_config.parent_md5 = attrs[:parent_md5]
existing_config = where(md5: new_config.generate_md5).first
existing_config || new_config
end
def self.default
new
end
All of the stuff from the save_a_theme dev branch this commit is the result of squashing a bunch of others together. this is everything that was already on the dev/save_a_theme branch as well as the "Add specs" commit. I left the test plans from some of the squashed commits in case they are helpful for QA Test plan: - Recompile assets, restart Canvas and clear browser cache - Go to Admin > [Your school name] - Click on Themes in the context menu - You should now see a collections page with a theme card for all the themes you have in Theme Editor: http://screencast.com/t/lb5vozF7 - Note: it might be my database, but on my end, I don't see a theme card for my Canvas default theme. There are also some brand colors missing for my theme cards. I'll be interested to see if you hit the same thing. These are issues that we can resolve with Ryan when he is back. - You should be able to click on the Apply and Delete buttons and see the confirm-overlays. We still need final copy for these. Test plan: - Go to your institution's Settings page and click Themes on the context menu. - You should now see a page listing all the default and user-created themes in your Canvas installation. - Clicking on each theme will open it inside theme editor. - The current/active theme will be correctly styled with a green outline change redirect targets and messages in theme editor test plan: exiting theme editor should redirect you back to the /accounts/x/themes page instead of /acounts/x make room for footer in theme editor test plan: in theme editor, scroll the preview to the bottom you should be able to scroll all the way, without having the bottom cut off by the footer remove "theme editor" button from account user/course search this is not needed since "Themes" now shows up in the left nav. test plan: turn on the 'Course and User Search' feature flag go to accounts/x you should not see a "theme editor" button on the right aka, not like this: http://cl.ly/2G2C3p3s3n0C fix "Exit" button in theme editor we were warning "you will lose unsaved changes" even when you hand not made any changes add specs to "Save A theme" stuff closes: CNVS-27961 test plan: do a whole regression test on the theme editor don't show both "k12 theme" and "canvas default" as options fixes: CNVS-25495 description (and test plan): if you are a k12 school, rather than seeing both "Canvas Default" and "K12 Theme" as options on the tiles of system themes to start from, you should now just see "Canvas Default". if you pick that, it should show the k12 theme. Change-Id: I5c2512e576dcb2aedaa899e17080d9c106e159ca Reviewed-on: https://gerrit.instructure.com/78163 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2016-01-19 03:29:32 +08:00
MD5_OF_K12_CONFIG = 'a1f113321fa024e7a14cb0948597a2a4'
def self.k12_config
All of the stuff from the save_a_theme dev branch this commit is the result of squashing a bunch of others together. this is everything that was already on the dev/save_a_theme branch as well as the "Add specs" commit. I left the test plans from some of the squashed commits in case they are helpful for QA Test plan: - Recompile assets, restart Canvas and clear browser cache - Go to Admin > [Your school name] - Click on Themes in the context menu - You should now see a collections page with a theme card for all the themes you have in Theme Editor: http://screencast.com/t/lb5vozF7 - Note: it might be my database, but on my end, I don't see a theme card for my Canvas default theme. There are also some brand colors missing for my theme cards. I'll be interested to see if you hit the same thing. These are issues that we can resolve with Ryan when he is back. - You should be able to click on the Apply and Delete buttons and see the confirm-overlays. We still need final copy for these. Test plan: - Go to your institution's Settings page and click Themes on the context menu. - You should now see a page listing all the default and user-created themes in your Canvas installation. - Clicking on each theme will open it inside theme editor. - The current/active theme will be correctly styled with a green outline change redirect targets and messages in theme editor test plan: exiting theme editor should redirect you back to the /accounts/x/themes page instead of /acounts/x make room for footer in theme editor test plan: in theme editor, scroll the preview to the bottom you should be able to scroll all the way, without having the bottom cut off by the footer remove "theme editor" button from account user/course search this is not needed since "Themes" now shows up in the left nav. test plan: turn on the 'Course and User Search' feature flag go to accounts/x you should not see a "theme editor" button on the right aka, not like this: http://cl.ly/2G2C3p3s3n0C fix "Exit" button in theme editor we were warning "you will lose unsaved changes" even when you hand not made any changes add specs to "Save A theme" stuff closes: CNVS-27961 test plan: do a whole regression test on the theme editor don't show both "k12 theme" and "canvas default" as options fixes: CNVS-25495 description (and test plan): if you are a k12 school, rather than seeing both "Canvas Default" and "K12 Theme" as options on the tiles of system themes to start from, you should now just see "Canvas Default". if you pick that, it should show the k12 theme. Change-Id: I5c2512e576dcb2aedaa899e17080d9c106e159ca Reviewed-on: https://gerrit.instructure.com/78163 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2016-01-19 03:29:32 +08:00
find(MD5_OF_K12_CONFIG)
end
def default?
([:variables] + OVERRIDE_TYPES).all? {|a| self[a].blank? }
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
def generate_md5
self.id = BrandConfig.md5_for(self)
end
def self.md5_for(brand_config)
Digest::MD5.hexdigest(ATTRS_TO_INCLUDE_IN_MD5.map { |a| brand_config[a] }.join)
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end
def get_value(variable_name)
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
effective_variables[variable_name]
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end
def overrides?
OVERRIDE_TYPES.any? { |o| self[o].present? }
end
subaccount branding (creation and trickle down) fixes CNVS-21426 changes theme_editor routes to nest under accounts show correct brand_config for subaccount be able to theme subaccounts parent account changes trickle down to subs theme editor default values are that of parent account add not in preview text that subaccounts dont show test plan: simple creation - create a sub-account - brand it differently from parent - if you go to courses belonging to this subaccount, it gets their css - if you go to courses belonging to the parent you get the parent css - if you go to a user dashboard you get the parent branding (maybe we can add smarts to this later in case you only are in the subaccount?) trickle down - rebrand two values on the parent - one that the subaccount explicitly sets - and one that doesnt - apply this config on the parent - wait a little and go to the child account - its theme inherits values for the parent, but... if it explicitly sets those values itself then it doesnt inherit it - go to the editor for the subaccount - the placeholder values are those of the parent account (or the canvas default if the parent hasnt set it) - test trickle down with a sub-account and a sub-sub-account still to do on different patch sets: - account settings to allow subaccount branding - show the progress of all the child compilation Change-Id: Iaddba7036f564965427807c2fd8b0a6a5d524366 Reviewed-on: https://gerrit.instructure.com/61285 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: August Thornton <august@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Colleen Palmer <colleen@instructure.com>
2015-08-15 02:42:55 +08:00
def effective_variables
@effective_variables ||=
chain_of_ancestor_configs.map(&:variables).reduce(variables, &:reverse_merge) || {}
end
def chain_of_ancestor_configs
get sub account branding and custom css/includes working fixes: CNVS-24787 fixes: CNVS-23964 fixes: CNVS-23957 - Handle parent account custom css/js for new_styles test plan: * set up a root account, child account, and grandchild account * use theme editor to set a custom css/js file for each (eg: for css `* {color:red}` and for js 'console.log("from grandchild")` * make a course & a group in the grandchild account * load a page in that course and group and make sure you see grandchild account's branding, and root's, child's, and then grandchild's css loaded on the page (grandchild should be loaded last so you see it's css effects override root or child's and you should see the console.log from root then child then grandchild) * view a page in "child". it should have root and child's css/js but not grandchild * as a user that only has enrollments (account associations) in "child", go to the dashboard. you should see css/js for both root and child but not grandchild fixes: CNVS-25051 Opening Theme Editor for sub-accounts shows incorrect theme preview test plan: * Go to a sub-account in theme editor and change settings so the Branding is different and save. * the preview on the right should reflect your changes both after you "apply" and "save" (and not just show the preview of the root account's branding) fixes: CNVS-23406 - global JS and CSS files are being included when Global CSS/JavaScript includes is false test plan: * go to /accounts/self/, and go to theme editor and upload a css_override * see that that css is loaded on pages * back in root account settings disable Global CSS/JavaScript includes * check that the css is no longer loaded. * do the same thing checking a subaccount's custom css fixes: CNVS-25558 - load whole chain of custom css/js in native app api requests test plan: * make api request for a wiki page in course in a subaccount that has custom css/js within a root account that also has custom css/js * you should see both the root account's css/js and the child account's returned in the response to test grandchild js issue jeremyp found: * go to theme editor for a grandchild account * choose a js override file (like: `console.log('first')`) * preview & apply * you should see "first" in console * go back to theme editor, pick a new file (like: `console.log('second')`) * preview & apply * you should only see "second" in console. not "first" Change-Id: I8d9047948f5da94be41e0205844629a170f980af Reviewed-on: https://gerrit.instructure.com/68249 Reviewed-by: Simon Williams <simon@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-12-05 00:57:07 +08:00
@ancestor_configs ||= [self] + (parent && parent.chain_of_ancestor_configs).to_a
subaccount branding (creation and trickle down) fixes CNVS-21426 changes theme_editor routes to nest under accounts show correct brand_config for subaccount be able to theme subaccounts parent account changes trickle down to subs theme editor default values are that of parent account add not in preview text that subaccounts dont show test plan: simple creation - create a sub-account - brand it differently from parent - if you go to courses belonging to this subaccount, it gets their css - if you go to courses belonging to the parent you get the parent css - if you go to a user dashboard you get the parent branding (maybe we can add smarts to this later in case you only are in the subaccount?) trickle down - rebrand two values on the parent - one that the subaccount explicitly sets - and one that doesnt - apply this config on the parent - wait a little and go to the child account - its theme inherits values for the parent, but... if it explicitly sets those values itself then it doesnt inherit it - go to the editor for the subaccount - the placeholder values are those of the parent account (or the canvas default if the parent hasnt set it) - test trickle down with a sub-account and a sub-sub-account still to do on different patch sets: - account settings to allow subaccount branding - show the progress of all the child compilation Change-Id: Iaddba7036f564965427807c2fd8b0a6a5d524366 Reviewed-on: https://gerrit.instructure.com/61285 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: August Thornton <august@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Colleen Palmer <colleen@instructure.com>
2015-08-15 02:42:55 +08:00
end
def clone_with_new_parent(new_parent_md5)
attrs = self.attributes.with_indifferent_access.slice(*BrandConfig::ATTRS_TO_INCLUDE_IN_MD5)
attrs[:parent_md5] = new_parent_md5
BrandConfig.for(attrs)
end
def dup?
BrandConfig.where(md5: self.md5).exists?
end
def save_unless_dup!
self.save! unless dup?
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
def to_json
BrandableCSS.all_brand_variable_values(self).to_json
end
def to_js
BrandableCSS.all_brand_variable_values_as_js(self)
end
def to_css
BrandableCSS.all_brand_variable_values_as_css(self)
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
def public_brand_dir
BrandableCSS.public_brandable_css_folder.join(md5)
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
def public_folder
"dist/brandable_css/#{md5}"
end
[:json, :js, :css].each do |type|
define_method :"public_#{type}_path" do
"#{public_folder}/variables-#{BrandableCSS.default_variables_md5}.#{type}"
end
define_method :"#{type}_file" do
public_brand_dir.join("variables-#{BrandableCSS.default_variables_md5}.#{type}")
end
define_method :"save_#{type}_file!" do
file = send(:"#{type}_file")
logger.info "saving brand variables #{type} file: #{file}"
public_brand_dir.mkpath
file.write(send(:"to_#{type}"))
send :"move_#{type}_to_s3_if_enabled!"
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
define_method :"move_#{type}_to_s3_if_enabled!" do
return unless Canvas::Cdn.enabled?
s3_uploader.upload_file(send(:"public_#{type}_path"))
begin
File.delete(send(:"#{type}_file"))
rescue Errno::ENOENT # continue if something else deleted it in another process
end
end
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
def s3_uploader
@s3_uploaderer ||= Canvas::Cdn::S3Uploader.new
end
def save_all_files!
save_json_file!
save_js_file!
save_css_file!
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
end
get sub account branding and custom css/includes working fixes: CNVS-24787 fixes: CNVS-23964 fixes: CNVS-23957 - Handle parent account custom css/js for new_styles test plan: * set up a root account, child account, and grandchild account * use theme editor to set a custom css/js file for each (eg: for css `* {color:red}` and for js 'console.log("from grandchild")` * make a course & a group in the grandchild account * load a page in that course and group and make sure you see grandchild account's branding, and root's, child's, and then grandchild's css loaded on the page (grandchild should be loaded last so you see it's css effects override root or child's and you should see the console.log from root then child then grandchild) * view a page in "child". it should have root and child's css/js but not grandchild * as a user that only has enrollments (account associations) in "child", go to the dashboard. you should see css/js for both root and child but not grandchild fixes: CNVS-25051 Opening Theme Editor for sub-accounts shows incorrect theme preview test plan: * Go to a sub-account in theme editor and change settings so the Branding is different and save. * the preview on the right should reflect your changes both after you "apply" and "save" (and not just show the preview of the root account's branding) fixes: CNVS-23406 - global JS and CSS files are being included when Global CSS/JavaScript includes is false test plan: * go to /accounts/self/, and go to theme editor and upload a css_override * see that that css is loaded on pages * back in root account settings disable Global CSS/JavaScript includes * check that the css is no longer loaded. * do the same thing checking a subaccount's custom css fixes: CNVS-25558 - load whole chain of custom css/js in native app api requests test plan: * make api request for a wiki page in course in a subaccount that has custom css/js within a root account that also has custom css/js * you should see both the root account's css/js and the child account's returned in the response to test grandchild js issue jeremyp found: * go to theme editor for a grandchild account * choose a js override file (like: `console.log('first')`) * preview & apply * you should see "first" in console * go back to theme editor, pick a new file (like: `console.log('second')`) * preview & apply * you should only see "second" in console. not "first" Change-Id: I8d9047948f5da94be41e0205844629a170f980af Reviewed-on: https://gerrit.instructure.com/68249 Reviewed-by: Simon Williams <simon@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-12-05 00:57:07 +08:00
def css_and_js_overrides
shard.activate do
@css_and_js_overrides ||= Rails.cache.fetch([self, 'css_and_js_overrides'].cache_key) do
chain_of_ancestor_configs.each_with_object({}) do |brand_config, includes|
BrandConfig::OVERRIDE_TYPES.each do |override_type|
if brand_config[override_type].present?
(includes[override_type] ||= []).unshift(brand_config[override_type])
end
get sub account branding and custom css/includes working fixes: CNVS-24787 fixes: CNVS-23964 fixes: CNVS-23957 - Handle parent account custom css/js for new_styles test plan: * set up a root account, child account, and grandchild account * use theme editor to set a custom css/js file for each (eg: for css `* {color:red}` and for js 'console.log("from grandchild")` * make a course & a group in the grandchild account * load a page in that course and group and make sure you see grandchild account's branding, and root's, child's, and then grandchild's css loaded on the page (grandchild should be loaded last so you see it's css effects override root or child's and you should see the console.log from root then child then grandchild) * view a page in "child". it should have root and child's css/js but not grandchild * as a user that only has enrollments (account associations) in "child", go to the dashboard. you should see css/js for both root and child but not grandchild fixes: CNVS-25051 Opening Theme Editor for sub-accounts shows incorrect theme preview test plan: * Go to a sub-account in theme editor and change settings so the Branding is different and save. * the preview on the right should reflect your changes both after you "apply" and "save" (and not just show the preview of the root account's branding) fixes: CNVS-23406 - global JS and CSS files are being included when Global CSS/JavaScript includes is false test plan: * go to /accounts/self/, and go to theme editor and upload a css_override * see that that css is loaded on pages * back in root account settings disable Global CSS/JavaScript includes * check that the css is no longer loaded. * do the same thing checking a subaccount's custom css fixes: CNVS-25558 - load whole chain of custom css/js in native app api requests test plan: * make api request for a wiki page in course in a subaccount that has custom css/js within a root account that also has custom css/js * you should see both the root account's css/js and the child account's returned in the response to test grandchild js issue jeremyp found: * go to theme editor for a grandchild account * choose a js override file (like: `console.log('first')`) * preview & apply * you should see "first" in console * go back to theme editor, pick a new file (like: `console.log('second')`) * preview & apply * you should only see "second" in console. not "first" Change-Id: I8d9047948f5da94be41e0205844629a170f980af Reviewed-on: https://gerrit.instructure.com/68249 Reviewed-by: Simon Williams <simon@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-12-05 00:57:07 +08:00
end
end
end
end
end
subaccount branding (creation and trickle down) fixes CNVS-21426 changes theme_editor routes to nest under accounts show correct brand_config for subaccount be able to theme subaccounts parent account changes trickle down to subs theme editor default values are that of parent account add not in preview text that subaccounts dont show test plan: simple creation - create a sub-account - brand it differently from parent - if you go to courses belonging to this subaccount, it gets their css - if you go to courses belonging to the parent you get the parent css - if you go to a user dashboard you get the parent branding (maybe we can add smarts to this later in case you only are in the subaccount?) trickle down - rebrand two values on the parent - one that the subaccount explicitly sets - and one that doesnt - apply this config on the parent - wait a little and go to the child account - its theme inherits values for the parent, but... if it explicitly sets those values itself then it doesnt inherit it - go to the editor for the subaccount - the placeholder values are those of the parent account (or the canvas default if the parent hasnt set it) - test trickle down with a sub-account and a sub-sub-account still to do on different patch sets: - account settings to allow subaccount branding - show the progress of all the child compilation Change-Id: Iaddba7036f564965427807c2fd8b0a6a5d524366 Reviewed-on: https://gerrit.instructure.com/61285 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: August Thornton <august@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Colleen Palmer <colleen@instructure.com>
2015-08-15 02:42:55 +08:00
def sync_to_s3_and_save_to_account!(progress, account_id)
save_and_sync_to_s3!(progress)
account = Account.find(account_id)
old_md5 = account.brand_config_md5
account.brand_config_md5 = md5
account.save!
BrandConfig.destroy_if_unused(old_md5)
end
def sync_to_s3_and_save_to_shared_brand_config!(progress, shared_brand_config_id)
save_and_sync_to_s3!(progress)
shared_brand_config = SharedBrandConfig.find(shared_brand_config_id)
old_md5 = shared_brand_config.brand_config_md5
shared_brand_config.brand_config_md5 = md5
shared_brand_config.save!
subaccount branding (creation and trickle down) fixes CNVS-21426 changes theme_editor routes to nest under accounts show correct brand_config for subaccount be able to theme subaccounts parent account changes trickle down to subs theme editor default values are that of parent account add not in preview text that subaccounts dont show test plan: simple creation - create a sub-account - brand it differently from parent - if you go to courses belonging to this subaccount, it gets their css - if you go to courses belonging to the parent you get the parent css - if you go to a user dashboard you get the parent branding (maybe we can add smarts to this later in case you only are in the subaccount?) trickle down - rebrand two values on the parent - one that the subaccount explicitly sets - and one that doesnt - apply this config on the parent - wait a little and go to the child account - its theme inherits values for the parent, but... if it explicitly sets those values itself then it doesnt inherit it - go to the editor for the subaccount - the placeholder values are those of the parent account (or the canvas default if the parent hasnt set it) - test trickle down with a sub-account and a sub-sub-account still to do on different patch sets: - account settings to allow subaccount branding - show the progress of all the child compilation Change-Id: Iaddba7036f564965427807c2fd8b0a6a5d524366 Reviewed-on: https://gerrit.instructure.com/61285 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: August Thornton <august@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Colleen Palmer <colleen@instructure.com>
2015-08-15 02:42:55 +08:00
BrandConfig.destroy_if_unused(old_md5)
end
def save_and_sync_to_s3!(progress=nil)
progress.update_completion!(5) if progress
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
save_all_files!
progress.update_completion!(80) if progress
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end
def self.destroy_if_unused(md5)
return unless md5
unused_brand_config = BrandConfig.
where(md5: md5).
where("NOT EXISTS (?)", Account.where("brand_config_md5=brand_configs.md5")).
All of the stuff from the save_a_theme dev branch this commit is the result of squashing a bunch of others together. this is everything that was already on the dev/save_a_theme branch as well as the "Add specs" commit. I left the test plans from some of the squashed commits in case they are helpful for QA Test plan: - Recompile assets, restart Canvas and clear browser cache - Go to Admin > [Your school name] - Click on Themes in the context menu - You should now see a collections page with a theme card for all the themes you have in Theme Editor: http://screencast.com/t/lb5vozF7 - Note: it might be my database, but on my end, I don't see a theme card for my Canvas default theme. There are also some brand colors missing for my theme cards. I'll be interested to see if you hit the same thing. These are issues that we can resolve with Ryan when he is back. - You should be able to click on the Apply and Delete buttons and see the confirm-overlays. We still need final copy for these. Test plan: - Go to your institution's Settings page and click Themes on the context menu. - You should now see a page listing all the default and user-created themes in your Canvas installation. - Clicking on each theme will open it inside theme editor. - The current/active theme will be correctly styled with a green outline change redirect targets and messages in theme editor test plan: exiting theme editor should redirect you back to the /accounts/x/themes page instead of /acounts/x make room for footer in theme editor test plan: in theme editor, scroll the preview to the bottom you should be able to scroll all the way, without having the bottom cut off by the footer remove "theme editor" button from account user/course search this is not needed since "Themes" now shows up in the left nav. test plan: turn on the 'Course and User Search' feature flag go to accounts/x you should not see a "theme editor" button on the right aka, not like this: http://cl.ly/2G2C3p3s3n0C fix "Exit" button in theme editor we were warning "you will lose unsaved changes" even when you hand not made any changes add specs to "Save A theme" stuff closes: CNVS-27961 test plan: do a whole regression test on the theme editor don't show both "k12 theme" and "canvas default" as options fixes: CNVS-25495 description (and test plan): if you are a k12 school, rather than seeing both "Canvas Default" and "K12 Theme" as options on the tiles of system themes to start from, you should now just see "Canvas Default". if you pick that, it should show the k12 theme. Change-Id: I5c2512e576dcb2aedaa899e17080d9c106e159ca Reviewed-on: https://gerrit.instructure.com/78163 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2016-01-19 03:29:32 +08:00
where("NOT EXISTS (?)", SharedBrandConfig.where("brand_config_md5=brand_configs.md5")).
first
if unused_brand_config
unused_brand_config.destroy
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end
Create predeploy rake task to handle Theme Editor closes: CNVS-21990 This is the rake task we call from a job server once that has new code before restarting all the app servers. It will make sure that our s3 bucket has all static assets including the css for custom themes people have created in the Theme Editor test plan: * make sure you have an config/canvas_cdn.yml file * `rm -rf public/dist` * run `bundle exec rake brand_configs:generate_and_upload_all` * in log/development.log you should see it write a _variables.scss file for each brand_config in any shard to disk, compile the css for each of those brands and push all the js/css/images/etc to s3 * browse pages in canvas, the css/images/js should be served from your "host:" configured in canvas_cdn.yml and none should 404 this change also includes: better error message when brandable_css manifest doesn't exist if the manifest file can't be found, this will tell you the full path to the file it was looking for so that if it can't find the manifest file,it will tell you the path to the file it was looking for. test plan: with RAILS_ENV=production: * rm -rf public/dist * try to access a page the error that it give you should tell you the full path to the json file it tried to read. if we haven't loaded rails yet, we still want to look at RAILS_ENV to get which style of css to generate Change-Id: I2dbb12541d6a28e90a326a51f0cddb90f313842f Reviewed-on: https://gerrit.instructure.com/58809 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-07-20 23:49:03 +08:00
def self.clean_unused_from_db!
BrandConfig.
where("NOT EXISTS (?)", Account.where("brand_config_md5=brand_configs.md5")).
All of the stuff from the save_a_theme dev branch this commit is the result of squashing a bunch of others together. this is everything that was already on the dev/save_a_theme branch as well as the "Add specs" commit. I left the test plans from some of the squashed commits in case they are helpful for QA Test plan: - Recompile assets, restart Canvas and clear browser cache - Go to Admin > [Your school name] - Click on Themes in the context menu - You should now see a collections page with a theme card for all the themes you have in Theme Editor: http://screencast.com/t/lb5vozF7 - Note: it might be my database, but on my end, I don't see a theme card for my Canvas default theme. There are also some brand colors missing for my theme cards. I'll be interested to see if you hit the same thing. These are issues that we can resolve with Ryan when he is back. - You should be able to click on the Apply and Delete buttons and see the confirm-overlays. We still need final copy for these. Test plan: - Go to your institution's Settings page and click Themes on the context menu. - You should now see a page listing all the default and user-created themes in your Canvas installation. - Clicking on each theme will open it inside theme editor. - The current/active theme will be correctly styled with a green outline change redirect targets and messages in theme editor test plan: exiting theme editor should redirect you back to the /accounts/x/themes page instead of /acounts/x make room for footer in theme editor test plan: in theme editor, scroll the preview to the bottom you should be able to scroll all the way, without having the bottom cut off by the footer remove "theme editor" button from account user/course search this is not needed since "Themes" now shows up in the left nav. test plan: turn on the 'Course and User Search' feature flag go to accounts/x you should not see a "theme editor" button on the right aka, not like this: http://cl.ly/2G2C3p3s3n0C fix "Exit" button in theme editor we were warning "you will lose unsaved changes" even when you hand not made any changes add specs to "Save A theme" stuff closes: CNVS-27961 test plan: do a whole regression test on the theme editor don't show both "k12 theme" and "canvas default" as options fixes: CNVS-25495 description (and test plan): if you are a k12 school, rather than seeing both "Canvas Default" and "K12 Theme" as options on the tiles of system themes to start from, you should now just see "Canvas Default". if you pick that, it should show the k12 theme. Change-Id: I5c2512e576dcb2aedaa899e17080d9c106e159ca Reviewed-on: https://gerrit.instructure.com/78163 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2016-01-19 03:29:32 +08:00
where("NOT EXISTS (?)", SharedBrandConfig.where("brand_config_md5=brand_configs.md5")).
Create predeploy rake task to handle Theme Editor closes: CNVS-21990 This is the rake task we call from a job server once that has new code before restarting all the app servers. It will make sure that our s3 bucket has all static assets including the css for custom themes people have created in the Theme Editor test plan: * make sure you have an config/canvas_cdn.yml file * `rm -rf public/dist` * run `bundle exec rake brand_configs:generate_and_upload_all` * in log/development.log you should see it write a _variables.scss file for each brand_config in any shard to disk, compile the css for each of those brands and push all the js/css/images/etc to s3 * browse pages in canvas, the css/images/js should be served from your "host:" configured in canvas_cdn.yml and none should 404 this change also includes: better error message when brandable_css manifest doesn't exist if the manifest file can't be found, this will tell you the full path to the file it was looking for so that if it can't find the manifest file,it will tell you the path to the file it was looking for. test plan: with RAILS_ENV=production: * rm -rf public/dist * try to access a page the error that it give you should tell you the full path to the json file it tried to read. if we haven't loaded rails yet, we still want to look at RAILS_ENV to get which style of css to generate Change-Id: I2dbb12541d6a28e90a326a51f0cddb90f313842f Reviewed-on: https://gerrit.instructure.com/58809 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-07-20 23:49:03 +08:00
# When someone is actively working in the theme editor, it just saves one
# in their session, so only delete stuff that is more than a week old,
# to not clear out a theme someone was working on.
where(["created_at < ?", 1.week.ago]).
delete_all
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end