Comments
-
Hi Daniel, You would have to implement Issue Level Security if you didn't want the user to be able to see issues that have been created. But they would still need the Browse project permission to see the form. The other thing you can do is just share the board filter with certain users - then other users couldn't even see…
-
@Charlotte Nicolaou - Thanks for the update! Yes Kate answered my other question for me. :-)
-
What specifically can't the user see? Can you share a screen shot of the product access for that user (without sharing user into)?
-
I ended up breaking the rule up into two separate rules.
-
So, is custom field 10081 the planned end date?
-
What does the filters look like for the other two boards?
-
you can probably just create a test card and run it through the process to see. :-)
-
The other two boards have to have the projects associated with the Epics included in the Filter for the board. For example; Master board shows Projects in (ABC, 123, DEF). And an Epic is created against ABC project (ABC-1). Then if you want the epic to show up in the board for Project 123, you have to include the project…
-
Hi Malinda, Just by adding a user as and Administrator in Jira doesn't automatically give the person access to everything. It all depends on the Permission Scheme attached to the Project. Make sure the person has at least Browse Project to see the project.
-
Great! Glad it is working for you now!
-
Actually, you shouldn't be using the advanced compare because they are not really two different fields - they are one field. Try changing the compare to just a JQL condition with {{issue.Stage}} = Approved
-
Can you share a screenshot of your latest rule and the audit log where it didn't work?
-
Hi Madhura - Welcome to the Atlassian Community! You need to check the Notification Scheme for the project to see if anything changed which who should receive notifications when.
-
If Approved is not in the list for any other first level option, it might work. Otherwise, you can add two Advance Compare conditions - one to check the parent.value and then one to check the child.value.
-
Hi @Kate Clavet-D_Amelio - thanks for the clarification. We will regroup based on that. We definitely have no plans to unmerge them.
-
I would report it as a bug here then: https://support.atlassian.com/contact/#/
-
Using linked issue types implies there is not a parent/child relationship. They are just related. Did the above suggestion work?
-
Hi Peyush, Try {{issue.Stage}} = Approved And if that doesn't work, give this a try: {{issue.Stage.child.value}} = Approved
-
What time zone are you located in? And at what time would you like the rule to fire local time?
-
Hello and Welcome, Amna! We are glad you are here!!
-
Hello and Welcome, @faus32 ! We are glad you are here!!
-
Agree with Dirk - I just had to submit one for one of our users on Friday. The user's email has to be de-blacklisted by Atlassian support (if that is the problem).
-
Hi @Alexey Petenko - Have you done these things?
-
Hello and Welcome, Keshava! We are glad you are here!!
-
Just remember that the date/time for the cron is UTC - so you might have to adjust the timing based on your time zone.
-
Hi Giuseppe - so what is not working with it now?
-
Do you have development tools attached to your project?
-
@Andrii Surai - that would require an involved work around.
-
Hi Carlos - It is always better to create a new question instead of adding one to an existing posting because the only ones who will see it are the ones on the post. That being said - can you be more specific in what you are wanting to do?