How to process new fields in a dashboard page without retrofitting every feeder page

[Scott Gillespie]

I have multiple "feeder" pages summarizing sprint details for different engagements.  These feeder pages roll up to a dashboard page to give a consolidated view.

A new field is needed for tracking additional data points ("Missed Story Reason--Owner" and "Missed Story Reason--Vendor").  These are numeric fields counting how many instances of missed stories were caused by owner vs. vendor.  If I had just a few pages plus the dashboard to update, it would be a trivial task.  However, there are hundreds of feeder pages involved. 

Is there a way for me to use macros/SQL in the dashboard page to handle feeder pages with and without the new field so I can avoid retrofitting older pages?  In other words, the dashboard should show both missed story fields, with values from pages that I've updated, and simply ignore/leave blank for pages not updated.

My experience so far has been that I need feeder page content consistent to roll up to a dashboard, and I haven't been able to find an alternative using statements like "IF 'Missed Story Reason--Owner" IS NOT NULL, etc.

[Aron Gombas _Midori_]

If I correctly understand your story, you want to mass-update the "feeder" pages without manual efforts.

I think you should try to do that via the database. All gadgets on all dashboards are storing their preferences in the database.

It means that:

1. re-configure one feeder page manually so that you have an example
2. check out the gadget preferences of this page in the database
3. based on that, write an SQL UPDATE statement and update all other gadgets

This is the theory. I'd experiment with this in a staging Jira so that I don't destroy all dashboards accidentally, and only if I have a proven recipe, I'd run that on the production database.

Database tables are documented here: https://developer.atlassian.com/server/jira/platform/database-schema/

Note that in the old terminology dashboards are called "portal pages" and gadgets are "widgets", therefore you should probably focus on these tables:

[Scott Gillespie]

Thanks for this info.  This may well be the needed solution, but let me better explain my situation to see if this is still the correct approach, or if something simpler will work.

Current table of missed story info uses Jira Sprint Report info along with a field with checkbox to indicate owner or vendor as cause of incomplete story, along with comment for brief explanation. I was asked to count how many missed stories in a given sprint were due to owner vs. vendor.  My understanding is that counting anything other than Yes/No-True/False checkboxes is difficult if not impossible to do, esp. with the embedded comments.

It was proposed to adjust the table to have a column for owner missed reason and a separate column for vendor missed reason, eliminating the checkboxes.  Users need only enter comments in the appropriate column, leaving the other blank.  This allows an easy count of non-blank entries to give the data point needed.

Current table (data copy/pasted from Jira, with missed reason info manually added:

Key     Status           Missed Sourced & Reason

01       Incomplete  [x] Owner
                               [  ] Vendor
                               Comment:  Test data not ready

01       Incomplete  [  ] Owner
                               [x] Vendor
                               Comment:  Developer unable to resolve code issue

New table
Key     Status           Owner Missed Reason    Vendor Missed Reason 

01       Incomplete  Test data not ready

01       Incomplete                                           Developer unable to resolve code issue

My first thought is that I need to change the tables in every page.  Your UPDATE solution may be the answer, then, to avoid that manual effort.  However, I learned that having this data point for all historical pages is not required--I only need to update current pages and these will be copied going forward.  

I used Table Transformer SQL to roll up this data, but I have always worked with consistent table content.  Is there a way to set up the SQL so it will tally the new table format totals, and ignore the original tables with the different format?  If so, then I don't need to retrofit all the previous sprint pages, manually or programmatically.