Welcome to the Alloy Ideas Portal đź‘‹ Here, you'll be able to browse improvement ideas raised by our community, vote on ideas you agree with or even raise your own ideas. We review all ideas raised and we endeavour to respond to all raised ideas.
Any ideas submitted will be immediately visible on the portal for others to vote on, please do not include anything in your ideas you do not wish to be shared with others.
Hi Tom, I've tried emailing you a couple of times directly regarding this ticket but it looks like your email server isn't liking emails coming from my account (this may have something to do with changes to our email infrastructure following our acquisition). Would you be able to raise this with your IT team? This is probably affecting all emails coming from @weareyotta.com.
Hi Tom, thanks for getting back to us on this. We'll take this away and discuss it with the development team and find out what may be possible to help with this. We'll update this ticket when we have more information. Thanks again!
Hi, yes no problem. This idea occurred to me last week when I was importing historical defects from a previous software system. The data had been shaped to fit the defect design within Alloy so that it was as seamless as possible with the new defects that are being created.
The date and time that the legacy defects had been created on was put in the 'Created Time' field, which is a system attribute within Alloy, however after they had gone through the Gateway process and been uploaded I noticed that the created time is generated on import because the attribute is tagged as 'computed', so about 10,000 records had the original created time overwritten and all now had a 'Created Time' on the same day. This wasn't a big problem, I instead added the proper created time into the other system attribute 'Reported Time' which isn't computed on import.
The issue we now have is that as new defects are created in system, the date and time they were created is in the attribute field 'Created Time', whereas the legacy records (some of which are still open cases and in use) have their time of origination in the 'Reported Time' field.
This creates the problem where old case files have their date of origin in the 'Reported Time' field, and new case files have their date of origin in the 'Created Time' field. So when you want to choose how the defects are presented when using the tab settings options (presumably to list the defects in chronological order with the oldest at the bottom of the list and the newest at the top of the list) the user has to decide between sorting on one of those attributes.
In this instance a system like the one that can be used for Titles and Subtitles, where you could specify to sort on Reported date (if it exists) or otherwise use the created time, would resolve this conflict for us e.g.
{{#if attributes_defectsReportedDate}}
Reported: {{attributes_defectsReportedDate}}
{{#else}}
Created: {{attributes_itemsMetadataCreatedTime}}
{{/if}}
Or alternatively an AQS type implementation to visually order list sorting could be even better as it would be easier to bake in more complex variables.
Alternatively, as I appreciate that this is possibly a niche occurrence, if there is some way to override the created time computation on import that could also solve the issue for me and negate the need for this feature in this instance.
I hope that makes sense, please let me know if you would like further details.