Custom column for all tables (home + process instances) - summary field for process instance

[harmeet-status]

Written by @danfunk

This is a request to build a less complete version of the prospectives that already exist and are fully configurable. Some alternatives to consider:

1) Ability to set a perspective as your home page. 2) Consider designing different home pages for different users. New users vs Approval Users vs power users …

[harmeet-status]

Comment from @danfunk

We have to set this higher, because the implications here seem high, the visibility of front page changes is risky - the vetting of these changes with end users seems critical - and the impact on different types of users is of high concern. Esitmating this with the understanding that implimenting it as described will lead to many additional issues.

[harmeet-status]

@danfunk we should discuss this, as I think there is a confusion between what we are thinking.

[harmeet-status]

This ticket sounds similar to https://www.notion.so/8db276d473cd40c39697913b48aa8b12?v=70e34477ed3c415ca9d09e7272d07d60&p=a048b5a92bff4cf683f68c383132966c&pm=s

[harmeet-status]

Comment from @danfunk:

I’ve re-looked at the ticket, and talked it over with the team. While similar, it is not directly compatible with other tickets around the process list refactor, which hopes to create seemless links form the home page to a filterable and adjustable view.

[harmeet-status]

@sashayar13 perhaps we drop this ticket. We already have another ticket to put a filter icon on each table in the home page https://www.notion.so/8db276d473cd40c39697913b48aa8b12?v=70e34477ed3c415ca9d09e7272d07d60&p=7ffd007ae8b74f01a5396cc59c4225b6&pm=s

[harmeet-status]

Comment from @sashayar13

@harmeet-status I'Il suggest keeping the ticket but exclude from the Focus Group. Because the initial requirement is different from the filtering. Let’s see what we achieve with the filtering, and later we can re-assess this ticket

[harmeet-status]

@danfunk is this ticket now already solved by the custom home page demo that @burnettk did last week?

[sashayar13]

@danfunk is this ticket now already solved by the custom home page demo that @burnettk did last week?

@harmeet-status, I think to customise the Home Page, we first need to have the column in the PI table available. If the column is available, then we can add it to the Home page

[harmeet-status]

@burnettk is there a way to do this ticket in less days, I'm thinking some quick solution because we know that we going to do the UI reskin and we can do it properly then.

I wanted to create a new metadata field called _default which is an amalgamation of 2 fields, e.g. vendor + total cost We could write some code at the process model level which creates the amalgamation and displays this in the metadata section.

[burnettk]

@harmeet-status this field, _default, would 1) only be displayed in the metadata section (on the page where you view a single process instance)? or 2) it could be added in a perspective, like existing process instance metadata columns? or 3) you would want it to be displayed in process instance tables by default, like even on the homepage? it does sound very similar to the process instance "title" / "summary" concept that is being discussed in the context of the new UI/UX mockups. i think 1 and 2 are doable today. you would assign "title" as a metadata extraction in the model, and then say `title = f"{vendor} {total_cost}" in a script task. number 3 is probably about 4 days. i'll update the estimate.

[harmeet-status]

Let's call this field process_summary as this is a better name.

This amalgamated metadata would be displayed in 2 places:

1. In the process model details screen, as just 1 of the metadata which is visible
2. On the home page and also process instance details page (this is where you will have to update the endpoint to pass this additional field

In terms of implementation of how we combine the fields, we would want it done in this way:

• If the system finds a process_summary field, then it will display it, otherwise leave as blank
• It is the responsibility of the process architect to map the values of this field. Not sure what is the best way of doing this, especially since we have to consider that this field needs to be updated when the underlying values are updated. Not sure how you would automate this as the process architect can forget to update it we make the updating manual

[harmeet-status]

@burnettk what overlap does this have with the new UI? New UI will also want this.

Can you comment and then I can prioritise it. Ideally if we could build something in the meanwhile, users would love it.

[burnettk]

@harmeet-status it's a big change, applicable to maybe every process instance table in the app, and since we are redesigning that table, perhaps we should just be aware that if we did this before the UI redesign we should make sure that we don't throw it away during the redesign. it does potentially makes sense to decouple them if possible so we don't have to change everything at once.

[tcoz]

Some food for thought:

Say you have a list of something, like ProcessInstances. YOu build a ProcessInstanceList component; it makes its own data calls and so on, you don't have to worry about it, you just drop the component anywhere and bang, there's a process list.

The hell of this approach is that, when it comes time to alter what a given process list displays (and that time always comes), you're affecting every process list in the app. So you have to write a lot of conditional code to hide columns, etc. etc.

This problem goes away if you use a list that just displays what its given. Styling is applied in metadata (column specs, which can be altered dynamically), HTTP calls are made externally by views and the result fed to the child components (like a List), and data is pre-pruned/shaped before passing it in.

This ensures use of the ListComponent is truly abstract and consistent, AND that you can flexibly deal with how data is retrieved/parsed/shaped. Global and per-instance theming can be applied easily (per the mechanics of the component and design system). Avoid subclass/wrap lists as components bound to a data schema; in UIs that rigidity always ends up biting you. Flat/shallow via view controller composition is the way to go.

In the "old" UI, I see the above playing out (there is a ProcessList list, which calls for data, processes and shapes it, etc.). I wouldn't port that component (or the approach) to the new UI. I'd just say, "here we are in the home view. Let's get the process instance data based on some parameters, then run it through a processing pipe. Looks right? Now, let's feed it to the List."

[harmeet-status]

There is work involved here to build the "summary" field in the process models.

[harmeet-status]

We also have process model work to complete as part of this. Need to create the field which will get referenced in the table.

https://github.com/sartography/spiff-arena/issues/1578

[calexh-sar]

@harmeet-status back-end work on this issue is key to moving the UI work along. Can this issue be prioritized higher?

[harmeet-status]

Yes let do this sprint!

[madhurrya]

@burnettk is there a way to test this? If not can I close this?

[burnettk]

use spiff_process_instance_summary = "whatever you want" in a script task, and then you should be able to see this value associated with the table rows in the new ui.

[madhurrya]

I added it here https://mysql.spiffcrm.com/editor/process-models/misc:qa:madhu-testing:temp-model1/files/temp-model1.bpmn and ran it. But I don't see it in https://mysql.spiffcrm.com/newui Doesn't the newui get auto populated with the latest data?

[madhurrya]

I think I didn't see it because the new UI doesn't show the completed ones. I checked without completing the instance and now I see it in the new UI and I see the summary field also

[madhurrya]

Will do further testing related to this when the new UI is implemented. Since the basic is working closing this ticket for now.