curation_concerns 1.7.2 → 1.7.3

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: d15b59d55d78440e70e6f40b0c0892065436ea41
4
- data.tar.gz: c3d817c1978120de064a838441a8c40c668ce3e1
3
+ metadata.gz: b8e3a51d73c77e6ee4533319b2e0dbc7b8afed1c
4
+ data.tar.gz: c1cb7a95bc11873894ec02b198c0925db1e1ff27
5
5
  SHA512:
6
- metadata.gz: d14c0baaf6373a14d4ba6b14343cdb81e2f0e93342f835fe6bb029a56087dcf04f43f8b822241737ef2dc66256c989c86a0b985d6e9a0c02c4f64275371ecefb
7
- data.tar.gz: a280ccee709f04466a253c04106195fab1d9c8d014c14bf6aa6cf84bce359e44ab09d441b6849b4c61c08853feac88b0e345e95d0e1e781ab6577f590cf8cc9c
6
+ metadata.gz: 7617b194446b007e5b23f6f58d9f5ba08f57f6bf26a46b07264141688c751aec136adf36a409f52d73b87280c24e012652cbb94798ff613938edffb1b420c33d
7
+ data.tar.gz: e542b1d43ab5205cd042a4fa6c7398a7bcbfd2956c7fbd92a092d3ef3fcec932b40503bc6e9122125080e2ecd34595ccf1d85e5117a37f9f9388edd9a295e50f
data/CONTRIBUTING.md CHANGED
@@ -3,6 +3,13 @@
3
3
  We want your help to make Project Hydra great.
4
4
  There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
5
5
 
