hydra-head 4.0.0.rc5 → 4.0.0.rc6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (44) hide show
  1. data/HISTORY.textile +1 -1
  2. data/HOW_TO_GET_STARTED.textile +2 -2
  3. data/INSTALL_PREREQ.textile +1 -20
  4. data/README.textile +12 -16
  5. data/app/assets/stylesheets/hydra/html_refactor.css +1 -5
  6. data/app/assets/stylesheets/hydra/hydrangea.css +0 -4
  7. data/app/assets/stylesheets/hydra/styles.css +12 -595
  8. data/app/controllers/downloads_controller.rb +2 -1
  9. data/app/controllers/hydra/permissions_controller.rb +2 -6
  10. data/app/models/ability.rb +1 -98
  11. data/app/models/hydra/ability.rb +128 -0
  12. data/app/views/_flash_msg.html.erb +1 -1
  13. data/app/views/catalog/_home.html.erb +2 -2
  14. data/app/views/catalog/_home_text.html.erb +2 -8
  15. data/app/views/catalog/_show_partials/_default.html.erb +0 -4
  16. data/app/views/generic_images/_edit.html.erb +0 -2
  17. data/app/views/layouts/hydra-head.html.erb +22 -35
  18. data/lib/hydra-head/version.rb +1 -1
  19. data/lib/hydra/mods_article.rb +22 -2
  20. data/lib/railties/hydra-fixtures.rake +17 -24
  21. data/tasks/hydra-head-fixtures.rake +32 -28
  22. data/tasks/hydra-head.rake +39 -57
  23. data/{lib/railties → tasks}/hyhead_rspec.rake +7 -26
  24. data/test_support/features/file_upload.feature +3 -3
  25. data/test_support/features/step_definitions/edit_metadata_steps.rb +1 -1
  26. data/test_support/features/step_definitions/user_steps.rb +7 -4
  27. data/test_support/spec/models/ability_spec.rb +3 -9
  28. metadata +36 -51
  29. data/DEVELOP_PLUGIN.textile +0 -90
  30. data/GIT_WORKFLOW.textile +0 -106
  31. data/HOW_TO_DEFINE_A_HYDRA_CONTROLLER.textile +0 -21
  32. data/HOW_TO_DEFINE_A_HYDRA_MODEL.textile +0 -64
  33. data/HYDRA_ACCESS_CONTROLS.textile +0 -27
  34. data/INITIAL_APP_MODS.textile +0 -223
  35. data/README_RAILS3_CHANGES.textile +0 -67
  36. data/README_RAKE_TASKS.textile +0 -107
  37. data/README_SUBTREE.textile +0 -87
  38. data/README_TERSE.textile +0 -92
  39. data/RELEASE_NOTES.textile +0 -8
  40. data/TESTING.textile +0 -85
  41. data/TESTING_PLUGIN.textile +0 -133
  42. data/app/views/layouts/application.html.erb +0 -49
  43. data/lib/railties/all_tests.rake +0 -23
  44. data/lib/railties/hyhead_cucumber.rake +0 -126
