Architecture question for dynamic 'my actions' list

Question

I am looking to create a "my actions" block on the dashboard of the website. This block would include all sort of dynamic actions that the user needs to do.

Some examples are:

• The volunteer still needs to sign volunteer contract 1
• The volunteer still needs to sign expense note 1
• The volunteer still needs to sign expense note 2
• ...

There will be a fixed list of all the different actions that can appear inside the actions list, they will never be created by the user itself, but always by the system. The user will then be able to complete the action directly from that actions list (by clicking on it). Or from some other parts of the site (e.g. for the document signing, it can also be done from the documents page).

We also want a history of all the actions that the user completed (with a timestamp).

Is it a better idea to calculate the "still to do actions" in real-time (i.e. every time the user opens the page). It seems so, since the actions could change over time (e.g. the organisation deleted the volunteer contract, hence it doesn't need to be signed anymore). Or would it be better to keep every action in the database, and keep this in sync with the CRUD operations done on each entity?

Is there anyone who can give insights, or has already done a project like this? I am running blank in searching around for projects like this, since it always ends up at a simple "todo list".

My stack is VueJS + NodeJS + MariaDB.

Answer 1

Is it a better idea to calculate the "still to do actions" in real-time (i.e. every time the user opens the page).

Yes.

Consider this scenario:

1. The "still to do actions" list contains an action 'sign document X'
2. The user goes to the documents page and signs document X
3. The user navigates back to the dashboard

How clumsy or professional would it look if after step 3 the newly loaded dashboard page still shows 'sign document X' as an action that has not been completed?

Or would it be better to keep every action in the database, and keep this in sync with the CRUD operations done on each entity?

This does not contradict the recalculation of the "still to do actions" list on page load.

Is there anyone who can give insights, or has already done a project like this?

I would approach this with 2 tables.

• 1 table with the possible actions that the system can add to the list. This table contains information like the text to show, the URL to provide in the "still to do actions" list, etc.
• 1 table containing a user-id, an action-id and a completion timestamp. This table would hold both the completed actions (with a non-NULL completion timestamp) and the actions that need to be performed (with a NULL completion timestamp).

The "still to do actions" list would show the entries from the second table where the completion timestamp is not filled.

When the system detects that a particular action has become relevant for a user to perform the action, the system can add an entry to the second table with a NULL completion timestamp. When the system detects that a user has performed an action, it can update the table by setting the timestamp for the relevant action.
As the "still to do actions" list looks for entries without a timestamp, both actions cause the list to be updated automatically.

Answer 2

calculate the "still to do actions" in real-time (i.e. every time the user opens the page)

Yes

Or would it be better to keep every action in the database

This is not mutually exclusive to the above; unless maybe "keep" means something else?

and keep this in sync with the CRUD operations done on each entity

You lost me

---

Update dynamic state every time any dependent state changes.

A business model - a OO class design - does this.

• Observer Pattern (event handling): UI changes update the business model and the model calculates state. The UI is refreshed.
• The database merely keeps the business model data. Design the data store update triggering any way you want.
• The business model calculates state before it updates the UI or the database. Initial population vs active user changes? Irrelevant.
  • UI --> BM calculate state --> UI
  • UI --> BM calculate state --> Data Store
  • Data Store --> BM calculate state --> UI

---

Separation of Concerns

We all violate this all the time. Like Capitalize a name directly in a textbox. That's ok if the business model has that rule also.

Putting rules in the database is more hazardous. Like populating a new form with all zeros. Then the customer says "I want forms X, Y, Z to be blank, not zero. Had to write a new, virtually identical stored procedure just for those. But the new rule was in the BM you say? Does not matter. Blank fields are saved with zero. Now, is that a zero-zero or a blank-zero?