Stop triggering autocomplete for non-auto complete fields. Support data attribute based autocomplete types. #4449
Conversation
| } else if(type === 'linked') { | ||
| new LinkedData(element, url) | ||
| } else { | ||
| new Default(element, url) |
There was a problem hiding this comment.
Do not use 'new' for side effects no-new
| element, | ||
| url) | ||
| } else if(type === 'linked') { | ||
| new LinkedData(element, url) |
There was a problem hiding this comment.
Do not use 'new' for side effects no-new
| { excluding: exclude } | ||
| ) | ||
| } else if(type == 'resource' ) { | ||
| new Resource( |
There was a problem hiding this comment.
Do not use 'new' for side effects no-new
| url, | ||
| { excluding: exclude } | ||
| ) | ||
| } else if(type == 'resource' ) { |
There was a problem hiding this comment.
Expected '===' and instead saw '==' eqeqeq
| let type = element.data('autocomplete-type') | ||
| let exlude = element.data('exclude-work') | ||
| if(type === 'resource' && exclude.length > 0) { | ||
| new Resource( |
There was a problem hiding this comment.
Do not use 'new' for side effects no-new
orangewolf
force-pushed
the
autocomplete-by-type
branch
from
a7a1836
to
7c33e59
Compare
…ta attribute based autocomplete types. Moves to a new autocomplete type choosing system that uses data[autocomplete-type] to declaritively select the type instead of just keying of certain field names. Does not remove the existing functionality, but is a baby step toward depricating it.
orangewolf
force-pushed
the
autocomplete-by-type
branch
from
7c33e59
to
5cc3171
Compare
|
Is this something that should be added to the master branch as well? |
for future reference, our branching policy is to always merge fixes to the mainline before pushing them to maintenance branches. the only exception should be cases where the fix is no longer relevant on the mainline, but resolves a significant issue for the maintenance series. in other words: we should always be backporting, never forward-porting. this is to avoid complicated regression situations, where fixes released on maintenance branches aren't available on current releases. we should either:
|
|
@no-reply that's my bad, as I didn't know that we were only backporting. That's a bit of a lift, as I don't have anything local running against master at the moment, but I can take a swing at getting this done for master later today if no one else can tackle it. |
|
no worries! i'm delighted (and relieved) to have this fix in. we'll get the branch reconciled in short order. this might not have been the platonic ideal of the process, but it looks like the system working to me! |
…s from samvera/hyrax#4449. Restrict autocomplete changes to controlled vocabulary input fields.
Moves to a new autocomplete type choosing system that uses data[autocomplete-type] to declaritively select
the type instead of just keying of certain field names. Does not remove the existing functionality, but is
a baby step toward depricating it.
Fixes #3510 ; refs #99 (maybe?)
Guidance for testing, such as acceptance criteria or new user interface behaviors:
Here's a video that shows it happening on Hyku running on vanilla Hyrax 2.5.1 https://share.getcloudapp.com/d5uWdzZj (sorry about the fan noise my mac is prepping for launch)
app/views/records/edit_fields/_language.html.erbfile for example@samvera/hyrax-code-reviewers