Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button.  The answer will now appear with a checkmark.  Please be sure to always mark answers that resolve your issue as verified.  Your fellow Community members will appreciate it!  Learn more.

  • State Verified Answer
  • Replies replies
    3
  • Subscribers subscribers
    2
  • Views views
    1456
  • Users 0 members are here
  • Locked Locked
Related
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sending Atlas requirements to many backlog projects (e.g. JIRA)

RavenArens

Atlas help says that one a project can be set up so that requirements from one Atlas project can be sent to multiple projects (backlog) through use of a UDA.

For instance if we are using JIRA as our external issue tracker, is this accomplished by creating a drop down list UDA within Atlas that has values that will be used to identify the different options for backlog projects (i.e. JIRA projects) and then within Connect how is the mapping defined?  Is one Hub project mapped to multiple JIRA projects and how is the criteria set up to determine which backlog item goes to which project.

 

Are problems introduced if the UDA value on the requirement is changed after a story has already been sent to the backlog from that requirement? 

Parents

  • Verified Answer

    0  
    Hi Ellen.

    The UDA takes effect whenever a requirement is published/shared - i.e. whenever a story item is created based on the requirement. No effect before and after, otherwise.
    Thus, only changing the UDA value itself has no immediate effect - no matter if the req is already shared or not.

    The UDA will cause Atlas to create stories in the Hub project(s) that are named exactly the same (case-sensitive) as the selected UDA values.
    There is no direct relation to JIRA and the name of the JIRA projects (though, typically, Hub project names and JIRA project names are kept identical).

    The UDA acts exclusively within the scope of the HUB
    The link between Hub projects and JIRA project is solely under the control of Connect.
    The Connect config is typically the same for all involved projects - the multi-backlog UDA does not need any Connect "specialties"...

    You need HUB projects for all the JIRA projects you want to access.
    You need Connect configurations that sync these Hub Projects with the JIRA projects.
    Then create the values for the multi-select UDA.

    Best Regards,
    Dominique.
Reply

  • Verified Answer

    0  
    Hi Ellen.

    The UDA takes effect whenever a requirement is published/shared - i.e. whenever a story item is created based on the requirement. No effect before and after, otherwise.
    Thus, only changing the UDA value itself has no immediate effect - no matter if the req is already shared or not.

    The UDA will cause Atlas to create stories in the Hub project(s) that are named exactly the same (case-sensitive) as the selected UDA values.
    There is no direct relation to JIRA and the name of the JIRA projects (though, typically, Hub project names and JIRA project names are kept identical).

    The UDA acts exclusively within the scope of the HUB
    The link between Hub projects and JIRA project is solely under the control of Connect.
    The Connect config is typically the same for all involved projects - the multi-backlog UDA does not need any Connect "specialties"...

    You need HUB projects for all the JIRA projects you want to access.
    You need Connect configurations that sync these Hub Projects with the JIRA projects.
    Then create the values for the multi-select UDA.

    Best Regards,
    Dominique.
Children
No Data

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.