6
+ ## Code of Conduct
7
+
8
+ The Hydra community is dedicated to providing a welcoming and positive experience for all its
9
+ members, whether they are at a formal gathering, in a social setting, or taking part in activities
10
+ online. Please see our [Code of Conduct](https://wiki.duraspace.org/display/hydra/Code+of+Conduct)
11
+ for more information.
12
+
6
13
  ## Hydra Project Intellectual Property Licensing and Ownership
7
14
 
8
15
  All code contributors must have an Individual Contributor License Agreement (iCLA) on file with the Hydra Project Steering Group.
@@ -10,12 +17,16 @@ If the contributor works for an institution, the institution must have a Corpora
10
17
 
11
18
  https://wiki.duraspace.org/display/hydra/Hydra+Project+Intellectual+Property+Licensing+and+Ownership
12
19
 
20
+ You should also add yourself to the `CONTRIBUTORS.md` file in the root of the project.
21
+
13
22
  ## Contribution Tasks
14
23
 
15
24
  * Reporting Issues
16
25
  * Making Changes
26
+ * Documenting Code
27
+ * Committing Changes
17
28
  * Submitting Changes
18
- * Merging Changes
29
+ * Reviewing and Merging Changes
19
30
 
20
31
  ### Reporting Issues
21
32
 
@@ -36,8 +47,28 @@ https://wiki.duraspace.org/display/hydra/Hydra+Project+Intellectual+Property+Lic
36
47
  * Then checkout the new branch with `git checkout fix/master/my_contribution`.
37
48
  * Please avoid working directly on the `master` branch.
38
49
  * You may find the [hub suite of commands](https://github.com/defunkt/hub) helpful
50
+ * Make sure you have added sufficient tests and documentation for your changes.
51
+ * Test functionality with RSpec; est features / UI with Capybara.
52
+ * Run _all_ the tests to assure nothing else was accidentally broken.
53
+
54
+ ### Documenting Code
55
+
56
+ * All new public methods, modules, and classes should include inline documentation in [YARD](http://yardoc.org/).
57
+ * Documentation should seek to answer the question "why does this code exist?"
58
+ * Document private / protected methods as desired.
59
+ * If you are working in a file with no prior documentation, do try to document as you gain understanding of the code.
60
+ * If you don't know exactly what a bit of code does, it is extra likely that it needs to be documented. Take a stab at it and ask for feedback in your pull request. You can use the 'blame' button on GitHub to identify the original developer of the code and @mention them in your comment.
61
+ * This work greatly increases the usability of the code base and supports the on-ramping of new committers.
62
+ * We will all be understanding of one another's time constraints in this area.
63
+ * YARD examples:
64
+ * [Hydra::Works::RemoveGenericFile](https://github.com/projecthydra-labs/hydra-works/blob/master/lib/hydra/works/services/generic_work/remove_generic_file.rb)
65
+ * [ActiveTriples::LocalName::Minter](https://github.com/ActiveTriples/active_triples-local_name/blob/master/lib/active_triples/local_name/minter.rb)
66
+ * [Getting started with YARD](http://www.rubydoc.info/gems/yard/file/docs/GettingStarted.md)
67
+
68
+ ### Committing changes
69
+
39
70
  * Make commits of logical units.
40
- * Your commit should include a high level description of your work in HISTORY.textile
71
+ * Your commit should include a high level description of your work in HISTORY.textile
41
72
  * Check for unnecessary whitespace with `git diff --check` before committing.
42
73
  * Make sure your commit messages are [well formed](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
43
74
  * If you created an issue, you can close it by including "Closes #issue" in your commit message. See [Github's blog post for more details](https://github.com/blog/1386-closing-issues-via-commit-messages)
@@ -58,7 +89,9 @@ https://wiki.duraspace.org/display/hydra/Hydra+Project+Intellectual+Property+Lic
58
89
 
59
90
  class PostsController
60
91
  def index
61
- respond_with Post.limit(10)
92
+ respond_to do |wants|
93
+ wants.html { render 'index' }
94
+ end
62
95
  end
63
96
  end
64
97
 
@@ -70,38 +103,53 @@ https://wiki.duraspace.org/display/hydra/Hydra+Project+Intellectual+Property+Lic
70
103
  long to fit in 72 characters
71
104
  ```
72
105
 
73
- * Make sure you have added the necessary tests for your changes.
74
- * Run _all_ the tests to assure nothing else was accidentally broken.
75
- * When you are ready to submit a pull request
76
-
77
106
  ### Submitting Changes
78
107
 
79
- [Detailed Walkthrough of One Pull Request per Commit](http://ndlib.github.io/practices/one-commit-per-pull-request/)
80
-
81
108
  * Read the article ["Using Pull Requests"](https://help.github.com/articles/using-pull-requests) on GitHub.
82
109
  * Make sure your branch is up to date with its parent branch (i.e. master)
83
110
  * `git checkout master`
84
111
  * `git pull --rebase`
85
112
  * `git checkout <your-branch>`
86
113
  * `git rebase master`
87
- * It is likely a good idea to run your tests again.
88
- * Squash the commits for your branch into one commit
89
- * `git rebase --interactive HEAD~<number-of-commits>` ([See Github help](https://help.github.com/articles/interactive-rebase))
90
- * To determine the number of commits on your branch: `git log master..<your-branch> --oneline | wc -l`
114
+ * It is a good idea to run your tests again.
115
+ * If you've made more than one commit take a moment to consider whether squashing commits together would help improve their logical grouping.
116
+ * [Detailed Walkthrough of One Pull Request per Commit](http://ndlib.github.io/practices/one-commit-per-pull-request/)
117
+ * `git rebase --interactive master` ([See Github help](https://help.github.com/articles/interactive-rebase))
91
118
  * Squashing your branch's changes into one commit is "good form" and helps the person merging your request to see everything that is going on.
92
119
  * Push your changes to a topic branch in your fork of the repository.
93
120
  * Submit a pull request from your fork to the project.
94
121
 
95
- ### Merging Changes
122
+ ### Reviewing and Merging Changes
123
+
124
+ We adopted [Github's Pull Request Review](https://help.github.com/articles/about-pull-request-reviews/) for our repositories.
125
+ Common checks that may occur in our repositories:
126
+
127
+ 1. Travis CI - where our automated tests are running
128
+ 2. Hound CI - where we check for style violations
129
+ 3. Approval Required - Github enforces at least one person approve a pull request. Also, all reviewers that have chimed in must approve.
130
+ 4. CodeClimate - is our code remaining healthy (at least according to static code analysis)
131
+
132
+ If one or more of the required checks failed (or are incomplete), the code should not be merged (and the UI will not allow it). If all of the checks have passed, then anyone on the project (including the pull request submitter) may merge the code.
133
+
134
+ *Example: Carolyn submits a pull request, Justin reviews the pull request and approves. However, Justin is still waiting on other checks (Travis CI is usually the culprit), so he does not merge the pull request. Eventually, all of the checks pass. At this point, Carolyn or anyone else may merge the pull request.*
135
+
136
+ #### Things to Consider When Reviewing
137
+
138
+ First, the person contributing the code is putting themselves out there. Be mindful of what you say in a review.
139
+
140
+ * Ask clarifying questions
141
+ * State your understanding and expectations
142
+ * Provide example code or alternate solutions, and explain why
143
+
144
+ This is your chance for a mentoring moment of another developer. Take time to give an honest and thorough review of what has changed. Things to consider:
96
145
 
97
- * It is considered "poor from" to merge your own request.
98
- * Please take the time to review the changes and get a sense of what is being changed. Things to consider:
99
146
  * Does the commit message explain what is going on?
100
- * Does the code changes have tests? _Not all changes need new tests, some changes are refactorings_
147
+ * Does the code changes have tests? _Not all changes need new tests, some changes are refactors_
148
+ * Do new or changed methods, modules, and classes have documentation?
101
149
  * Does the commit contain more than it should? Are two separate concerns being addressed in one commit?
102
- * Did the Travis tests complete successfully?
103
- * If you are uncertain, bring other contributors into the conversation by creating a comment that includes their @username.
104
- * If you like the pull request, but want others to chime in, create a +1 comment and tag a user.
150
+ * Does the description of the new/changed specs match your understanding of what the spec is doing?
151
+
152
+ If you are uncertain, bring other contributors into the conversation by assigning them as a reviewer.
105
153
 
106
154
  # Additional Resources
107
155
 
@@ -22,8 +22,11 @@ module CurationConcerns
22
22
  # remove from old collections
23
23
  (curation_concern.in_collection_ids - new_collection_ids).each do |old_id|
24
24
  collection = ::Collection.find(old_id)
25
- collection.members.delete(curation_concern)
26
- collection.save
25
+ # don't remove from collections current user doesn't have edit permissions for
26
+ if collection.edit_users.include? user.email
27
+ collection.members.delete(curation_concern)
28
+ collection.save
29
+ end
27
30
  end
28
31
 
29
32
  # add to new
@@ -40,6 +40,12 @@ module CurationConcerns
40
40
  # that files are in a LDP basic container, and thus, included in the asset's uri.
41
41
  def authorize_download!
42
42
  authorize! :read, params[asset_param_key]
43
+ rescue CanCan::AccessDenied
44
+ redirect_to default_image
45
+ end
46
+
47
+ def default_image
48
+ ActionController::Base.helpers.image_path 'default.png'
43
49
  end
44
50
 
45
51
  # Overrides Hydra::Controller::DownloadBehavior#load_file, which is hard-coded to assume files are in BasicContainer.
@@ -130,6 +130,7 @@ module CurationConcerns
130
130
  def ordered_ids
131
131
  @ordered_ids ||= begin
132
132
  ActiveFedora::SolrService.query("proxy_in_ssi:#{id}",
133
+ rows: 10_000,
133
134
  fl: "ordered_targets_ssim")
134
135
  .flat_map { |x| x.fetch("ordered_targets_ssim", []) }
135
136
  end
@@ -137,9 +138,11 @@ module CurationConcerns
137
138
 
138
139
  # These are the file sets that belong to this work, but not necessarily
139
140
  # in order.
141
+ # Arbitrarily maxed at 10 thousand; had to specify rows due to solr's default of 10
140
142
  def file_set_ids
141
143
  @file_set_ids ||= begin
142
144
  ActiveFedora::SolrService.query("{!field f=has_model_ssim}FileSet",
145
+ rows: 10_000,
143
146
  fl: ActiveFedora.id_field,
144
147
  fq: "{!join from=ordered_targets_ssim to=id}id:\"#{id}/list_source\"")
145
148
  .flat_map { |x| x.fetch(ActiveFedora.id_field, []) }
@@ -1,3 +1,3 @@
1
1
  module CurationConcerns
2
- VERSION = '1.7.2'.freeze
2
+ VERSION = '1.7.3'.freeze
3
3
  end
@@ -3,6 +3,9 @@ describe CurationConcerns::Actors::AddToCollectionActor do
3
3
  let(:user) { create(:user) }
4
4
  let(:curation_concern) { GenericWork.new }
5
5
  let(:attributes) { {} }
6
+ let(:collection) { create(:collection).tap do |col|
7
+ col.apply_depositor_metadata user
8
+ end }
6
9
  subject do
7
10
  CurationConcerns::Actors::ActorStack.new(curation_concern,
8
11
  user,
@@ -26,7 +29,6 @@ describe CurationConcerns::Actors::AddToCollectionActor do
26
29
  end
27
30
 
28
31
  describe 'create' do
29
- let(:collection) { create(:collection) }
30
32
  let(:attributes) do
31
33
  { collection_ids: [collection.id], title: ['test'] }
32
34
  end
@@ -35,5 +37,30 @@ describe CurationConcerns::Actors::AddToCollectionActor do
35
37
  expect(subject.create(attributes)).to be true
36
38
  expect(collection.reload.members).to eq [curation_concern]
37
39
  end
40
+
41
+ describe "when work is in user's own collection" do
42
+ it "removes the work from that collection" do
43
+ # had to move collection and subject down into the spec to ensure they use the same user
44
+ collection = create(:collection).tap do |col|
45
+ col.apply_depositor_metadata user
46
+ end
47
+ subject.create(attributes)
48
+ expect(subject.create(collection_ids: [])).to be true
49
+ expect(collection.reload.members).to eq []
50
+ end
51
+ end
52
+
53
+ describe "when work is in another user's collection" do
54
+ let(:other_user) { create(:user) }
55
+ before do
56
+ collection.apply_depositor_metadata other_user
57
+ subject.create(attributes)
58
+ end
59
+
60
+ it "doesn't remove the work from that collection" do
61
+ expect(subject.create(collection_ids: [])).to be true
62
+ expect(collection.reload.members).to eq [curation_concern]
63
+ end
64
+ end
38
65
  end
39
66
  end
@@ -6,6 +6,7 @@ describe DownloadsController do
6
6
  let(:file_set) do
7
7
  FactoryGirl.create(:file_with_work, user: user, content: File.open(fixture_file_path('files/image.png')))
8
8
  end
9
+ let(:default_image) { ActionController::Base.helpers.image_path 'default.png' }
9
10
  it 'calls render_404 if the object does not exist' do
10
11
  expect(controller).to receive(:render_404) { controller.render body: nil }
11
12
  get :show, params: { id: '8675309' }
@@ -15,18 +16,16 @@ describe DownloadsController do
15
16
  let(:another_user) { FactoryGirl.create(:user) }
16
17
  before { sign_in another_user }
17
18
 
18
- it 'redirects to root' do
19
+ it 'redirects to the default image' do
19
20
  get :show, params: { id: file_set.to_param }
20
- expect(response).to redirect_to root_path
21
- expect(flash['alert']).to eq 'You are not authorized to access this page.'
21
+ expect(response).to redirect_to default_image
22
22
  end
23
23
  end
24
24
 
25
25
  context "when user isn't logged in" do
26
- it 'redirects to sign in' do
26
+ it 'redirects to the default image' do
27
27
  get :show, params: { id: file_set.to_param }
28
- expect(response).to redirect_to new_user_session_path
29
- expect(flash['alert']).to eq 'You are not authorized to access this page.'
28
+ expect(response).to redirect_to default_image
30
29
  end
31
30
 
32
31
  it 'authorizes the resource using only the id' do
@@ -81,6 +81,16 @@ describe CurationConcerns::WorkShowPresenter do
81
81
  expect(presenter.file_set_presenters.map(&:id)).to eq obj.ordered_member_ids
82
82
  end
83
83
 
84
+ context "solr query" do
85
+ before do
86
+ expect(ActiveFedora::SolrService).to receive(:query).twice.with(anything, hash_including(rows: 10_000)).and_return([])
87
+ end
88
+
89
+ it "requests >10 rows" do
90
+ presenter.file_set_presenters
91
+ end
92
+ end
93
+
84
94
  context "when some of the members are not file sets" do
85
95
  let(:another_work) { create(:work) }
86
96
  before do
@@ -165,12 +165,18 @@ module CurationConcerns
165
165
  subject { described_class.scope_processing_agents_for(user: nil) }
166
166
  it { is_expected.to eq([]) }
167
167
  end
168
+
168
169
  context 'when user is persisted' do
169
170
  let(:user) { create(:user) }
171
+ before do
172
+ allow(user).to receive(:groups).and_return(['librarians'])
173
+ end
174
+
170
175
  subject { described_class.scope_processing_agents_for(user: user) }
176
+
171
177
  it 'will equal [kind_of(Sipity::Agent)]' do
172
178
  is_expected.to contain_exactly(PowerConverter.convert_to_sipity_agent(user),
173
- PowerConverter.convert_to_sipity_agent(Group.new('registered')))
179
+ PowerConverter.convert_to_sipity_agent(Group.new('librarians')))
174
180
  end
175
181
  end
176
182
  end
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: curation_concerns
3
3
  version: !ruby/object:Gem::Version
4
- version: 1.7.2
4
+ version: 1.7.3
5
5
  platform: ruby
6
6
  authors:
7
7
  - Matt Zumwalt
@@ -10,7 +10,7 @@ authors:
10
10
  autorequire:
11
11
  bindir: bin
12
12
  cert_chain: []
13
- date: 2017-01-10 00:00:00.000000000 Z
13
+ date: 2017-02-03 00:00:00.000000000 Z
14
14
  dependencies:
15
15
  - !ruby/object:Gem::Dependency
16
16
  name: hydra-head
@@ -1591,7 +1591,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
1591
1591
  version: '0'
1592
1592
  requirements: []
1593
1593
  rubyforge_project:
1594
- rubygems_version: 2.5.1
1594
+ rubygems_version: 2.5.2
1595
1595
  signing_key:
1596
1596
  specification_version: 4
1597
1597
  summary: A Rails Engine that allows an application to CRUD CurationConcern objects