@@ -1,67 +0,0 @@
1
-
2
- h2. Views
3
-
4
- Security has been tightened in Rails3, forcing you to include _authenticity_token__ with all requests. If you have forms or javascript that submits requests without this token, Rails will destroy the user session, effectively logging the user out (see http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails). The easiest way to make sure this token is properly included in your forms is to generate the forms using the +form_tag+ or +form_for+ view helpers from Rails.
5
-
6
- h2. Fixtures
7
-
8
- Fixtures are loaded from a directory _within the test app_, which is updated when you run rake hyhead:setup_test_app so in order to update a fixture, you must change it in test_support/fixtures and then either re-run rake hyhead:setup_test_app or copy the fixture into tmp/test_app/test_support/fixtures
9
-
10
- h2. Cucumber tests
11
-
12
- We have switched from Webrat to Capybara as the driver for our Cucumber tests. If you have been writing your own cucumber tests (you should!) and want to stay in sync with the rest of the hydra developers, you should switch to Capybara and pull all of the "step definitions from the hydra code":https://github.com/projecthydra/hydra-head/tree/rails3/test_support/features/step_definitions into your local app.
13
-
14
- Sometime soon, we hope to wrap our step definitions into the Hydra code itself so that you can use them without having to manually copy the files into your step_definitions directory. This will probably be done in a way that imitates the "Factory Girl step definitions":http://robots.thoughtbot.com/post/284805810/gimme-three-steps
15
-
16
- h2. User objects
17
-
18
- Blacklight has switched to using devise instead of authlogic as its default user/authentication system. As part of this switch, no longer have a "login" attribute as their unique identifier. Instead, you must use email as the unique identifier. We have added a "login" method that
19
-
20
- h2. User Attributes
21
-
22
- User attributes (first_name, last_name, full_name, affiliation and photo) have been removed from HydraHead.
23
-
24
- h2. Controllers
25
-
26
- * Removed Djatoka (JPEG 2000) support and the GetController
27
-
28
- h2. Views
29
-
30
- * removed fluid infusion javascript
31
- * moved javascripts from the plugin directory. Update your views to remove ":plugin=>:hydra_repository"
32
-
33
- h3. What this means:
34
-
35
- * Our sample user "archivist1" is now "archivist1@example.com".
36
- * Your cucumber features and rspec tests must use email addresses as the unique identifier for Users
37
-
38
- Change your features and role_map YAML files accordingly.
39
-
40
-
41
-
42
-
43
- h2. How to upgrade
44
-
45
- The sureest and easiest path to upgrading a hydra head application from Rails 2 to Rails 3, is to start a new project from scratch.
46
-
47
- * Create a new rails 3 project
48
- * Add ```gem 'blacklight'``` and ```gem 'hydra-head'``` to the Gemfile
49
- * run ```bundle install```
50
- * cp -r old_project/vendor/plugin/old_project_plugin/app/* new_project/app
51
- * cp -r old_project/vendor/plugin/old_project_plugin/lib/* new_project/lib
52
- <<<<<<< HEAD
53
- * copy any tests (test, spec, feature, etc) from the old_project_plugin directory to the new project
54
- * Run the generators
55
- ```rails g blackight -devise```
56
- Run the hydra-head generator
57
- ```rails g hydra:head -df```
58
- Run the database migrations
59
- ```rake db:migrate
60
- rake db:migrate RAILS_ENV=test```
61
-
62
- * If you will be writing cucumber tests, run the cucumber generator
63
- ```rails g cucumber:install```
64
- * copy any tests (test, spec, feature, etc) from the old_project_plugin directory to the new project
65
- * update your solrconfig.xml
66
- * update your role_map_...yml files to use appropriate identifiers
67
-
@@ -1,107 +0,0 @@
1
- h2. Getting info about the rake tasks from the command line
2
-
3
- <pre>rake -T</pre>
4
-
5
- To narrow down the output, use grep. For example:
6
-
7
- <pre>rake -T | grep hy</pre>
8
-
9
-
10
- h2. hydra:jetty Tasks
11
-
12
- h3. The main tasks: load, start, stop
13
-
14
- <pre>
15
- rake hydra:jetty:load # Copies the default SOLR config files and starts up the fedora instance.
16
- rake hydra:jetty:restart # Restarts the bundled Hydra Testing Server
17
- rake hydra:jetty:start # Starts the bundled Hydra Testing Server
18
- rake hydra:jetty:status # Returns the status of the Hydra::TestingServer.
19
- rake hydra:jetty:stop # Stops the bundled Hydra Testing Server
20
- </pre>
21
-
22
- h3. Subtasks: config, config_fedora, config_solr
23
-
24
- <pre>
25
- rake hydra:jetty:config # Copies the default Solr & Fedora configs into the bundled Hydra Testing Server
26
- rake hydra:jetty:config_fedora # Copies a custom fedora config for the bundled Hydra Testing Server
27
- rake hydra:jetty:config_solr # Copies the default SOLR config for the bundled Hydra Testing Server
28
- </pre>
29
-
30
- h2. hyhead Continuous Integration Tasks
31
-
32
- h3. hyhead Full Continuous Integration Build: ci
33
-
34
- <pre>
35
- rake hyhead:ci # Execute Continuous Integration build (docs, tests with coverage)
36
- </pre>
37
-
38
- h2. hyhead Test Host Setup: setup_test_host
39
-
40
- Many of the other tasks call this for you.
41
-
42
- <pre>
43
- rake hyhead:setup_test_host # Copy all of the necessary code into the test host
44
- </pre>
45
-
46
- h3. Subtasks for setting up test host
47
-
48
- These are the tasks used by setup_test_host
49
-
50
- <pre>
51
- rake hyhead:copy_plugin_to_host # Copy the current plugin code into hydra-plugin_test_host/vendor/plugins/hydra-head
52
- rake hyhead:remove_plugin_from_host # Remove hydra-plugin_test_host/vendor/plugins/hydra-head
53
- rake hyhead:copy_features_to_host # Copy current contents of the features directory into hydra-plugin_test_host/features
54
- rake hyhead:remove_features_from_host # Remove hydra-plugin_test_host/features
55
- rake hyhead:copy_fixtures_to_host # Copy current contents of the spec/fixtures directory into hydra-plugin_test_host/spec/fixtures
56
- rake hyhead:remove_fixtures_from_host # Remove hydra-plugin_test_host/spec/fixtures
57
- </pre>
58
-
59
- h2. hyhead RSpec Tasks
60
-
61
- h3. The main RSpec task: spec
62
-
63
- <pre>
64
- rake hyhead:spec # Easiest way to run rspec tests.
65
- </pre>
66
-
67
- This is the same as calling
68
-
69
- <pre>
70
- rake hyhead:rspec:setup_and_run # Sets up test host, loads fixtures, then runs specs - need to have jetty running.
71
- </pre>
72
-
73
- h4. Rspec subtasks
74
-
75
- To run the rspec tests without any setup, use
76
-
77
- <pre>
78
- rake hyhead:rspec:run # Run the hydra-head specs - need to have jetty running, test host set up and fixtures loaded.
79
- </pre>
80
-
81
- h2. hyhead Cucumber Tasks
82
-
83
- h3. The main Cucumber task: cucumber
84
-
85
- <pre>
86
- rake hyhead:cucumber # Easieset way to run cucumber tests.
87
- </pre>
88
-
89
- This is the same as calling
90
-
91
- <pre>
92
- rake hyhead:cucumber:setup_and_run # Sets up test host, loads fixtures, then runs cucumber features - need to have jetty running.
93
- </pre>
94
-
95
- h3. Cucumber subtasks
96
-
97
- To run the cucumber tests without any setup, use
98
-
99
- <pre>
100
- rake hyhead:cucumber:run # Run cucumber tests for hyhead - need to have jetty running, test host set up and fixtures loaded.
101
- </pre>
102
-
103
- h3. Generating RDocs
104
-
105
- <pre>
106
- rake hyhead:doc # Generate YARD Documentation
107
- </pre>
@@ -1,87 +0,0 @@
1
- h1. Tracking Plugins with Git Subtree
2
-
3
- We are now tracking all of the Hydra plugins in their own Git repositories. We are doing this with the git subtree tool. This allows each hydra head to have a full copy of each plugin in its working copy. When you want to commit plugin changes back to the shared plugin git repository, use the git subtree tool to "split" that plugin's code and commit log into its own branch, then merge your changes into the shared plugin repository.
4
-
5
- h2. Getting the git subtree tool
6
-
7
- You can checkout the git subtree tool from https://github.com/apenwarr/git-subtree
8
-
9
- The tool itself is just a single-file shell script that you need to install into where the rest of your git scripts are stored. See the "INSTALL instructions":https://github.com/apenwarr/git-subtree/blob/master/INSTALL
10
-
11
- Once you've got it installed, refer to "git-subtree.txt":https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt for details on how to use the script. For our purposes, you can mostly rely on the info below.
12
-
13
- h2. Using the git subtree tool
14
-
15
- Say I'm working on the HyHull project and I need to commit changes from my head back to the shared hydrangea_articles plugin
16
-
17
- First, add the hydrangea_articles git repository to your remote repositories
18
-
19
- <pre>
20
- git remote add articles-repo git@github.com:projecthydra/hydrangea_articles.git
21
- </pre>
22
-
23
- Then, use git subtree to split your copy of the plugin into a new branch in your local git repository. Include the name of your hydra head in the --annotate value. This will be appended to all of your commits.
24
-
25
- <pre>
26
- git subtree split --prefix=vendor/plugins/hydrangea_articles --annotate="(HyHull) " -b articles
27
- </pre>
28
-
29
- This will create a new branch called "articles"
30
-
31
- Now checkout your articles branch, rebase to the master branch of the shared plugin, and then push your changes to the shared plugin
32
-
33
- <pre>
34
- git checkout articles
35
- git rebase articles-repo/master
36
- git push articles-repo articles:master
37
- </pre>
38
-
39
- If you don't want to push your updates directly into the master branch of the shared plugin, push to a new remote branch with the name of the ticket you're working on and ask another committer to review your changes and/or apply them.
40
-
41
- <pre>
42
- git push articles-repo articles:my-ticket-number
43
- </pre>
44
-
45
- If you just want to share a replica of your copy of the plugin without rebasing, you can use git subtree push to post a copy of your work as a branch on the shared plugin's git repo:
46
-
47
- Ex:
48
- </pre>
49
- git subtree push --prefix=vendor/plugins/hydrangea_books --annotate="(HyHull) " -b HYHULL-219
50
- <pre>
51
-
52
- Complete example with shell outputs:
53
-
54
- In this example, I
55
-
56
- * split the plugin subtree into its own branch
57
- * checkout the new plugin branch
58
- * rebase the plugin branch against the plugin repository's master branch
59
- * push my updates into the plugin repository's master branch
60
-
61
- <pre>
62
- hydrangea matt$ git subtree split --prefix=vendor/plugins/hydrangea_datasets --annotate="(hydrangea) " -b datasets
63
- Created branch 'datasets'
64
- f2d9407ada9744f3b8bcabac83ddb1cd3fb47e28
65
-
66
- hydrangea matt$ git checkout datasets
67
- warning: unable to rmdir jetty: Directory not empty
68
- Checking out files: 100% (4723/4723), done.
69
- Switched to branch 'datasets'
70
-
71
- hydrangea matt$ git fetch datasets-remote
72
- From github.com:projecthydra/hydrangea_datasets
73
- * [new branch] master -> datasets-remote/master
74
-
75
- hydrangea matt$ git rebase datasets-remote/master
76
- First, rewinding head to replay your work on top of it...
77
- Applying: (hydrangea) fixing licenses in plugins
78
-
79
- hydrangea matt$ git push datasets datasets-remote:master
80
- Counting objects: 4, done.
81
- Delta compression using up to 2 threads.
82
- Compressing objects: 100% (3/3), done.
83
- Writing objects: 100% (3/3), 708 bytes, done.
84
- Total 3 (delta 1), reused 0 (delta 0)
85
- To git@github.com:projecthydra/hydrangea_datasets.git
86
- 656bf34..20ba2ba datasets -> master
87
- </pre>
data/README_TERSE.textile DELETED
@@ -1,92 +0,0 @@
1
- h2. Installation/Setup
2
-
3
- h3. (1) Grab the code
4
-
5
- <pre>
6
- git clone git@github.com:projecthydra/hydra-head.git
7
- </pre>
8
-
9
- h3. (2) Grab jetty and the test host application
10
-
11
- The git repository includes references to git submodules containing hydra-jetty and a sample Blacklight app that you can install the hydra-head plugin into.
12
-
13
- <pre>
14
- cd hydra-head
15
- git submodule init
16
- git submodule update
17
- bundle install
18
- </pre>
19
-
20
-
21
- h3. (3) IMPORTANT: Put a copy of the plugin into the host app
22
-
23
- *If you don't run this, you will not be able to run the test host app or its rake tasks*
24
-
25
- The host application needs a copy of the plugin in its vendor/plugins directory. We provide a rake task for this. The rake task will copy all of the plugin code into hydra-plugin_test_host/vendor/plugins
26
-
27
- <pre>
28
- rake hyhead:copy_to_host_plugins_dir
29
- </pre>
30
-
31
-
32
- h3. (4) Migrate the host app's databases
33
-
34
- <pre>
35
- cd hydra-plugin_test_host
36
- rake db:drop:all
37
- rake db:migrate
38
- rake db:migrate RAILS_ENV=test
39
- cd ..
40
- </pre>
41
-
42
- h2. Running the full Continuous Integration build
43
-
44
- _Stop any copies of jetty that you have running before running this._
45
-
46
- This will spin up jetty, import your fixtures into it run the tests, and stop jetty.
47
-
48
- <pre>
49
- rake hyhead:ci RAILS_ENV=test
50
- </pre>
51
-
52
- h2. Running the Tests Manually
53
-
54
- h3. Start Jetty and load the fixtures
55
-
56
- <pre>
57
- rake hydra:jetty:load RAILS_ENV=test
58
- rake hydra:default_fixtures:refresh environment=test
59
- </pre>
60
-
61
- h3. Run the RSpec Tests
62
-
63
- <pre>
64
- rake hyhead:spec
65
- </pre>
66
-
67
- OR
68
-
69
- <pre>
70
- rake hyhead:remove_from_host_plugins_dir
71
- rake hyhead:copy_to_host_plugins_dir
72
- rake hyhead:rspec
73
- </pre>
74
-
75
-
76
- h2. Running the App
77
-
78
- The test host app is a regular Rails app with Blacklight installed. Its configured with the assumption that the hydra-head plugin is installed into vendor/plugins/hydra-head.
79
-
80
- Before starting the app, make sure that you have the latest copy of the plugin code copied into its plugins directory.
81
-
82
- <pre>
83
- rake hyhead:remove_from_host_plugin
84
- rake hyhead:copy_to_host_plugins_dir
85
- </pre>
86
-
87
- After copying the plugin code, cd into the root of the test app and start it like you normally start any rails app.
88
-
89
- <pre>
90
- cd hydra-plugin_test_host
91
- script/server
92
- </pre>
@@ -1,8 +0,0 @@
1
- h2. 3.0.0
2
-
3
- If you have been testing out the Release Candidates, you need to add this line to your CatalogController:
4
-
5
- <pre>
6
- # This filters out objects that you want to exclude from search results. By default, it filters out FileAssets
7
- CatalogController.solr_search_params_logic << :exclude_unwanted_models
8
- </pre>
data/TESTING.textile DELETED
@@ -1,85 +0,0 @@
1
- h1. Directions to Clone and Test the Rails 3 hydra-head Code
2
-
3
- h2. For the Impatient
4
-
5
- # clone the hydra-head code (to a fresh working copy) <pre>git clone git@github.com:projecthydra/hydra-head.git</pre>
6
- # switch tot he hydra-head directory <pre>cd hydra-head</pre>
7
- # install bundler gem <pre>gem install bundler</pre>
8
- # Get the project dependencies <pre>bundle install</pre>
9
- # grab the jetty submodule <pre>git submodule init; git submodule update</pre>
10
- # test <pre>rake hyhead:ci</pre> This command:
11
- ## creates the test app in tmp/test_app
12
- ## spins up jetty (in jettywrapper)
13
- ## imports fixtures
14
- ## runs rspec & cucumber tests
15
- ## kills jetty (in jettywrapper)
16
-
17
- h2. More Detailed Instructions & Notes
18
-
19
- h3. The Hydra Jetty
20
-
21
- In order to test the gem during development, the hydra-jetty is included as a submodule to provide both a fedora and solr instance. Once you have cloned the github repository,
22
- run the following commands to load the jetty:
23
-
24
- <pre>
25
- git submodule init
26
- git submodule update
27
- </pre>
28
-
29
- To start the jetty:
30
-
31
- <pre>
32
- rake jetty:start
33
- </pre>
34
-
35
- Note: the first time you start the jetty, you must use the following command in order to properly configure the jetty:
36
-
37
- <pre>
38
- rake hydra:jetty:load
39
- </pre>
40
-
41
-
42
- h3. Testing the gem
43
-
44
- The specs and features for testing the gem within the context of a rails 3 app are all contained within the test_support directory. Once you have
45
- installed the test app, you will be able to run the specs/features from within that app via the provided rake tasks.
46
-
47
- A rake task is provided for setting up a rails 3 test app in the tmp/test_app directory. To generate the app, run:
48
-
49
- <pre>
50
- rake hyhead:setup_test_app
51
- </pre>
52
-
53
- Once you have done this and have a jetty running, you are ready to run the specs and cucumbers:
54
-
55
- <pre>
56
- rake hyhead:test
57
- </pre>
58
-
59
- This will run the specs and cucumber features from within the test application.
60
-
61
- In order to run a single spec or cucumber feature, use the following from the command line:
62
-
63
- <pre>
64
- export RAILS_ROOT="tmp/test_app"
65
- rspec test_support/spec/controllers/catalog_controller_spec.rb # path to the spec file you wish to run
66
- cucumber test_support/features/mods_asset_show.feature # path to the feature file you wish to run
67
- </pre>
68
-
69
- h2. Note about vendor/cache directory
70
-
71
- In order to more quickly install the required gems, the gems have been cached and are stored in the vendor/cache directory. Initially this was done to avoid the
72
- excessive amount of time bundler was taking to install all the gems and their dependencies. To get all the requisite gems, simply run:
73
-
74
- <pre>
75
- bundle install --local
76
- </pre>
77
-
78
- The cached gems also provide a quick means for generating a gemset for the test_app.
79
-
80
- When developing the hydra-head gem, be sure to commit changes to the vendor/cache directory when you update or install a new gem.
81
-
82
- h2. Note about solr and fedora config files
83
-
84
- When you change the solr and fedora config files, you must update them in the generator templates directory (lib/generators/hydra-head) as well as root of the hydra_head code.
85
-