samvera / hydra-editor Goto Github PK

It looks funny

it should be form-horizontal

https://github.com/projecthydra-labs/hydra-editor/blob/e9cebe3c6a5a3ca9d12aa77e5eab879226eaffab/app/views/records/_form.html.erb#L1

https://travis-ci.org/projecthydra/hydra-editor/jobs/80890598

Due to sass/sass#1656

Cleaning params using HydraEditor::Form#model_attributes doesn't clean single-value params containing empty strings. This is related to samvera-deprecated/sufia#941

Derived from samvera/maintenance#17

If I have a record where some of the terms_for_editing are empty
And I edit the record, but do not enter values for the empty fields
Then hydra-editor creates an empty string values for those fields.

E.g., just showing the empty fields,

1.9.3-p327 :001 > item = Item.find('duke:3')
 => #<Item pid:"duke:3", contributor:[], coverage:[], language:[], publisher:[], relation:[], rights:[], source:[], subject:[]> 

[item edited with hydra-editor w/o changing data]

1.9.3-p327 :002 > item = Item.find('duke:3')
 => #<Item pid:"duke:3", contributor:[""], coverage:[""], language:[""], publisher:[""], relation:[""], rights:[""], source:[""], subject:[""]> 

IMO this is undesirable b/c it actually changes the object datastream, even if no changes were submitted.

First, I would like some agreement on the idea that hydra-editor should not do this -- that is, specifically, not set an empty string value on a field that is empty.

If there is agreement on that principle, I can work up a PR to address it.

https://github.com/projecthydra-labs/hydra-editor/blob/1cfd52104a5bd375e5cdd87a1deba05de4fa6131/app/forms/hydra_editor/form.rb#L53

When you add another, you want to type into the newly created field (at the bottom) and then click the button next to it to add the next one. But that is a remove button, not an add button.

I think the way curate does it is better

Please see the maintenance policy for Ruby on Rails for further information regarding which releases of Rails are still supported by the community.

Rails version 6.0.0 was released on 08/16/2019, and in accordance with the charter of the current phase of the Component Maintenance Working Group, the CircleCI configuration for this should be updated.

Derived from samvera/maintenance#89

This would definitely require some breaking changes in Controller behavior. Essentially, one would need more than the ID of the resource in order to query the proper table in https://github.com/samvera/hydra-editor/blob/master/lib/hydra_editor/controller_resource.rb#L3. This provides the resource for CanCan authorization, and there are tests which make it evident that no errors are thrown when the Class of the resource is not supplied in the HTTP request parameters: https://github.com/samvera/hydra-editor/blob/master/spec/controllers/records_controller_spec.rb#L132

These requests would need to fail unless the type parameter were provided so that https://github.com/samvera/hydra-editor/blob/master/lib/hydra_editor/controller_resource.rb#L8 will resolve.

I can make a PR after I figure out how to make the existing tests pass ...

Descriptive summary

This repository’s default branch has already been renamed to main using GitHub’s renaming tool. In order to preserve automatic redirection of links that reference the old branch name master to the new default main branch, a branch with the old name should not be recreated.

CircleCI can be used to prevent the recreation of the old default branch name by preventing PRs with a branch named master from being merged by causing a test failure during continuous integration.

Rationale

Git's default "master" branch derives from "master/slave" jargon which perpetuates systemic racist language and systems (see email Replacing "master" reference in git branch names). To uphold our Code of Conduct, we must move away from the term "master" in our technical language (as well as words like blacklist or whitelist).

Expected behavior

If a PR is submitted with a branch named master, the continuous integration tests should fail.

Actual behavior

If a PR is submitted with a branch named master, the continuous integration tests will not fail because of the branch name.

Related work

Background on the renaming effort is available in the working group notes.

Per https://wiki.duraspace.org/display/hydra/Code+Copyright+Statement.

The hydra-editor should be usable by someone not using the hydra gem (if they need an advanced copy of active-record for example).

