Prefill simple search criteria in the search grid

Hello, 

For Documents item type, in the search grid I need the "Classification" to be prefilled to "General" . 

I applied client side method to "classification" and "search_default" properties of Documents but it doesn't work. 

"search_default" property did not exist before so I just added it, I don't know if that makes a difference.

method: 

return {classification:{filterValue:"General",isFilterFixed:false}}; 

Parents
  • Hi,

    using the "Default Search" column for the classification property in your ItemType should work just fine. The filter Methods are typically used for pop-up search dialogs.

    You just need to keep in mind that this feature is a bit of a diva. "Default Search" loves to conflict with user preferences. Have you tried the "Reset preferences" button in the user menu in the top right corner?

    Angela

  •   oh right "Default Search" option works. I was hoping to do this via a method. Because we need this "Default Search" to be populated for a certain identity only. 

  • Ah, okay! Du willst einen dynamischen Filter. Es gibt noch ein paar andere Optionen. 

    1. Der Benutzer kann seine eigene gespeicherte Suche angeben. Dies ist eine gute Lösung, wenn der Filter nur aus praktischen Gründen verwendet werden soll. 

    2. Mit einem „On Before Get“-Serverereignis können Sie zusätzliche Suchbedingungen hinzufügen. 

    this.setProperty("Klassifizierung","mycat");
    gib dies zurück;

    Nachteil der Lösung: Der Benutzer kann nicht sehen, dass ein Filter aktiv ist. Normalerweise verwendet man diese Technik für „orderBy“-Einstellungen oder andere Filterverbesserungen, die für den Endbenutzer von geringem Interesse sind.

    Sie können eine Identitätsprüfung hinzufügen, aber versuchen Sie, unnötige Abfragen so weit wie möglich zu vermeiden. Der Code wird von jedem einzelnen Benutzer für jede Grid-Operation ausgelöst ... immer!

    3. Sie können die Einstellungen für die Benutzer vordefinieren, um die Suchbedingung immer einzuschließen. 

    In meiner Umgebung hatten wir tatsächlich den umgekehrten Anwendungsfall. Aufgrund einiger versehentlich gespeicherter Einstellungen war eine bestimmte Suchbedingung immer vorhanden und der Benutzer musste sie immer manuell löschen.

    Benutzer können die Präferenz immer noch selbst löschen (in Wirklichkeit tun sie das nie – sie fragen immer zuerst den Administrator). Ich habe hierfür keine gebrauchsfertige Anleitung. Sehen Sie sich den Präferenzelementtyp an und versuchen Sie zu verstehen, was passiert. Sie können die Präferenz für bestimmte Identitäten per Methode ändern.

    EDIT: User save their own preference settings with the "Save layout" button. Maybe this is the best solution for you if you don´t mind that people can overwrite the filter.

    4. Wenn Sie aus Sicherheitsgründen einen Filter benötigen, versuchen Sie es mit MAC/DAC.

  • I edited the original post, but unfortunately page auto translate of my browser kicked in. I don´t have the original post anymore. Just translate from German to English, it still should make sense somehow :-)

  • thanks   following your post above i have this method 

    I

    nnovator inn = this.getInnovator();
    
    //Get ID of the logged in user
    Item alias = inn.newItem("Alias","get");
    alias.setProperty("source_id",inn.getUserID());
    alias.setAttribute("select","related_id");
    alias = alias.apply();
    
    
    //Get id of the identity the user is part of
    string relatedId = alias.getProperty("related_id");
    string identity = inn.newResult(relatedId);
    
    
    // ID of the identity "ShopFloor"
    string target = "DBA5D86402BF43D5976854B8B48FCDD1";
    
    //Get the filtered object if the logged in user's related identity matched the Id of "shopFloor" identity
    if(identity == target){
    //Get Item document where "classification" = "General"
    Item docs = inn.newItem("Document","get");
    docs.setAttribute("select", "");
    docs.setProperty("classification", "General");
    return docs.apply();
    }

    the errors i get is 
    ERROR: 9FB01F83F326460EA304FBB7FA24AC2A.
    Line number 13, Error Number: CS0029, Cannot implicitly convert type 'Aras.IOM.Item' to 'string'
    Line number -3, Error Number: CS0161, 'ItemMethod.methodCode()': not all code paths return a value

    I can get the related ID by adding the line "return inn.newResult(relatedId)" but this stops the further execution of the code block. If I run the part that gets me the filtered "Document" item ,separately, where Classification = General that works too. However, when I combine the two code blocks that get me the related_id of the UserId and filtered Document item I get the above error.

  • This one will lead to an error --> string identity = inn.newResult(relatedId);
    "newResult" is an item, not a string. 

    Second error is caused by the missing return. You only return something in this if statement. But nothing if the "if-statement" is bypassed.

    Which event type do you use right now?

    As said before, avoid unnecessary queries at all cost cause "get" Methods are executed for every search operation which can lead to performance problems. 

    Something like this could work for onBeforeGet (not tested):


    string currentUserIds = Aras.Server.Security.Permissions.Current.IdentitiesList;
    if(CCO.Permissions.IdentityListHasId(currentUserIds, targetId))
    {
       // Add additional filter if user has targetId identity included in it´s id list
      this.setProperty("classification","General");
    }

    return this;


    onBeforeGet Methods influence the search filter. It´s not a classic item operation.

  •  I applied this method to onBeforeGet. Correct results show in the Document search grid however other Documents, the ones that have Classification other than General do not open. They show but don't open. 
    As you can see in the screenshot Document PR-100001 does not show in the search result which is the intended outcome. However, it doesn't open. It would open if the method is not applied to the Document item. 

    Method: 

    Innovator inn = this.getInnovator();
    //Id of Identity ShopFloor
    string target = "6AEA9BA311D64CD080005608BAF10914";
    string currentUserIds = Aras.Server.Security.Permissions.Current.IdentitiesList;
    if(CCO.Permissions.IdentityListHasId(currentUserIds, target))
    {
    // Add additional filter if user has targetId identity included in it´s id list
    this.setProperty("classification","General");
    }

    return this;

    Screenshot:

  • To be honest, I don´t thing the onBeforeGet filter is the best solution for your use case at all. I still think MAC and DAC are maybe the better option or just some Saved Searches. Don´t believe everything you find in this forum Grin

    Main question: Do you want to have a restriction out of convenience or for security?

    What you see now is the beauty of all onBeforeGet solutions - the tiny little happy details.

    First you have to ensure that your own identity does not contain the target identity too. If you don´t want to exclude your self from the identity group, write another code to abort the method for admins or similar groups. 

    To ensure you can still open the items from a relationship while they are hidden in the main grid, you need a trick.

    Basically you allow people to open the item, if they explicitly search for it (this is what happens in the relationships automatically)

    You need to add something like this to your current solution: 

    if (this.getProperty("id","") == "")
    {
       this.setProperty("classification"," Shipping Unit");
    }

    But as mentioned before, it´s maybe not the best solution for you use case. In doubt ask Aras! They get these kind of questions very often. I assume have a subscription. Why not use it?

    And tell Aras they need to find a better open release option that ensures the survival of the supportive forum community. Thanks :). 

Reply
  • To be honest, I don´t thing the onBeforeGet filter is the best solution for your use case at all. I still think MAC and DAC are maybe the better option or just some Saved Searches. Don´t believe everything you find in this forum Grin

    Main question: Do you want to have a restriction out of convenience or for security?

    What you see now is the beauty of all onBeforeGet solutions - the tiny little happy details.

    First you have to ensure that your own identity does not contain the target identity too. If you don´t want to exclude your self from the identity group, write another code to abort the method for admins or similar groups. 

    To ensure you can still open the items from a relationship while they are hidden in the main grid, you need a trick.

    Basically you allow people to open the item, if they explicitly search for it (this is what happens in the relationships automatically)

    You need to add something like this to your current solution: 

    if (this.getProperty("id","") == "")
    {
       this.setProperty("classification"," Shipping Unit");
    }

    But as mentioned before, it´s maybe not the best solution for you use case. In doubt ask Aras! They get these kind of questions very often. I assume have a subscription. Why not use it?

    And tell Aras they need to find a better open release option that ensures the survival of the supportive forum community. Thanks :). 

Children
No Data