2019-04-29 20:27:42 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2022-01-09 14:26:19 -05:00
|
|
|
GIT_INITIAL_BRANCH_SUPPORTED =
|
|
|
|
Gem::Version.new(`git --version`.match(/[\d\.]+/)[0]) >= Gem::Version.new("2.28.0")
|
|
|
|
|
2013-09-05 07:22:15 -04:00
|
|
|
module Helpers
|
2016-12-12 20:59:38 -05:00
|
|
|
extend ActiveSupport::Concern
|
|
|
|
|
2013-09-05 07:22:15 -04:00
|
|
|
def self.next_seq
|
|
|
|
@next_seq = (@next_seq || 0) + 1
|
|
|
|
end
|
|
|
|
|
|
|
|
def log_in(fabricator = nil)
|
|
|
|
user = Fabricate(fabricator || :user)
|
|
|
|
log_in_user(user)
|
|
|
|
user
|
|
|
|
end
|
|
|
|
|
|
|
|
def log_in_user(user)
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
cookie_jar = ActionDispatch::Request.new(request.env).cookie_jar
|
2013-10-09 00:10:37 -04:00
|
|
|
provider = Discourse.current_user_provider.new(request.env)
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
provider.log_on_user(user, session, cookie_jar)
|
2019-03-19 08:39:13 -04:00
|
|
|
provider
|
|
|
|
end
|
|
|
|
|
|
|
|
def log_out_user(provider)
|
|
|
|
provider.log_off_user(session, cookies)
|
2013-09-05 07:22:15 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def fixture_file(filename)
|
|
|
|
return "" if filename.blank?
|
|
|
|
file_path = File.expand_path(Rails.root + "spec/fixtures/" + filename)
|
|
|
|
File.read(file_path)
|
|
|
|
end
|
|
|
|
|
|
|
|
def build(*args)
|
|
|
|
Fabricate.build(*args)
|
|
|
|
end
|
|
|
|
|
|
|
|
def create_topic(args = {})
|
|
|
|
args[:title] ||= "This is my title #{Helpers.next_seq}"
|
2023-12-12 22:50:13 -05:00
|
|
|
user = args.delete(:user)
|
2024-01-25 01:28:26 -05:00
|
|
|
user = Fabricate(:user, refresh_auto_groups: true) if !user
|
2013-09-05 07:22:15 -04:00
|
|
|
guardian = Guardian.new(user)
|
2016-12-05 07:31:43 -05:00
|
|
|
args[:category] = args[:category].id if args[:category].is_a?(Category)
|
2013-09-05 07:22:15 -04:00
|
|
|
TopicCreator.create(user, guardian, args)
|
|
|
|
end
|
|
|
|
|
|
|
|
def create_post(args = {})
|
2022-09-30 14:20:21 -04:00
|
|
|
# Pretty much all the tests with `create_post` will fail without this
|
|
|
|
# since allow_uncategorized_topics is now false by default
|
|
|
|
SiteSetting.allow_uncategorized_topics = true unless args[:allow_uncategorized_topics] == false
|
|
|
|
|
2013-09-05 07:22:15 -04:00
|
|
|
args[:title] ||= "This is my title #{Helpers.next_seq}"
|
|
|
|
args[:raw] ||= "This is the raw body of my post, it is cool #{Helpers.next_seq}"
|
|
|
|
args[:topic_id] = args[:topic].id if args[:topic]
|
2024-01-25 01:28:26 -05:00
|
|
|
user = args.delete(:user) || Fabricate(:user, refresh_auto_groups: true)
|
2016-12-05 07:31:43 -05:00
|
|
|
args[:category] = args[:category].id if args[:category].is_a?(Category)
|
2016-02-03 02:50:05 -05:00
|
|
|
creator = PostCreator.new(user, args)
|
|
|
|
post = creator.create
|
|
|
|
|
|
|
|
raise StandardError.new(creator.errors.full_messages.join(" ")) if creator.errors.present?
|
|
|
|
|
|
|
|
post
|
2013-09-05 07:22:15 -04:00
|
|
|
end
|
|
|
|
|
2013-11-08 14:11:41 -05:00
|
|
|
def stub_guardian(user)
|
|
|
|
guardian = Guardian.new(user)
|
|
|
|
yield(guardian) if block_given?
|
2018-10-09 10:21:41 -04:00
|
|
|
Guardian.stubs(new: guardian).with(user, anything)
|
2013-11-08 14:11:41 -05:00
|
|
|
end
|
2014-11-11 18:27:34 -05:00
|
|
|
|
2023-10-02 08:00:29 -04:00
|
|
|
def wait_for(on_fail: nil, timeout: 1, &blk)
|
2014-11-11 18:27:34 -05:00
|
|
|
i = 0
|
|
|
|
result = false
|
2023-10-02 08:00:29 -04:00
|
|
|
while !result && i < timeout * 1000
|
2014-11-11 18:27:34 -05:00
|
|
|
result = blk.call
|
|
|
|
i += 1
|
|
|
|
sleep 0.001
|
|
|
|
end
|
|
|
|
|
2017-08-23 10:41:47 -04:00
|
|
|
on_fail&.call
|
2015-04-25 11:18:35 -04:00
|
|
|
expect(result).to eq(true)
|
2014-11-11 18:27:34 -05:00
|
|
|
end
|
|
|
|
|
2016-04-07 10:21:17 -04:00
|
|
|
def email(email_name)
|
|
|
|
fixture_file("emails/#{email_name}.eml")
|
|
|
|
end
|
2018-04-20 15:25:28 -04:00
|
|
|
|
2020-10-14 13:15:54 -04:00
|
|
|
def create_staff_only_tags(tag_names)
|
|
|
|
create_limited_tags("Staff Tags", Group::AUTO_GROUPS[:staff], tag_names)
|
|
|
|
end
|
|
|
|
|
|
|
|
def create_limited_tags(tag_group_name, group_id, tag_names)
|
|
|
|
tag_group = Fabricate(:tag_group, name: tag_group_name)
|
|
|
|
TagGroupPermission.where(
|
2018-04-20 15:25:28 -04:00
|
|
|
tag_group: tag_group,
|
|
|
|
group_id: Group::AUTO_GROUPS[:everyone],
|
2020-10-14 13:15:54 -04:00
|
|
|
permission_type: TagGroupPermission.permission_types[:full],
|
|
|
|
).update(permission_type: TagGroupPermission.permission_types[:readonly])
|
2018-04-20 15:25:28 -04:00
|
|
|
TagGroupPermission.create!(
|
|
|
|
tag_group: tag_group,
|
2020-10-14 13:15:54 -04:00
|
|
|
group_id: group_id,
|
2018-04-20 15:25:28 -04:00
|
|
|
permission_type: TagGroupPermission.permission_types[:full],
|
|
|
|
)
|
|
|
|
tag_names.each do |name|
|
|
|
|
tag_group.tags << (Tag.where(name: name).first || Fabricate(:tag, name: name))
|
|
|
|
end
|
|
|
|
end
|
2019-01-31 23:40:48 -05:00
|
|
|
|
2019-05-06 14:51:51 -04:00
|
|
|
def create_hidden_tags(tag_names)
|
|
|
|
tag_group = Fabricate(:tag_group, name: "Hidden Tags", permissions: { staff: :full })
|
|
|
|
tag_names.each do |name|
|
|
|
|
tag_group.tags << (Tag.where(name: name).first || Fabricate(:tag, name: name))
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-12-04 13:33:51 -05:00
|
|
|
def sorted_tag_names(tag_records)
|
|
|
|
tag_records.map { |t| t.is_a?(String) ? t : t.name }.sort
|
|
|
|
end
|
|
|
|
|
|
|
|
def expect_same_tag_names(a, b)
|
|
|
|
expect(sorted_tag_names(a)).to eq(sorted_tag_names(b))
|
|
|
|
end
|
|
|
|
|
2020-10-12 12:25:06 -04:00
|
|
|
def capture_output(output_name)
|
2020-03-02 18:03:58 -05:00
|
|
|
if ENV["RAILS_ENABLE_TEST_STDOUT"]
|
|
|
|
yield
|
|
|
|
return
|
|
|
|
end
|
2020-10-12 12:25:06 -04:00
|
|
|
|
|
|
|
previous_output = output_name == :stdout ? $stdout : $stderr
|
|
|
|
|
2019-01-31 23:40:48 -05:00
|
|
|
io = StringIO.new
|
2020-10-12 12:25:06 -04:00
|
|
|
output_name == :stdout ? $stdout = io : $stderr = io
|
|
|
|
|
2019-01-31 23:40:48 -05:00
|
|
|
yield
|
|
|
|
io.string
|
|
|
|
ensure
|
2020-10-12 12:25:06 -04:00
|
|
|
output_name == :stdout ? $stdout = previous_output : $stderr = previous_output
|
|
|
|
end
|
|
|
|
|
|
|
|
def capture_stdout(&block)
|
|
|
|
capture_output(:stdout, &block)
|
|
|
|
end
|
|
|
|
|
|
|
|
def capture_stderr(&block)
|
|
|
|
capture_output(:stderr, &block)
|
2019-01-31 23:40:48 -05:00
|
|
|
end
|
2019-11-15 00:48:24 -05:00
|
|
|
|
2023-06-12 07:59:54 -04:00
|
|
|
def set_subfolder(new_root)
|
|
|
|
global_setting :relative_url_root, new_root
|
|
|
|
|
2019-11-15 00:48:24 -05:00
|
|
|
old_root = ActionController::Base.config.relative_url_root
|
2023-06-12 07:59:54 -04:00
|
|
|
ActionController::Base.config.relative_url_root = new_root
|
|
|
|
Rails.application.routes.stubs(:relative_url_root).returns(new_root)
|
2019-11-15 00:48:24 -05:00
|
|
|
|
|
|
|
before_next_spec { ActionController::Base.config.relative_url_root = old_root }
|
2023-06-12 07:59:54 -04:00
|
|
|
|
|
|
|
if RSpec.current_example.metadata[:type] == :system
|
|
|
|
Capybara.app.map("/") { run lambda { |env| [404, {}, [""]] } }
|
|
|
|
Capybara.app.map(new_root) { run Rails.application }
|
|
|
|
|
|
|
|
before_next_spec do
|
|
|
|
Capybara.app.map(new_root) { run lambda { |env| [404, {}, [""]] } }
|
|
|
|
Capybara.app.map("/") { run Rails.application }
|
|
|
|
end
|
|
|
|
end
|
2019-11-15 00:48:24 -05:00
|
|
|
end
|
2020-01-28 19:11:38 -05:00
|
|
|
|
2020-10-12 12:25:06 -04:00
|
|
|
def setup_git_repo(files)
|
|
|
|
repo_dir = Dir.mktmpdir
|
2022-01-09 14:26:19 -05:00
|
|
|
`cd #{repo_dir} && git init . #{"--initial-branch=main" if GIT_INITIAL_BRANCH_SUPPORTED}`
|
2020-10-12 12:25:06 -04:00
|
|
|
`cd #{repo_dir} && git config user.email 'someone@cool.com'`
|
|
|
|
`cd #{repo_dir} && git config user.name 'The Cool One'`
|
|
|
|
`cd #{repo_dir} && git config commit.gpgsign 'false'`
|
|
|
|
files.each do |name, data|
|
|
|
|
FileUtils.mkdir_p(Pathname.new("#{repo_dir}/#{name}").dirname)
|
|
|
|
File.write("#{repo_dir}/#{name}", data)
|
|
|
|
`cd #{repo_dir} && git add #{name}`
|
|
|
|
end
|
|
|
|
`cd #{repo_dir} && git commit -am 'first commit'`
|
|
|
|
repo_dir
|
|
|
|
end
|
2021-06-16 18:20:09 -04:00
|
|
|
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
def add_to_git_repo(repo_dir, files)
|
|
|
|
files.each do |name, data|
|
|
|
|
FileUtils.mkdir_p(Pathname.new("#{repo_dir}/#{name}").dirname)
|
|
|
|
File.write("#{repo_dir}/#{name}", data)
|
|
|
|
`cd #{repo_dir} && git add #{name}`
|
|
|
|
end
|
|
|
|
`cd #{repo_dir} && git commit -am 'add #{files.size} files'`
|
|
|
|
repo_dir
|
|
|
|
end
|
|
|
|
|
2021-06-16 18:20:09 -04:00
|
|
|
def stub_const(target, const, value)
|
|
|
|
old = target.const_get(const)
|
|
|
|
target.send(:remove_const, const)
|
|
|
|
target.const_set(const, value)
|
|
|
|
yield
|
|
|
|
ensure
|
|
|
|
target.send(:remove_const, const)
|
|
|
|
target.const_set(const, old)
|
|
|
|
end
|
2022-03-14 18:23:39 -04:00
|
|
|
|
|
|
|
def track_sql_queries
|
|
|
|
queries = []
|
|
|
|
callback = ->(*, payload) do
|
2024-05-27 06:27:13 -04:00
|
|
|
queries << payload.fetch(:sql) if %w[CACHE SCHEMA].exclude?(payload.fetch(:name))
|
2022-03-14 18:23:39 -04:00
|
|
|
end
|
|
|
|
|
2024-09-11 03:14:53 -04:00
|
|
|
ActiveSupport::Notifications.subscribed(callback, "sql.active_record") do
|
|
|
|
ActiveSupport::Notifications.subscribed(callback, "sql.mini_sql") { yield }
|
|
|
|
end
|
2023-01-09 06:18:21 -05:00
|
|
|
|
2022-03-14 18:23:39 -04:00
|
|
|
queries
|
|
|
|
end
|
2023-03-07 20:28:09 -05:00
|
|
|
|
|
|
|
def stub_ip_lookup(stub_addr, ips)
|
|
|
|
Addrinfo
|
|
|
|
.stubs(:getaddrinfo)
|
|
|
|
.with { |addr, _| addr == stub_addr }
|
|
|
|
.returns(
|
|
|
|
ips.map { |ip| Addrinfo.new([IPAddr.new(ip).ipv6? ? "AF_INET6" : "AF_INET", 80, nil, ip]) },
|
|
|
|
)
|
|
|
|
end
|
2023-05-03 21:20:52 -04:00
|
|
|
|
|
|
|
def with_search_indexer_enabled
|
|
|
|
SearchIndexer.enable
|
|
|
|
yield
|
|
|
|
ensure
|
|
|
|
SearchIndexer.disable
|
|
|
|
end
|
DEV: Introduce `run_theme_migration` spec helper in test environment (#26845)
This commit introduces the `run_theme_migration` spec helper to allow
theme developers to write RSpec tests for theme migrations. For example,
this allows the following RSpec test to be written in themes:
```
RSpec.describe "0003-migrate-small-links-setting migration" do
let!(:theme) { upload_theme_component }
it "should set target property to `_blank` if previous target component is not valid or empty" do
theme.theme_settings.create!(
name: "small_links",
theme: theme,
data_type: ThemeSetting.types[:string],
value: "some text, #|some text 2, #, invalid target",
)
run_theme_migration(theme, "0003-migrate-small-links-setting")
expect(theme.settings[:small_links].value).to eq(
[
{ "text" => "some text", "url" => "#", "target" => "_blank" },
{ "text" => "some text 2", "url" => "#", "target" => "_blank" },
],
)
end
end
```
This change is being introduced because we realised that writting just
javascript tests for the migrations is insufficient since javascript
tests do not ensure that the migrated theme settings can actually be
successfully saved into the database. Hence, we are introduce this
helper as a way for theme developers to write "end-to-end" migrations
tests.
2024-05-02 18:29:18 -04:00
|
|
|
|
|
|
|
# Uploads a theme from a directory.
|
|
|
|
#
|
|
|
|
# @param set_theme_as_default [Boolean] Whether to set the uploaded theme as the default theme for the site. Defaults to true.
|
|
|
|
#
|
|
|
|
# @return [Theme] The uploaded theme model given by `models/theme.rb`.
|
|
|
|
#
|
|
|
|
# @example Upload a theme and set it as default
|
|
|
|
# upload_theme("/path/to/theme")
|
|
|
|
def upload_theme(set_theme_as_default: true)
|
|
|
|
theme = RemoteTheme.import_theme_from_directory(theme_dir_from_caller)
|
|
|
|
|
|
|
|
if theme.component
|
|
|
|
raise "Uploaded theme is a theme component, please use the `upload_theme_component` method instead."
|
|
|
|
end
|
|
|
|
|
|
|
|
theme.set_default! if set_theme_as_default
|
|
|
|
theme
|
|
|
|
end
|
|
|
|
|
2024-11-19 23:17:36 -05:00
|
|
|
# Invokes a Rake task in a way that is safe for the test environment
|
|
|
|
def invoke_rake_task(task_name, *args)
|
|
|
|
Rake::Task[task_name].invoke(*args)
|
|
|
|
ensure
|
|
|
|
Rake::Task[task_name].reenable
|
|
|
|
end
|
|
|
|
|
DEV: Introduce `run_theme_migration` spec helper in test environment (#26845)
This commit introduces the `run_theme_migration` spec helper to allow
theme developers to write RSpec tests for theme migrations. For example,
this allows the following RSpec test to be written in themes:
```
RSpec.describe "0003-migrate-small-links-setting migration" do
let!(:theme) { upload_theme_component }
it "should set target property to `_blank` if previous target component is not valid or empty" do
theme.theme_settings.create!(
name: "small_links",
theme: theme,
data_type: ThemeSetting.types[:string],
value: "some text, #|some text 2, #, invalid target",
)
run_theme_migration(theme, "0003-migrate-small-links-setting")
expect(theme.settings[:small_links].value).to eq(
[
{ "text" => "some text", "url" => "#", "target" => "_blank" },
{ "text" => "some text 2", "url" => "#", "target" => "_blank" },
],
)
end
end
```
This change is being introduced because we realised that writting just
javascript tests for the migrations is insufficient since javascript
tests do not ensure that the migrated theme settings can actually be
successfully saved into the database. Hence, we are introduce this
helper as a way for theme developers to write "end-to-end" migrations
tests.
2024-05-02 18:29:18 -04:00
|
|
|
# Uploads a theme component from a directory.
|
|
|
|
#
|
|
|
|
# @param parent_theme_id [Integer] The ID of the theme to add the theme component to. Defaults to `SiteSetting.default_theme_id`.
|
|
|
|
#
|
|
|
|
# @return [Theme] The uploaded theme model given by `models/theme.rb`.
|
|
|
|
#
|
|
|
|
# @example Upload a theme component
|
|
|
|
# upload_theme_component("/path/to/theme_component")
|
|
|
|
#
|
|
|
|
# @example Upload a theme component and add it to a specific theme
|
|
|
|
# upload_theme_component("/path/to/theme_component", parent_theme_id: 123)
|
|
|
|
def upload_theme_component(parent_theme_id: SiteSetting.default_theme_id)
|
|
|
|
theme = RemoteTheme.import_theme_from_directory(theme_dir_from_caller)
|
|
|
|
|
|
|
|
if !theme.component
|
|
|
|
raise "Uploaded theme is not a theme component, please use the `upload_theme` method instead."
|
|
|
|
end
|
|
|
|
|
|
|
|
Theme.find(parent_theme_id).child_themes << theme
|
|
|
|
theme
|
|
|
|
end
|
|
|
|
|
|
|
|
# Runs named migration for a given theme.
|
|
|
|
#
|
|
|
|
# @params [Theme] theme The theme to run the migration for.
|
|
|
|
# @params [String] migration_name The name of the migration to run.
|
|
|
|
#
|
|
|
|
# @return [nil]
|
|
|
|
#
|
|
|
|
# @example
|
|
|
|
# run_theme_migration(theme, "0001-migrate-some-settings")
|
|
|
|
def run_theme_migration(theme, migration_name)
|
|
|
|
migration_theme_field = theme.theme_fields.find_by(name: migration_name)
|
|
|
|
theme.migrate_settings(fields: [migration_theme_field], allow_out_of_sequence_migration: true)
|
|
|
|
nil
|
|
|
|
end
|
|
|
|
|
|
|
|
private
|
|
|
|
|
|
|
|
def theme_dir_from_caller
|
|
|
|
caller.each do |line|
|
|
|
|
if (split = line.split(%r{/spec/*/.+_spec.rb})).length > 1
|
|
|
|
return split.first
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2013-09-05 07:22:15 -04:00
|
|
|
end
|