Skip to content
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

DynamicField Database: Filter for DF doesn't work in AgentTicketFreeText (but works in AgentTicketPhone) #2165

Open
StefanAbel-OTOBO opened this issue Feb 13, 2023 · 2 comments
Labels
change A change in some part of the functionality of OTOBO, unfitting to other categories. question Further information is requested
Milestone

Comments

@StefanAbel-OTOBO
Copy link
Contributor

When having two DynamicField Database, you can use the first one to limit the results of the second one.

This works in AgentTicketPhone:
image

This doesn't work in AgentTicketFreeText, as you don't see any result (too much limitation):
image

If you remove the Filter for DynamicField Agent1 in the settings for Agent2, you see everything:
image

This is the configuration of the DynamicFields:
Agent1:
image

Agent2:
image

I had this on a customer's system and could reproduce it in 10.1.6

@StefanAbel-OTOBO StefanAbel-OTOBO added the bug Something isn't working as intended label Feb 13, 2023
@StefanAbel-OTOBO
Copy link
Contributor Author

ov147

stefanhaerter added a commit that referenced this issue Feb 27, 2023
…alue over saved one in non-creation ticket screens.
@stefanhaerter
Copy link
Contributor

TL;DR: The bug-causing behavior looks like to be implemented on purpose. Further discussion is needed before changing this.

I did some additional debugging to verify that my in #2198 proposed solution is valid. I found that the behavior actually appears to be on purpose, at least a little bit: If a ticket id is given, Kernel::System::DynamicFieldDB::DatabaseSearchByConfig() uses Kernel::System::DynamicField::Backend::ValueGet() 1 to retrieve the stored value of the given field for the ticket to perform its restrictions. In AgentTicketPhone, no ticket id exists yet, so the value given within the Params (and previously fetched by EditFieldValueGet()) is used. In AgentTicketFreeText, there exists a ticket id and even if the stored value is empty, it is used over the one given in the Params1.

This can easily be changed, but I would categorize this as a non-trivial design decision with at least a bit of impact, thus I would prefer discussing this with @svenoe and @bschmalhofer.

1

if (
$Key =~ m/^FieldFilter_(?:\d)$/
&& $Param{Config}->{PossibleValues}->{$Key}
&& $Param{TicketID}
)

stefanhaerter added a commit that referenced this issue Jan 26, 2024
…alue over saved one in non-creation ticket screens.
@svenoe svenoe modified the milestones: OTOBO 10.0.20, OTOBO 10.0.21 Mar 21, 2024
@svenoe svenoe modified the milestones: OTOBO 10.0.21, OTOBO 10.0.22 Apr 18, 2024
@stefanhaerter stefanhaerter added the question Further information is requested label Jul 4, 2024
@svenoe svenoe modified the milestones: OTOBO 10.0.22, OTOBO 10.0.23 Sep 25, 2024
@stefanhaerter stefanhaerter added change A change in some part of the functionality of OTOBO, unfitting to other categories. and removed bug Something isn't working as intended labels Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
change A change in some part of the functionality of OTOBO, unfitting to other categories. question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants