April 23rd, 2019 by inflectra
In a recent post, we highlighted new templating functionality in SpiraTest/SpiraTeam/SpiraPlan 6.0. Templates let you have multiple products (formerly known as projects) that all share the same workflow configuration, types, priorities, and more with each other. If you change the template, all the products based off of that template immediately change too. This post will explore how templates will work. A more detailed post about how to plan your migration to templates will be out soon.
The above rule set for templates hopefully shows how powerful they are. They should make using SpiraPlan easier and more streamlined. But it can be hard to wrap your head around them (it certainly did for a number of the Inflectra team). Let's try and explore templates in a small example.
Sansa works at The North Enterprises. She is a system administrator of SpiraTeam 5.4. The North has eight products. When they upgrade to 6.0, they still have eight products. But now they also have eight templates: one for each product. The data in every product is the same as before. The priorities, types, statuses, workflows are all the same. To a normal user like Ned, SpiraTeam 6.0 works basically the same as before (just prettier and nicer).
Sansa, as the system admin, can see all the products and all the templates from the administration section of the application. Arya, a colleague of Sansa, is a product admin of product Stark. With SpiraPlan 6.0, product Stark now has its own template - template Stark. Through the upgrade process, Arya is automatically an admin for template Stark. She can go to administration for either product Stark or template Stark to make any change she wishes. For instance, she can add or remove members from product Stark via its product admin.
What if Arya wants to change the incident workflows for product Stark? These are no longer attached to the product. They are now part of template Stark. So from the admin menu she would select Incidents > Workflows, just like in 5.4, but now this menu item is on the template, not the product.
Meanwhile Sansa has been asked to create a new product - the Snow product. She creates it but does not give it its own template. Instead Sansa makes it use the same template as product Stark - template Stark. Now product Snow and product Stark use the same template. With the new product made, Sansa adds her colleague Jon as a product admin of product Snow. Jon automatically also becomes an admin of template Stark. Jon wants to fiddle with a requirement priority color for his product Snow (so that one of the priority's is black). He makes this change in template Stark. This means all requirements with that priority in both product Snow AND product Stark will now be black, because they both get this information from the template. If Arya isn't happy with this change, she can go to template Stark and change it back (or better yet take up the matter with Jon first).
And if you have any questions, please email or call us at +1 (202) 558-6885
Are you looking for a platform that helps you deliver better software, faster?