Metadata Card Configuration: Hide property based on value

Hi

1: Currently, it is only possible to use lookup properties (single-select and multi-select) as filter properties in the metadata card configuration.

2: Do you have that configuration available. I cannot reproduce the error. Here's a sample implementation against the sample vault that adds the Product or service property to the proposal class. Make sure that none of your groups has "Is default = true"

Condition:

{
  "Class": 5
}

Behavior:

{
  "Groups": { 
    "Proposal Status": { 
      "Title": "Proposal Status", 
      "IsCollapsible": true, 
      "IsCollapsedByDefault": false, 
      "HasHeader": true, 
      "IsDefault": false 
    },
    "Indexing data": {
      "Title": "Indexing data",
      "IsCollapsible": true, 
      "IsCollapsedByDefault": false, 
      "HasHeader": true, 
      "IsDefault": false
    }
  }, 
  "Properties": { 
    "1096":{ 
      "Group": "Proposal Status"
    },
    "1098": { 
      "Group": "Proposal Status"
    },
    "1004": { 
      "Group": "Indexing data"
    },
    "1034": { 
      "Group": "Indexing data"
    },
    "1040": {
      "IsAdditional": true,
      "IsHidden": false
    }
  } 
}

3: I'll forward your feedback to our doc team.

Mika

Hi Mika,

1: This is me making a sad face --> :-\ I would like to see this enhanced, at least with basics as Empty/Null, NotEmpty, etc

This limitation to lookupID's is not mentioned in the documentation and it doesn't stroke with the documented part where you can use the name of a workflow state as a property condition:

You can also use workflows and workflow states as property conditions. You may use aliases or IDs for workflows or
workflow states in the condition:

{
"Properties": {
 "38": "Processing job applications",
 "39": "Applicant selected for interview"
 }
}

Can you clarify that?


2: sample code below as requested.

It looks like the order issue was caused by [ "IsDefault": true ], thanks!

When you put the IsDefault on false, the properties will show on above the groups. It's logical when you read it afterwards in the documentation.
So, now I set the last group to be default, so the properties as company and contacts etc will automatically show at the bottom since I don't want the clutter to be on top.

{
  "MetadataCard": {
  "Description": {
    "Content": "Contact support
for more information.",
    "Image": {
      "Url": "">community.m-files.com/M-Files-logo.png",
      "Width": 250,
      "Height": 42
      }
    }
  },
  
  "Theme": {
      "Footer": {
        "IsHidden": true
      }
  },
  
  "Groups": {
    "GroupEmailHeader": {
      "Title": "Email Header",
      "IsCollapsible": true,
      "IsCollapsedByDefault": false,
      "HasHeader": true,
      "IsDefault": false,
      "Priority": 10
    },
    "GroupEmailMessage": {
      "Title": "Email Message",
      "IsCollapsible": true,
      "IsCollapsedByDefault": false,
      "HasHeader": true,
      "IsDefault": false,
      "Priority": 20
    },
    "GroupSupport": {
      "Title": "Support",
      "IsCollapsible": true,
      "IsCollapsedByDefault": false,
      "HasHeader": true,
      "IsDefault": false,
      "Priority": 30
    },
    "GroupContact": {
      "Title": "Contact information",
      "IsCollapsible": true,
      "IsCollapsedByDefault": false,
      "HasHeader": true,
      "IsDefault": true,
      "Priority": 40
    } 
  }, 
  
  "_Comment": "Undefined fields show up below last defined group.",  
  
  "Properties": {

    "100": { 
      "_Comment": "Property: Class and can't be hidden.",
      "IsHidden": true
      }, 

    "35": { 
      "_Comment": "Property: Created from External Source",
      "IsHidden": true
      }, 

    "MF.PR.EmailName": { 
      "Group": "GroupEmailHeader",
      "Label": "Name or title",
      "IsHidden": true
      }, 

    "MF.PR.EmailFrom": { 
      "Group": "GroupEmailHeader",
      "Label": "From"
      }, 
      
    "MF.PR.EmailTo": { 
      "Group": "GroupEmailHeader",
      "Label": "To"
      },       

    "MF.PR.EmailCC": { 
      "Group": "GroupEmailHeader",
      "Label": "CC"
      }, 

    "MF.PR.EmailSentDate": { 
      "Group": "GroupEmailHeader",
      "Label": "Date",
      "Priority": 1
      }, 

    "MF.PR.EmailSubject": { 
      "Group": "GroupEmailMessage",
      "Label": "Subject"
      }, 
      
    "MF.PR.EmailBody": { 
      "Group": "GroupEmailMessage",
      "Label": "Body"
      }, 
  
    "MF.PR.Case": { 
      "Group": "GroupSupport"
      }, 

    "MF.PR.Notes": {
      "Group": "GroupSupport",
      "Description": "Only make remarks that contribute to the document and don't have a place in other properties.",
      "Tooltip": "Notes field."
      } 
  } 
}

1: This is me making a sad face --> :-\ I would like to see this enhanced, at least with basics as Empty/Null, NotEmpty, etc

This limitation to lookupID's is not mentioned in the documentation and it doesn't stroke with the documented part where you can use the name of a workflow state as a property condition:

You can also use workflows and workflow states as property conditions. You may use aliases or IDs for workflows or
workflow states in the condition:

{
"Properties": {
 "38": "Processing job applications",
 "39": "Applicant selected for interview"
 }
}

Can you clarify that?

We are working to add more possibilities to the filters in future releases. In my comment I meant that the filter property data type must be select from list or select from list (multi-select). You can surely use aliases etc. The built-in "Workflow (ID 38)" and "Workflow state (ID 39)" are single-select lookup properties in the database. This is explained in chapter 3.5 in the documentation:

Note: Currently only SSLU (single-select lookup) and MSLU (multi-select lookup) properties are supported in
property-based conditions.

Mika