expected: sorintlab/sirclesdemo
actual: alectolytic/sirclesdemo

EDIT:
The actual repo was created because the original one was missing:
From https://hub.docker.com/r/alectolytic/sirclesdemo/:

A demo container based on upstream demo. Created as the official one was unavailable.

https://github.com/sorintlab/sircles#quick-start-using-docker

Any ideas why?

It'd be handy to have a demo/preview of the UI in the in the Read Me for those of us who find sircles on mobile.

@sgotti We want to disable the user when he doesn't work anymore in the company.
We have thought different ways:

-Creating a new column in the database with a check if he still works or not. Then in the query, when we request the member, we have to control if this column is checked or not.

-If there is already in the database a column with something that allows to know if he is working or not we can use it. For example if there is the contract expiration date we can compare it with the current date and disable users with the date lower than it.

This issue is to track changes needed to make sircles a real CQRS application.

The unique thing that we'll do differently is to handle all events and related generated commands and events in an unique transaction. For example: when a circle is deleted, an event handler will handle this event and create commands to every tension associated to that sircle to unset it. We'll handle all this in an unique transaction. The reason is dictated by the features required on the read side: since we provide a timeline based navigation, we want to provide a consistent view for every timeline. For doing this we have to group under an unique timeline all the related changes. So this is done only for the above reason, the command part will able to work and converge to a consistent state also without doing it in an unique transaction.

• Remove the timeline "aggregate", it doesn't make any sense and the timeline concept can be managed only on the read side using the events correlationid.
• Remove the commands aggregate, it doesn't make any sense. Just log the commands.
• The aggregate implementation, if needed (for aggregates with many events like the rolestree), will use its own snapshot implementation instead of using the readdb.
• The readdb will apply the events in a separate transaction.
• The eventstore now is a fully serializable event store: it accepts one change at a time and fails the transactions having serializabale errors (this is a property enforce by the db using a serializable isolatioon level). This isn't a big problem given the write ratio but we can make it able to accept concurrent changes to different aggregates.