I firmly believe in free software.
The application I'm making here have capabilities that I've not seen in
any system. It presents itself as an opportunity to collaborate on a
tool that serves the people rather than corporations. Whose incentives
are to help people rather, not make the most money. And whose terms
ensure that these freedoms and incentives cannot be taken back or
subverted.
I license this software under the AGPL.
Allow a shift to have no role associated with it in order to simplify
conflict resolution around situations like a shift being created while
the role it was assoiated with was deleted. This also allows for shifts
that are freestanding to be created in case having a role doesn't make
sense for it.
Vue's proxy handling interferres with the new Set methods causing them
to throw a TypeError when used on Set objects that are replaced by
proxies. Workaround by dropping the proxy when using these.
See https://github.com/vuejs/core/issues/11398
When editing the slots of events and shifts there are certain situations
where the event or shift a slot should belong to becomes unclear or
difficult to reliably assign. For example when adding a new slot in the
UI it may be desirable to do so before the user has input the event
or shift the slot should belong to.
In these cases, not being able to store the slot into the schedule makes
the UI logic needlessly complicated. Allow slots to be added that do
not have its assiated relation linked up to make editing and handling
such scenarios easier.
Rename the base Entity type to ApiEntity, and the base EntityToombstone
to ApiTombstone to better reflect the reality that its only used in the
API interface and that the client and server types uses its own base if
any.
Remove EntityLiving and pull EntityTombstone out of of the base entity
type so that the types based on ApiEntity are always living entities and
if it's possible for it to contain tombstone this will be explicitly
told with the type including a union with ApiTombstone.
Refactor the types of the ClientEntity and ClientMap to better reflect
the types of the entities it stores and converts to/from.
Use a single mutable location, event, slot, etc, for each unique
resource that keeps track of the local editable client copy and
the server copy of the data contained in it.
This makes it much simpler to update these data structures as I can take
advantage of the v-model bindings in Vue.js and work with the system
instead of against it.
Use the ClientSchedule data structure for deserialising and tracking
edit state on the client instead of trying to directly deal with the
ApiSchedule type which is not build for ease of edits or rendering.
Implement tracking of time slots along with editing and restoration of
singularly edited time slots. This provides a simpler interface to work
with when rendering tables of time slots that can be edited than
directly manipulating events and shifts containing an array of slots.
To determine if the entity received from the server is the same as the
entity the client has the equals method is use. To avoid problems with
clients that have incorrect clocks the timestamp is overriden with the
server's time when the entities are saved on the server.
This means that the entities received back from the server when the
client saves will have different timestamps than what the client set.
Ignore the updatedAt timestamp when comparing entities for equality so
that the update logic correctly replaces entities that only differ by
the update timestamp.
If the event/shift that a location/role was referencing had been marked
for deletion the sanity check would incorrectly refuse to delete the
event/role. Fix by ignoring deleted events/shifts.
Add utility methods to more easily edit the fields of a single entity in
the schedule, along with a modification flag and is modified utility to
check for changes having been made.
The Vue Ref system and assiated proxies does not work with the native
EcmaScript private fields, replace them with the TypeScript access
modifiers which are regular fields under the hood.
Write the logic of keeping track of location modifications and applying
updates from the server into the ClientSchedule class. This should
serve as the foundation for replacing the prototype in-component update
logic which have turned into an unmaintainable spagetti.
