This repository has been archived by the owner on Apr 14, 2023. It is now read-only.
beforeField and afterField relations do not work with equalTo or Whitelists #1489
Comments
pdaulbyscottlogic
added this to the Allow field values to depend on multiple other field values milestone
pdaulbyscottlogic
changed the title
willsalt-sl
added
bug
This was referenced Nov 18, 2019
cdowding-sl
added
bug
r-stuart
pushed a commit
that referenced
this issue
Dec 2, 2019
Partial fix for the ticket #1489. This fixes the equal to case, but doesn't address the before or after cases. The reason for a partial fix is due to the difficulty comparing the two different cases (equal vs before/after). Equal to is simple because all of the values can be adjusted by the offset, translating a set of values to a set of values. Before/after are more complicated, as theoretically each of the values must be translated to a range. This therefore means the result is a set of restrictions. Unfortunately, the system isn't designed to be passing around a set of restrictions at this time in the program. Therefore, this will take further thought. A possible solution is to take the most restrictive of the values. This would ensure that whichever values are picked are permissable, but would severely limit the number of values output.
r-stuart
pushed a commit
that referenced
this issue
Dec 2, 2019
Partial fix for the ticket #1489. This fixes the equal to case, but doesn't address the before or after cases. The reason for a partial fix is due to the difficulty comparing the two different cases (equal vs before/after). Equal to is simple because all of the values can be adjusted by the offset, translating a set of values to a set of values. Before/after are more complicated, as theoretically each of the values must be translated to a range. This therefore means the result is a set of restrictions. Unfortunately, the system isn't designed to be passing around a set of restrictions at this time in the program. Therefore, this will take further thought. A possible solution is to take the most restrictive of the values. This would ensure that whichever values are picked are permissable, but would severely limit the number of values output.
r-stuart
pushed a commit
that referenced
this issue
Dec 3, 2019
Partial fix for the ticket #1489. This fixes the equal to case, but doesn't address the before or after cases. The reason for a partial fix is due to the difficulty comparing the two different cases (equal vs before/after). Equal to is simple because all of the values can be adjusted by the offset, translating a set of values to a set of values. Before/after are more complicated, as theoretically each of the values must be translated to a range. This therefore means the result is a set of restrictions. Unfortunately, the system isn't designed to be passing around a set of restrictions at this time in the program. Therefore, this will take further thought. A possible solution is to take the most restrictive of the values. This would ensure that whichever values are picked are permissable, but would severely limit the number of values output.
r-stuart
pushed a commit
that referenced
this issue
Dec 3, 2019
Partial fix for the ticket #1489. This fixes the equal to case, but doesn't address the before or after cases. The reason for a partial fix is due to the difficulty comparing the two different cases (equal vs before/after). Equal to is simple because all of the values can be adjusted by the offset, translating a set of values to a set of values. Before/after are more complicated, as theoretically each of the values must be translated to a range. This therefore means the result is a set of restrictions. Unfortunately, the system isn't designed to be passing around a set of restrictions at this time in the program. Therefore, this will take further thought. A possible solution is to take the most restrictive of the values. This would ensure that whichever values are picked are permissable, but would severely limit the number of values output.
r-stuart
pushed a commit
that referenced
this issue
Dec 3, 2019
Partial fix for the ticket #1489. This fixes the equal to case, but doesn't address the before or after cases. The reason for a partial fix is due to the difficulty comparing the two different cases (equal vs before/after). Equal to is simple because all of the values can be adjusted by the offset, translating a set of values to a set of values. Before/after are more complicated, as theoretically each of the values must be translated to a range. This therefore means the result is a set of restrictions. Unfortunately, the system isn't designed to be passing around a set of restrictions at this time in the program. Therefore, this will take further thought. A possible solution is to take the most restrictive of the values. This would ensure that whichever values are picked are permissable, but would severely limit the number of values output.
r-stuart
added a commit
that referenced
this issue
Dec 3, 2019
fix(#1489): Fix equal to offset for whitelist
|
@d-withers could you check to see if this is still an issue - if not can you close it off please. |
ghost
assigned 
|
Confirmed this is still an issue -- there is a hardcoded error tagging this bug when attempting this (java.lang.UnsupportedOperationException: cannot combine sets with before/after relation, Issue #1489). Looks like the equalToOffset case was fixed in #1571 but the before/after cases were not. I'll update the ticket description. |
d-withers
changed the title
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bug Report
When attempting to use a beforeField or afterField relation on fields with inSet constraints the following error is returned:
java.lang.UnsupportedOperationException: cannot combine sets with <before|after> relation, Issue #1489Some discussion of this from #1571 repeated below:
The text was updated successfully, but these errors were encountered: