Issue with Custom Conditions

vindelico

Hello Dev14,

I am running into the same issue.
Can you point me to where/how you did that manual editing and once you do it will it be permanent, i.e. will it override the setting of the condition through the interface?

Thanks, M.

Tinnitus

KevinTheJedi
Have you had a look at the bug?
Will there be a fix for it ?

KevinTheJedi

Tinnitus

Not yet, this is a low priority bug. Legacy is in maintenance mode so development has slowed down quite a bit as we focus more on v2.0. It is on our list to look into.

Cheers.

Tinnitus

Dev14

Thanks for your fix, we work with it regularly, and it works relatively well. (After we refreshed our SQL knowledge)

@KevinTheJedi
Have you had time to look at the problem with the SQL function so that it is generated correctly?

KevinTheJedi

Tinnitus

There have been no commits made in reference to this and no updates within this thread so, no, no updates yet.

Cheers.

Dev14

This bug applies to when two or more conditions are set on a queue. My example is born out of attempting to set a number of conditions on my "Open" top-level queue (see my original post above). You may need to adjust which row you edit by matching the "title" column with the queue you're trying to correct and manually update in MySQL if your conditions are set for a different queue. Also, you'll want to make sure your two or more conditions are set up in your OSTicket panel before editing MySQL directly.

For those that find this thread, here is where to manually update this in MySQL (I do use phpMyAdmin locally for easier administration). You do this at your own risk...I do have a DB admin background and experience:

Expand your OST database
Click ost_queue table
Click "edit" on the first row. Title is "Open" (the first one; which is the top-level "Open" queue.)
Scroll down to the row labelled "config"
You can edit the "conditions" in that string.
Don't forget to scroll down and click, "Go" to commit the change then refresh your Admin Panel in OSTicket.

For me, my first "condition" had a null value and only showed two sets of quotes with no numbers after adding a second condition. I simply updated it by entering in the number 3 between the set of quotation marks.

Before

After

Tinnitus

Hello,
I have created a patch for this that works fine in my tests.
Is it possible to integrate it into a future update, or could this cause potential problems?

    function getRoughCount() {
        if (($count = $this->getRoughCountAPC()) !== false)
            return $count;

        $query = Ticket::objects();
        $Q = $this->getBasicQuery();
        $expr = SqlCase::N();

// Prüfen, ob mehrere Custom Conditions definiert sind
if (is_array($Q->constraints)) {
    foreach ($Q->constraints as $condition) {
        // Jede Bedingung korrekt in einen SQL-Ausdruck umwandeln
        $expr->when(new SqlExpr(new Q($condition)), new SqlField('ticket_id'));
    }
} else {
    // Fallback: Einzelbedingung wie bisher
    $expr->when(new SqlExpr(new Q($Q->constraints)), new SqlField('ticket_id'));
}
        $query = $query->aggregate(array(
            "ticket_count" => SqlAggregate::COUNT($expr)
        ));

        $row = $query->values()->one();
        return $row['ticket_count'];
    }

    function getRoughCountAPC() {
        if (!function_exists('apcu_store'))
            return false;

        $key = "rough.counts.".SECRET_SALT;
        $cached = false;
        $counts = apcu_fetch($key, $cached);
        if ($cached === true && isset($counts["q{$this->id}"]))
            return $counts["q{$this->id}"];

        // Fetch rough counts of all queues. That is, fetch a total of the
        // counts based on the queue criteria alone. Do no consider agent
        // access. This should be fast and "rought"
        $queues = static::objects()
            ->filter(['flags__hasbit' => CustomQueue::FLAG_PUBLIC])
            ->exclude(['flags__hasbit' => CustomQueue::FLAG_DISABLED]);

        $query = Ticket::objects();
        $prefix = "";

        foreach ($queues as $queue) {
            $Q = $queue->getBasicQuery();
            $expr = SqlCase::N();

// Prüfen, ob mehrere Custom Conditions definiert sind
if (is_array($Q->constraints)) {
    foreach ($Q->constraints as $condition) {
        // Jede Bedingung korrekt in einen SQL-Ausdruck umwandeln
        $expr->when(new SqlExpr(new Q($condition)), new SqlField('ticket_id'));
    }
} else {
    // Fallback: Einzelbedingung wie bisher
    $expr->when(new SqlExpr(new Q($Q->constraints)), new SqlField('ticket_id'));
}
            $query = $query->aggregate(array(
                "q{$queue->id}" => SqlAggregate::COUNT($expr)
            ));
        }

        $counts = $query->values()->one();

        apcu_store($key, $counts, 900);
        return @$counts["q{$this->id}"];
    }

KevinTheJedi

Tinnitus

This issue has nothing to do with the counts.. it's in regards to multiple conditions on the same column in a single queue. Essentially, the previous Condition gets overwritten with the latest one (if applied on same column).

Cheers.

Tinnitus

This fix resolves our issue with multiple conditions and is exactly what @Dev14 was looking for.
My question is whether this could be included as a bugfix in a future release, assuming my solution is accepted.

KevinTheJedi

Tinnitus

So this solves the OP issue? Or only after manually correcting the OP issue via the database?

Cheers.

Tinnitus

Yes, it solves the problem

KevinTheJedi

Tinnitus

I just applied both patches, tested the OP issue, and your patches do not solve the OP. Go re-read the OP and try it step-by-step and you'll see.

Cheers.

Tinnitus

Unfortunately, it doesn't quite work yet - but the multiple conditions seem to be working now, which wasn't the case before.