Object Filter Per User

Object Filter Per User

Object Filter Per User

Object Filter Per User lets each user hide objects they do not want to see in the Dashboard's data-driven views — object browsers, lists, and graph/diagram views. It is reached from the Dashboard menu under Object Management → User Object Filter (the view is titled Dashboard / My Object Filters).

Two characteristics define the feature:

  • It is personal. Your filters affect only your own screen. Other users are unaffected, and nothing in the database changes.
  • It is non-destructive and reversible. Objects are hidden from results, not deleted. Turn a filter off and they reappear immediately.

Typical use: reduce noise by hiding object families you are not currently working on. The examples below use the Demo-10.0.031 inventory.


1. Object filtering at the per-user level

1.1 What "per-user" means

Each filter is tied to your user account. When a data view loads, the server resolves your identity from your session and applies only your active filters to the response before it reaches your screen. Specifically:

  • Personal scope. You only see and manage your own filters; they never affect what other users see, and only the filter's owner can edit or delete it.
  • No database changes. Filtering happens in memory, as a layer over the query result. The underlying object data and its visibility in the database are untouched.
  • Applied after the query runs. The normal query executes as usual; your filters are applied to its results afterward. This makes filtering safe and instantly reversible — unchecking Active restores the objects with no re-import or rebuild.
  • Filters stack. An object is hidden if any of your active filters would hide it, unless an exclude condition rescues it (see 1.6).
  • Fail-safe. A malformed filter (for example, an invalid Regex) never blocks results — it is simply ignored.

1.2 Before you start

  • You must be logged in. Filters are tied to your user account.
  • Decide what to hide: an object type (for example, Application Program or Copybook), a property to test (usually the name), and the text or rule that identifies the unwanted objects.

1.3 Open My Object Filters

  1. Go to the Dashboard menu → Object Management → User Object Filter.
  2. The My Object Filters view appears: a header (Dashboard / My Object Filters), a Filter Text search box, a New button on the right, and a grid of your existing filters.


Figure 1: Opening My Object Filters from the Dashboard menu and the My Object Filters view.

The grid columns:

Column

Meaning

Target Object Type

Which object type this rule applies to

Property Name

The object property being tested (usually the name)

Filter Text

The text the rule matches against

Operator

How the text is matched (Contains, Start With, and so on)

Excludes

Number of exception conditions (hover to view them)

Active

On/off toggle; takes effect immediately

Last Modified

When you last changed it

Action

Edit or Delete

1.4 Create a new filter

  1. Click New (top right).
  2. Complete the form:
    • Target Object Type — the type to hide (for example, Application Program). Leave blank to apply to all types.
    • Property Name — the property to test (for example, name). Defaults to the inventory's name property.
    • Filter Text — the value to match (for example, IOBAT). Required.
    • Operator — how to match. Defaults to Contains. See the operator reference in 1.5.
  3. Click Add.

Figure 2: The New button.


Figure 3: The New filter dialog completed for the worked example.

Worked example — hide the I/O batch routines

In this inventory the I/O batch routine programs all end in IOBAT (ACIOBAT, ADIOBAT, AGIOBAT, AHIOBAT, …).

Field

Value

Target Object Type

Application Program

Property Name

name

Filter Text

IOBAT

Operator

End With

Result: ACIOBAT, ADIOBAT, AGIOBAT, and the other IOBAT routines no longer appear in your views.


Figure 4: Before and after applying the filter. IOBAT routines no longer appear.

Note: The labels in the Target Object Type list come from your inventory. Pick the one that represents COBOL programs (for example, Application Program).

1.5 Operator reference

Examples use program names from the Demo-10.0.031 inventory. All matching is case-insensitive.

Operator

Matches when the property…

Example match

Contains (default)

contains the text anywhere

IOBAT matches ACIOBAT

Start With

begins with the text

AC matches ACIOBAT and ACNTFIX

End With

ends with the text

IOBAT matches ACIOBAT

Exact

equals the text exactly

ACIOBAT matches only ACIOBAT

Regex

matches the regular expression

^A.IOBAT$ matches ACIOBAT, ADIOBAT, AGIOBAT

1.6 Add exceptions with Excludes

