Bug: When updating event, don't allow quantity change

[fosterlynn]

We shouldn't allow changing the quantity (resource or effort) on an event, and some other things too, from https://lab.allmende.io/valueflows/valueflows/-/wikis/Application-specification-guidance#validations:

"cannot be updated: resourceQuantity, effortQuantity, atLocation, inScopeOf, resourceConformsTo, resourceInventoriedAs, provider, receiver, action, hasBeginning, hasEnd, hasPointInTime, inScopeOf (these properties could have affected reported accounting; use another economic event to make corrections)"

We may not want to be that strict, or very strict at all in a "play space". But if we allow quantity to be updated, then there is extra logic to update the resource, which I don't think we want to do. Let's discuss the other fields.

[adaburrows]

Ah, this is a discussion we haven't had yet about what I was thinking. Also, we have reached a point of tremendous complexity in the UI logic and until I refactor everything so the logic is composable and state machine based, I don't want to change anything in that logic (this will be done after the current tech debt milestone).

1. The values entered are not actually saved until the whole set of objects is saved for the first time, this means if you "create" a new event and then "save" it, it is temporarily created as an object in memory only in the flows form. You can go back and edit that in memory object as many times as possible.
2. When you save the Flows form, those objects are stored in the in memory indexed tree and written out to the "project" zome.
3. We are not checking to see if something is in the state of already being created because of a weird quirk of the playspace: all accounting is done in memory and recomputed each time something changes.
4. Because of this, we never actually save any EconomicResource quantities to the data store, they are always computed from the complete list of their events (and will be computed from the graph order once that data structure is in place).
5. This gives us tremendous flexibility around editing anything we want at any time we want,
6. I was thinking about adding an ability to have something akin to a "save" button on the workspace. This would write things out permanently and at that point, things could not be undone (just as it is in hREA), partly because I was thinking that would be how we transfer things over into hREA. Then anyone could fiddle with things until the got it right, then they could save it out to hREA without fear of having to correct those mistakes in a very public way.
7. In this case, there is no extra logic to recompute the value, because our non-standard implementation already works more like a spreadsheet (data flow) than anything else.

[fosterlynn]

We may not want to be that strict, or very strict at all in a "play space".

I can see that it would be good to clarify in the doc that this set of rules on updating and deleting events is for anyone who will use this for accounting. (That validation section isn't in the formal doc yet, but will be at some point.) If you aren't going to run any reports ever, then it may not matter if you change things. If you are, then as of the report, things are cast in stone from an accounting rules standpoint, and an app can never tell when someone ran a report.

The "update vs really update" has some layers to it if we decide to let things be loose in playspace.

Anyhow, this is a big discussion.

[edit] Maybe in the meantime, we never allow update of quantities, and we can look at the rest of the list above. If people are in that in-between state where they still can theoretically change it because its not in the actual datastore, maybe they need to cancel and start over. That could be a somewhat smaller discussion perhaps.

[adaburrows]

As a result of the tech debt stuff, this does automatically update everything in the Resources page when quantities are updated. At this point in time the easiest course of action is to keep it playspace-y until accounting reports are done.

Do you think that enforcing that is worth it at this point in time? Like should we be training users to think it's permanent? Or can we let people have the spreadsheet experience of being able to play around?

It wouldn't be difficult to add the code to make specific checkpoints that invalidate the data if it's modified afterward. For instance, we can make a signature of the data up through the generation of certain reports and a correlated list of events included. Then if anything in the data changes it would no longer be valid. I frame it this way, because currently anything can be changed in the browser and only adding hREA would make sure that isn't the case.

[fosterlynn]

Do you think that enforcing that is worth it at this point in time? Like should we be training users to think it's permanent? Or can we let people have the spreadsheet experience of being able to play around?

I don't know. I'm fine with leaving it loosey-goosey for now, and get more experience with it.