This was proposed by @tpendragon, and perhaps calls to the Gem (such as what is found on https://github.com/samvera/hydra-editor/blob/master/lib/hydra_editor/controller_resource.rb#L3) could be removed for a future minor release.

When precompiling assets for production use, the task fails with

Sass::SyntaxError: Undefined variable: "$border-radius-base".

Because the generator for Blacklight is not Rails 4 compatible. It makes versioned migrations which Rails 4 doesn't understand.

bootstrap_form 2.1.1

https://github.com/projecthydra-labs/hydra-editor/blob/31fced70fd5919e377ca26223edcd1f54c091f01/app/views/records/choose_type.html.erb#L2

This may fix it:

bootstrap_form_tag url: hydra_editor.new_record_path, method: :get

Derived from samvera/maintenance#76

There are changes in https://github.com/samvera/hydra-editor/tree/3-3-stable which may require a new release.

Please see https://github.com/samvera-labs/bixby for reference.

This should follow the conventions proposed by https://keepachangelog.com/en/1.0.0/

https://github.com/projecthydra-labs/hydra-editor/blob/108b4a2749ed26e195bc5de2b7c53200188309e2/app/views/records/edit_fields/_default.html.erb#L1

Otherwise it won't stretch full width.

Derived from samvera/maintenance#77

the bootstrap_forms gems merged with another gem to become:
https://github.com/bootstrap-ruby/rails-bootstrap-forms

The callback for managed_field:add is triggered early, and seems like it should happen after the children elements have been appended.

Move: https://github.com/samvera/hydra-editor/blob/master/app/assets/javascripts/hydra-editor/field_manager.es6#L117

after the append:
https://github.com/samvera/hydra-editor/blob/master/app/assets/javascripts/hydra-editor/field_manager.es6#L99

Using a service such as Coveralls, integrate code coverage analysis to ensure 100% coverage

If you have many types of objects, with common properties, it's nice that they can share partials in app/views/records of course hydra-editor should still use a more specific view if it is available.

Here is the warning:

DEPRECATION WARNING: Rendering view from `records/edit_fields/displays`. Move to tufts_audios/edit_fields/displays. This will be removed in 1.0.0. (called from render_edit_field_partial at /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/hydra-editor-0.3.0/app/helpers/concerns/records_helper_behavior.rb:27)

When keyboard user actives 'add' button, focus resets and you have to tab through the whole page again. It should go directly to the newly-added field so that the new data can be input. Another good option would be for it to stay on the button that was just activated.

Ruby 2.7.0 was released on 12/25/2019, and in accordance with the charter of the current phase of the Component Maintenance Working Group, the CircleCI configuration for this should be updated.

Waffle.io is scheduled to be shut down by May 16th: https://waffle.io/

Descriptive summary

In Sufia 7.0.0, the bootlinter found the following errors:

1. Found elements with a .glyphicon-* class that were missing the additional required .glyphicon class.
   1. i.icon-white.glyphicon-plus (15)
   2. <i> element should be <span>
   3. https://github.com/twbs/bootlint/wiki/E030

Related work

#2365 #2357 #2004 #2005

The releases listing shows a v2.5.2, but it hasn't propagated to the rubygems version listings.

Derived from samvera/maintenance#16

I've got a vanilla Sufia install that I'm running under RAILS_ENV=production, and when I run the assets:precompile task, I see the following error:

mjg@beacon:~/workspace/druw (master[2.1.5@druw]⚡ )$ RAILS_ENV=production rake --trace assets:precompile
** Invoke assets:precompile (first_time)
** Invoke assets:environment (first_time)
** Execute assets:environment
** Invoke environment (first_time)
** Execute environment
** Execute assets:precompile
rake aborted!
Sass::SyntaxError: Undefined variable: "$border-radius-base".
  (in /home/mjg/.rvm/gems/ruby-2.1.5@druw/gems/hydra-editor-1.0.0.rc2/app/assets/stylesheets/hydra-editor/multi_value_fields.scss:35)
/home/mjg/.rvm/gems/ruby-2.1.5@druw/gems/hydra-editor-1.0.0.rc2/app/assets/stylesheets/hydra-editor/multi_value_fields.scss:35

I see that this variable is declared in bootstrap-sass 3.3.1.0 in assets/stylesheets/bootstrap/_variables.scss, and this version of bootstrap-sass is in my bundle, FWIW.

Beginning with v3.5.1, Simple Form now requires models passed to it to conform to the ActiveModel interface; particularly, they must implement #to_model. #138 pins the dependency to avoid unexpected breakage in downstream apps.

Support for v3.5.1 and up should be re-added (this may just require testing/documentation fixes) and a major version released to get us back to tracking current simple_form development.

https://github.com/projecthydra-labs/hydra-editor/blob/master/app/assets/javascripts/hydra-editor/manage_repeating_fields.js#L59

it's checking if any child input is empty. If the input is a _destroy field. We want it empty.

See samvera/hyrax#2296.

HydraEditor::Form.model_attributes cleans term values by removing empty strings, but this only works for multi-valued terms. Single-valued (multiple: false) terms should have empty string value '' replaced with nil.

Currently uses hydra-head + blacklight.

https://github.com/projecthydra/hydra-head/blob/f3da6a134e61b64e79d229d124de4e49cb686831/hydra-core/app/controllers/concerns/hydra/controller/controller_behavior.rb#L31

Perhaps we need to override deny_access on the RecordsController?

1.0.0.beta1 lets you hit a + and - button to add/remove values via javascript. The new form doesn't let you.

simple_form_for(foo), url: 'example.org' do |f|
  f.input :bar, as: :multi_value
end
# This will throw an error if Foo#bar exists, but bar is not an attribute on Foo.

Done when: you can create a MultiValueInput for the values from an an object's method (not just an attribute).

Our use case:

• We have a custom input that extends MultiValueInput (similar to inputs in Hyrax).
• We need to rearrange some of the object's terms into a different structure that is then passed to our custom input. We use an instance method to do this, but MultiValueInput currently only pays attention to attributes, not instance methods.

https://travis-ci.org/projecthydra/hydra-editor/builds/17023017

I re-ran the build of master b/c I was having trouble sorting the test issues on #28.

build_permitted_params should check to see if the term is a property before calling obj.multiple?(term) otherwise if the term is a method and not a property it will raise UnknownAttributeError. i.e.:

ActiveFedora::UnknownAttributeError: Collection does not have an attribute `visibility'

I'm not sure if it affects users in any tangible way, but right now adding multiple fields results in them all having the same ID. This will make testing a bit more painful, and I don't really know the ramifications of violating the HTML spec. id is supposed to be unique, but beyond testing I'm not sure if there are any actual problems.

In any case, if it's easy enough I'll try to throw together a PR to fix it, and if not, it's probably worth noting at least.

The ENTER key effectively clicks the nearest button, rather than submitting the form. The nearest button may be "add" or "remove" depending if you're on the last item in a list.

For long forms, and/or people who prefer (or require) the keyboard, submitting the form is a bit annoying, and may result in accidental data deletion when hitting ENTER on a field. The default behavior of an HTML form is that hitting ENTER within most fields will submit the form.

Possibly relevant: http://stackoverflow.com/questions/8294465/making-enter-key-on-an-html-form-submit-instead-of-activating-button