Excludes act as an allow-list inside your block-list. If an object matches the main rule but also matches an exclude condition, it is kept (shown).

  1. In the New or Edit dialog, locate the Excludes section.
  2. Click Add Condition.
  3. In the inline row, type the Filter Text and choose an Operator. Click a cell to edit it.
  4. Repeat for additional exceptions. Use the delete action to remove a row.


Figure 5: Adding an exclude condition to keep ACIOBAT visible.

Continuing the example: You hid every IOBAT routine in 1.4, but you are actively working on the AC file routine ACIOBAT and want to keep it visible:

  • Exclude → Filter Text ACIOBAT, Operator Exact.
  • Result: ACIOBAT remains visible, while ADIOBAT, AGIOBAT, and the rest stay hidden.

1.7 Manage your filters

  • Turn on or off: click the Active checkbox in the grid. It applies immediately, with no dialog.
  • Edit: click the edit (pencil) action, change any field or exclude, then save.
  • Delete: click the delete (trash) action and confirm. You can only edit or delete your own filters.
  • Find a filter quickly: type in the Filter Text search box at the top, or use the per-column filters in the grid header.


Figure 6: Before applying the filter. The IOBAT programs are visible.

2. Hidden objects excluded from Graph and Detail views

Your active filters are applied to every data-driven view after its query runs, so the same rule hides matching objects consistently across Detail views and Graph views.

2.1 Detail views (browsers, lists, grids)

In list-style results, matching objects are dropped from the returned data and the item count is recalculated to reflect the smaller set. You will not see a gap or a placeholder — the hidden rows are simply absent, and totals shown in the view match what is displayed.

2.2 Graph and diagram views

In graph and diagram views, filtering removes the matching objects and cleans up the diagram around them:

  • Hidden objects are removed as nodes from the diagram.
  • Any connections (edges) that only led to a hidden node are removed as well, so no edge dangles to a node that is no longer shown.
  • Edges between two objects that both remain visible are kept unchanged.

This keeps the diagram coherent: hiding a family of objects also removes the relationship lines that pointed only at them.

2.3 Verify it is working

  1. Save the filter and confirm its Active box is checked.
  2. Open a data view that lists objects (an object browser or list) and a graph/diagram view.
  3. Confirm the behavior:
    • In Detail views, objects matching your rule no longer appear, and item counts reflect the smaller set.
    • In Graph views, hidden nodes are gone and edges that only led to those nodes are removed.


Figure 7: After applying the filter. Only ACIOBAT remains from the IOBAT family.

Note: If you see no change, confirm the Active toggle is on and that the Target Object Type matches the type shown in that view (or leave Target Object Type blank to apply to all types).

2.4 Notes and common issues

  • Per-user always. You only see and manage your own filters; they never affect other users.
  • Hidden, not deleted. Unchecking Active restores the objects.
  • Multiple filters stack. An object is hidden if any active filter would hide it, unless an exclude condition rescues it.
  • Empty Target Object Type applies to all types. Be specific if you mean only one type.
  • Where it applies. Filtering is applied to the data-driven views' results after the query runs, so it is safe and reversible — the underlying query still runs normally and the database is never changed.

    • Related Articles

    • CM evolveIT User Manual

      Welcome to CM evolveIT         User Training Manual                                                             Restrictive Rights This document and the product referenced in it are subject to the terms and conditions of the user License Agreement ...

    • Object Style

      Object Style: This document will cover the basics of the CM EvolveIT Object Management-Object Style. There will be a discussion of how we use the Object Style functionality to. After completing this document, you should have a basic understanding of ...

    • User Group

      Dashboard - User Group This document will cover the basics of the CM EvolveIT Dashboard user mapping. There will be a discussion of how to create user groups and set user authority within the group. We will look at how to assign inventories to groups ...

    • CUD and User Mapping

      This document will cover the basics of the CM evolveIT Dashboard user mapping. There will be a discussion of how to create user groups and set user authority within the group. We will look at how to assign inventories to groups as well as how to ...

    • Inventory and Object Group Mapping

      This document will cover the basics of how to map Inventories to Object Groups in the CM evolveIT Dashboard. There will be a discussion of how to assign and remove Inventories form an Object Group. After completing this document, you should have an ...