-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug/57508 custom fields with format string text bool link and date dont forbid multi select internally and have handling in ordering #16570
Bug/57508 custom fields with format string text bool link and date dont forbid multi select internally and have handling in ordering #16570
Conversation
22a781e
to
629c79c
Compare
…don't forbid multi select internally and have handling in ordering https://community.openproject.org/work_packages/57508
…g, date, bool, link
…_open_versions? of CustomField
…t already checks for list format
…sible?, as it already checks for version format
… allow_non_open_versions unless allow_non_open_versions_possible?
629c79c
to
72bff94
Compare
From the looks of the commit that introduced it it looks like it was introduced to prevent the select being displayed for custom fields on TimeEntries. That was later on changed to also allow multi select for TimeEntry- and VersionCustomField. So I guess it is ok to remove the limitation as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice change here @toy.
I have one idea but feel free to ignore it. Good to merge in any case.
@@ -118,7 +118,7 @@ See COPYRIGHT and LICENSE files for more details. | |||
</fieldset> | |||
<% end %> | |||
|
|||
<% if @custom_field.new_record? || @custom_field.version? || @custom_field.allow_non_open_versions_possible? %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the cleanup in here. It was confusing before.
app/models/custom_field.rb
Outdated
|
||
def allow_non_open_versions? | ||
allow_non_open_versions | ||
%w[version user list].include?(field_format) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could also write it like this:
version? || user? || list?
which would be more in line with the implemenation of allow_non_open_versions_possible?
. But that is just an idea and not a necessity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also noticed it, but too quickly ignored probably thinking about efficiency, but version? || user? || list?
is also more explicit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made me wonder, also not important in this case, but it is not even slower:
require 'benchmark/ips'
class CustomField
attr_reader :field_format
def initialize(field_format)
@field_format = field_format
end
def list?
field_format == "list"
end
def version?
field_format == "version"
end
def user?
field_format == "user"
end
def multi_value_possible1?
%w[version user list].include?(field_format)
end
def multi_value_possible2?
version? || user? || list?
end
end
cfs = [
CustomField.new('version'),
CustomField.new('user'),
CustomField.new('list'),
CustomField.new('foobar'),
]
Benchmark.ips do |x|
x.report('include?') { cfs.each(&:multi_value_possible1?) }
x.report('x? || y? || z?') { cfs.each(&:multi_value_possible2?) }
x.compare!
end
gives
Warming up --------------------------------------
include? 173.006k i/100ms
x? || y? || z? 185.909k i/100ms
Calculating -------------------------------------
include? 1.731M (± 0.6%) i/s (577.81 ns/i) - 8.823M in 5.098375s
x? || y? || z? 1.851M (± 0.4%) i/s (540.34 ns/i) - 9.295M in 5.022755s
Comparison:
x? || y? || z?: 1850702.9 i/s
include?: 1730668.9 i/s - 1.07x slower
…in CustomField#multi_value_possible?
Ticket
OP#57508
What are you trying to accomplish?
Cleanup custom field ordering from unsupported cases, and check that multi_value (and allow_non_open_versions) are not assignable on model level and not only on UI level.
Merge checklist