Skip to Main Content
Alloy Ideas Portal

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.

Status Future Consideration
Product Alloy Web
Created by Tom H
Created on May 27, 2022

Use Variables in Configure Tab Settings

When using tab settings to customize how records display in the layer panel, it would be helpful if you could use variables much in the same way that you can for Titles and Subtitles.

At present there is the option to choose an attribute and then specify ascending or descending, but in some instances it would be beneficial have more flexibility with ELSE / IF conditions etc.

  • ADMIN RESPONSE
    May 30, 2022

    Hi, could you please provide us with an example? Just want to make sure we've captured your requirements.

  • Attach files
  • Admin
    Jonathan Shaw
    Reply
    |
    Sep 23, 2022


    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.

  • Admin
    Jonathan Shaw
    Reply
    |
    Jun 13, 2022

    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!

  • Tom H
    Reply
    |
    May 30, 2022

    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.