Voorwaarden bouwen: alle, een of meer, en de val ertussenin

Alle en een of meer bepalen welke tickets een regel raakt. Twee andere begrippen, is en gewijzigd in, bepalen of hij één keer afgaat of elke keer.

Alle en een of meer bepalen welke tickets een regel raakt. Twee andere begrippen, is en gewijzigd in, bepalen of hij één keer afgaat of elke keer.

Alle en een of meer

• Voldoen aan ALLE van de volgende voorwaarden. Elke voorwaarde waar. Deze maken smaller.
• Voldoen aan EEN of MEER van de volgende voorwaarden. Minstens één waar. Deze maken breder.

De klassieke fout is alternatieven in het alle-blok zetten. Status is Open en status is In afwachting, allebei in alle, past op niets.

Waar mensen werkelijk op stuklopen

Voorwaarden komen in twee smaken en die gedragen zich totaal anders.

• Is. Waar zolang het ticket in die stand staat. Een trigger met "status is Open" gaat af bij elke bijwerking zolang het ticket open is.
• Gewijzigd in. Alleen waar bij de bijwerking waarin het dat werd. Gaat één keer af.

Een melding die op "is" is gebouwd mailt de klant bij elke bijwerking, het hele leven van het ticket lang. Op "gewijzigd in" gebouwd mailt hij één keer, en dat was de bedoeling.

Het verwante paar

"Gewijzigd" en "niet gewijzigd" werken op dezelfde manier voor elk veld. Gebruik ze zodra de regel over een overgang gaat in plaats van over een toestand, en dat geldt voor de meeste meldingsregels.

Twee losse sets alternatieven

Er is maar één een-of-meer-blok, dus dit kun je niet rechtstreeks uitdrukken. Het gebruikelijke antwoord is een tag: de ene trigger zet hem als de eerste set past, en een tweede leest de tag. Minder elegant en een jaar later veel leesbaarder.

Zie ook

• Waarom mijn trigger niet afging
• Oneindige loops in triggers voorkomen
• Voorwaarden en acties: het volledige overzicht