Approach to records with common fields

🖌 UX (User Experience)
#1

Hi,

I am trying to figure out a way to represent things in Corteza in my own namespace. For the sake of discussion, consider the following context:

Module A:

  • Field_F1
  • Field_F2
  • Field_A1
  • Field_A2

Module B:

  • Field_F1
  • Field_F2
  • Field_B1
  • Field_B2

There are two modules, A and B which have (from business point of view) two common fields F1 and F2, and two particular fields: A1 and A2 respectively B1 and B2.

What I would like is to allow users to see in a list all entries (instances) from either A or B with their common fields displayed and searchable in a record list.

I can see two options and I have some problems with both. There may be more and I would be happy to get any hints on different approaches.

Option 1: merge module A and B in a single module M, maybe add a type.
this way, in a record list, one can show both types of entries, with common fields or all fields.
The advantage:

  • M record list can be used to search, filter either (logical) record kinds.

The disadvantage:

  • in the record page for the M module I will see both A# and B# fields and when these are quite a few, this implies complexity and some confusion for the end user. What would help here would be a possibility to hide a field based on an expression or function.

Option 2: create a module Combined which contains only F# fields. To that, add:

  • record reference fields for module A and B
  • a type to discriminate
  • add a workflow to afterCreate for either A and B to generate a synthetic Combined record with proper values
  • add workflow to afterDelete, afterUpdate for either A and B to manage the corresponding Combined record
  • limit editing, adding, deleting of Combined

The advantage:

  • record list for Combined can be used to display, filter, search, based on F# fields entries for both A or B.
  • record page for A and B only show direct info related to them, no confusion here.

The disadvantage:

  • apparently there is no way to make a computed field which is a reference to either A or B to display in the record list or record page of Combined to allow the user to follow a link to the more detailed page. A workaround here is to display all possible related record reference fields from which only one would have a value, depending if that instance of Combined represents an A or B data. A way to hide the empty fields would be useful as this can be quite confusing again.
  • adds complexity in setup and data duplication (copies of F# fields from A or B to Combined)
  • does not scale very well if A and B are in a bigger set of modules that need this kind of feature. The result is a matrix of all possible record reference fields of which only one has data, with no way of hiding the others.

I would appreciate any hints on what would be the best approach.
Thank you.

#2

Hi @ami. This is a complex case. Option 1 isn’t ideal if you have a lot of fields. As you state, it might end up confusing for the end user.
Option 2 is better if you want to be able to show a list that contains multiple modules. What you could do here is add an URL field, and fill it with the link to the record page (for example: latest.cortezaproject.org/compose/ns/crm/pages/69058244277960721/record/104852813930037265). The first number is the ID of the record page and the second is the ID of the record. It’s not ideal, but it would save the user a click.

#3

Hi @Lenny,

Thank you for the suggestion. I’ll consider it and see how it is received.

One of my suggestions was to be able to set field visibility based on an expression or predicate. In my mind, we could have something similar to Field value expression which would be computed in the same way to decide the visibility of the field.
Any comments on this?

#4

To be sure: you mean that when a field value expression returns true (for example), that the action could be that the field is hidden from the UI? And, only on record pages, or also in record list in other pages? It’s not a feature we have at the moment.

#5

It is a feature proposal, yes.
The reasoning would be that the record pages would look cleaner especially in cases where a record page actually contains a lot of fields that are the union of several contexts as described in my post.

What I mean is to attach to every field, a visibility boolean expression or predicate, which I suggest it could be similar in implementation as field value expressions are only that this one returns true/false. The result of this expression would dictate if the field is visible or not. The visibility would be in question only in the view mode. Edit mode would show the field always.

I see this easier on a record page indeed.

On a record list it would be also useful but the implications are more complex.
Visibility on a column would be some kind of aggregate over all values of that field in each record in the list for that column. That may be too expensive to compute. One could imagine computing the aggregate visibility value only at the level of visible page, but then it maybe be inconsistent (the column would sometimes appear, sometimes disappear on page change).

#6

This is some functionality that I was looking for also.

#7

me too, still looking for it …

#8

I’m looking forward to.