Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Best way to structure and implement Product Version list in Assets for Customer Request Forms

Hello, I currently have an Object Schema that I am using to store Customer Organizations and Employees. I would like to extend this to include our product versions. Currently, I have a custom field that uses a picklist (IE: 1.0, 1.1, 2.0, 3.0)  that I manually update upon new releases or when a version is retired.  When a version loses official support, I create a new option (ie. "1.0 (unsupported)") and disable the version so it can't be picked.  This informs customers when opening a new ticket that the version isn't officially supported.

I'd like to switch to using Assets and develop the schema in such a way that I can accomplish the following.

  • Have an Object be removed from a dropdown selection field available to customers based on an attribute (ie. "Selectable")
  • Have that attribute update based on another attribute that contains the expiration of support for that version.
  • Create a new object with the name of the non-supported version and "unsupported" (ie. "v1.0 (Unsupported)") so that in reviews I can distinguish between tickets that were open when the version was supported and ones that were opened when it wasn't.

My questions are three-fold:

  1. What would be the best way to structure and organize the versions?  My initial thought is they should all be Objects under the appropriate software object type, however if there are impacts in doing it this way, I am open to suggestions.
  2. How best to automate the removal of expired versions, and creation of new objects?
  3. Is there a better way to inform users or track whether a ticket was opened on an unsupported version other than my plan to create a new option for the custom field.

I think I understand how to restrict the field options based on AQL queries, so the structure and automations are my main hurdles right now.


0 answers

Suggest an answer

Log in or Sign up to answer
Site Admin
AUG Leaders

Atlassian Community Events