Saved Search

I have the following criteria specified for a Saved Search. Unfortunately it returns/displays all default Document columns (50+). Was hoping it would just return and display the columns specified in the Saved Search criteria. Am I doing it wrong? <Item type="Document" action="get" page="1" pagesize="500" maxRecords="" select="project,doc_no,description,source,reference,doctype"><doctype condition="eq">Manual</doctype></Item>  
  • Hello, The columns displayed in an Item's grid are linked to an individual user's Preferences. By default, the same columns will be displayed independently of the Saved Search that you have selected. Chris
    Christopher Gillis Aras Labs Software Engineer
  • I would recommend identifying this as a future opportunity for improvement. Its ridiculous to use ARAS to centralize documents in one place, but then only have one grid view available across the board for all types. Right now we show all 50 attribute columns because appropriate views aren't configurable. Individual settings are nice, but (various) predefined views need to be configured (different attributes based on doc type) by admins and made available to users. Saved search seems to be the appropriate fit as it can be listed in the TOC for all.
  • Hello, I've worked on a project with a similar use case before, and the solution we came up with may work for you as well. We wanted each classification of an ItemType to have it's own view in the main search grid. What we did was create a new ItemType that corresponded with each classification. We added properties to this new ItemType that matched the property names of the original. We then created an onGet Server Event on this new ItemType with code like the sample below.
    this.setAttribute("type", "Document");
    // You can modify the query here if you want to limit the items returned
    // e.g. this.setProperty("classification", "Drawing");
    return this.apply();
    Using an onGet event like this allowed us to override the query that gets the items and instead tell the query to return Document ItemTypes. You can then customize the properties displayed on the grid by setting the Hidden flag on your properties on the new ItemType. Chris
    Christopher Gillis Aras Labs Software Engineer
  • The method type (JavaScript) specified for Doc_Manuals_Event is not currently supported.
  • Hello, Server Methods need to be written in either CSharp or VB. The short sample I provided was written in CSharp. Chris
  • Can this method be tweaked to work in relationship grids as well? Tried but onGet event may not be firing... Trying to find work arounds NOT to have the same columns displayed for every department and document category. Every department and doc category wants (rightly so) only columns relevant to them, in appropriate order (like SharePoint views).
  • Hello, The onGet event should trigger any time that the ItemType is queried for. You can try setting an onGet event on the relationship ItemType itself to redirect the query to the ItemType you want. Following this approach, you may end up with multiple relationships each for a different department. You can use this Community Project to only display the relationship tab that corresponds to the current user's Identity. Chris
    Christopher Gillis Aras Labs Software Engineer
  • Hi Chris,

    interesting that also Aras worked on the "onGet" ItemType use case. It sounds identical to the use case discussed in this thread:

    https://community.aras.com/f/development/3496/how-to-create-a-new-part-toc-menu-item-that-does-a-custom-search

    How does Aras solved the CUI button problem? I met one Aras employee who used my fabulous CUI button concept for a customer solution, but I do not know what he has changed or improved. What kind of concept did you use in your project? Something similar or were you able to find a better approach?

  • Hi Angela,

    The project I mentioned in this comment had very simple requirements. In my case, all I needed was to have a view-only way of seeing the different classifications, so I did not need to worry about making sure the NewEdit, or Delete buttons pointed to the actual ItemType.

    Do you happen to remember who you spoke with? I can check in with them to see if they made any updates or improvements to your concept of using custom CUI buttons in these kinds of views.