> 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 ever 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???!!!!