nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Trying to generate a 5% sample size.

Manav Shah_nhoo89

We have two projects A and B. In project A data will be added, project B is quality check. I want 5% of tickets from project A to enter project B for quality checks once ticket is closed in project A. I have created the below rule, please advice me if this is going to work. I have created branch because I need different % of samples for different conditions. Please advice me on variable and its comparison.

Accepted answers

Ste Wright

Hi @Manav Shah

I assume you're trying to use the logic in this answer?

If yes, it's not an exact science - you're effectively giving the rule a 5% chance of passing the condition, but it's not a guarantee that it'll be 5% exactly.

I also don't think you need to use "Lookup Issues" for this, as it's not based on a set of data, but each single issue's transition.

---

The rule might look like this (without additional conditions)...

Trigger: Issue transitioned
Action: Create variable
- Name = RandomNumber
- Smart value = {{#=}}CEILING(RANDOM()*20){{/}}
Condition: {{smart values}} condition
- First value = {{RandomNumber}}
- Condition = greater than
- Second value = 19
Action: Create Issue

^ So essentially, a random number is assigned between 1-20. And the condition then checks it's over 19 (i.e 20) - which has a ~5% chance of being assigned.

Ste

All comments

Walter Buggenhout

Hi @Manav Shah and welcome to the Community!

That looks quite spectacular. But I am not sure what you are actually trying to achieve as a result.

At a certain point in your automation rule, you suddenly refer to lookupIssues, but I don't see any point in your automation rule where you perform the lookup Issues action. If you don't perform a lookup of a set of issues first, the {{lookupIssues}} smart value will just return nothing. So no, I don't think this is going to work.

If I understand what you are trying to do (randomly generating a number of issues for testing based on an unknown number of issues in another project that might be ready to test) I can't think of a way to automate this. It would be much easier if you could build a ready to test status into the workflow of your Project A, you can easily select the issues that need to be reviewed one by one, thus drastically reducing complexity.

Hope this helps!

Manav Shah_nhoo89

Hi @Walter Buggenhout, thank you very much for the quick response. I am quite new here. I just wanted to create a random sample which is almost equal to 5%. How about if I replace my variable to "{{#=}}CEILING(RANDOM()*100" and change the condition to if variable is less than 5, it should create new ticket in project B?

Walter Buggenhout

You can create a new ticket in project B at any time, @Manav Shah. But I don't think that is what you are trying to do, unless I am missing your point.

I understand that you are trying to determine how many tickets should be (randomly) tested. I don't see the point in that unless you also define which tickets these are. And - if you don't define those tickets - why even bother to do all the math? I don't see any place in your rule where you are actually doing something with the result of your calculation.

But, I'm quite sure that's because I don't understand what it really is you are trying to do.

Manav Shah_nhoo89

So basically, my project A is purely a project to input data in CRM based on the description of the ticket. While in project B, I want to quality check these tickets if data is correctly entered based on description once the ticket is closed. But, now there 1000 tickets, I want to quality check only 50 of them as a sample. So, end result of this rule is to create 50 tickets for quality check in project B as 5% sample from project B.

Just fyi, we don't want to merge both projects, need it separate.

@Walter Buggenhout

Ste Wright

Hi @Manav Shah

I assume you're trying to use the logic in this answer?

If yes, it's not an exact science - you're effectively giving the rule a 5% chance of passing the condition, but it's not a guarantee that it'll be 5% exactly.

I also don't think you need to use "Lookup Issues" for this, as it's not based on a set of data, but each single issue's transition.

---

The rule might look like this (without additional conditions)...

Trigger: Issue transitioned
Action: Create variable
- Name = RandomNumber
- Smart value = {{#=}}CEILING(RANDOM()*20){{/}}
Condition: {{smart values}} condition
- First value = {{RandomNumber}}
- Condition = greater than
- Second value = 19
Action: Create Issue

^ So essentially, a random number is assigned between 1-20. And the condition then checks it's over 19 (i.e 20) - which has a ~5% chance of being assigned.

Ste

Manav Shah_nhoo89

Hey @Ste Wright! Yes figured this one out. But the problem in this rule is that its just a 5% probability and not really 5% of total population is being generated as sample. Looking for further solutions to this problem. Thanks anyways, cheers!

Ste Wright

Hi @Manav Shah

You mention below you already have 1,000 tickets - could you...

Use Automation to populate them with a piece of metadata, using the 5% option above, and then...
Use a second rule to create a set of issues based on that metadata.

...?

This would allow you to apply the logic to the whole data set and continue to use that logic ongoing with the previous rule above.

----

The additional rule for (1) might look like this...

Trigger: Scheduled
- Run a JQL search = TRUE
  - JQL - project = Project A
Action: Create variable
- Name = RandomNumber
- Smart value = {{#=}}CEILING(RANDOM()*20){{/}}
Condition: {{smart values}} condition
- First value = {{RandomNumber}}
- Condition = greater than
- Second value = 19
Action: Edit Issue
- Field = Labels
  - Value = <insert value here>

---

A few notes...

This is an example rule; you could set the "Edit Issue" action to modify whichever unique identifier is best for you.
You only need to run this rule once, then deactivate it. You can run a scheduled rule out of cycle once it's active. Select the breadcrumbs (...) in the top-right, then select Run rule.

---

Let us know your thoughts

Ste

Manav Shah_nhoo89

So actually, we have continuous data actually. I just gave an example of 1000 entries to showcase the large dataset size.

I don't think the above will work for daily tickets, this is more for if you are running the rule once 1000 entries are done. I hope I got your POV right.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management