OpenEnergyPlatform / oeplatform

Repository for the code of the Open Energy Platform (OEP) website. The OEP provides an interface to the Open Energy Family
http://openenergyplatform.org/
GNU Affero General Public License v3.0
61 stars 19 forks source link

adding locking mechanism for entities #1609

Open h-spinde opened 3 months ago

h-spinde commented 3 months ago

Summary of the discussion

As mentioned in Issue #1504 , I added a locking mechanism so any entity currently being edited gets locked from being edited by other people. Specifically, this locking mechanism kicks in when one klicks the "save" button after entering data into an input-field related to the entity. An error message is currently not being displayed, as I edited only the backend, not the frontend. Furthermore, when editing for example an institution, the insititution label is always displayed as though it had been changed in the current tab - even when the edit is not saved (due to the entity being locked at the time of attempting to edit it). See here: after-editing-locked-entity That the change has not been saved only become apparent if one leaves the current bundle, returns to scenario-bundles/main and then selects the bundle again: after_editing_locked-entity-2.png

Technical Explanation of the changes made: In factsheet/models.py I added a new table for tracking which entities are currently locked. In factsheet/views.py I added two new functions: acquire_lock and release_lock. acquire_lock checks if the entity someone is attempting to edit currently has an entry in the new "LockTable" table. If there is no such entry, the function generates a new entry and returns True. If there is such an entry, the function checks whether the existing lock has already timed out. If the lock has not yet timed out, the function returns False, since the entity is considered locked. If the lock is timed out, the function overwrites the old lock with a new one and returns True. release_lock deletes a lock once the entity it applies to is no longer being edited. The "update_an_entity" function was changed to first call the "acquire_lock" function and only update the given entity if acquire_lock returns true (so if the entity is not already locked). Otherwise, it prints "Entity currently being edited!" Once the entity was successfully updated, update_an_entity calls "release_lock".

Type of change (CHANGELOG.md)

Added

Updated

Workflow checklist

Part of #1504

PR-Assignee

Reviewer

jh-RLI commented 3 months ago

Hey @h-spinde, great to see your contribution. You also have to push the django migration you created by running django manage.py makemigrations . There should be a file factsheet/migrations/0012_locktable.py this needs to be availabe otherwiese the tests will not work.

h-spinde commented 3 months ago

Hey @h-spinde, great to see your contribution. You also have to push the django migration you created by running django manage.py makemigrations . There should be a file factsheet/migrations/0012_locktable.py this needs to be availabe otherwiese the tests will not work.

Thank you! This was in fact enough to pass all the failed tests.

jh-RLI commented 3 months ago

@adelmemariani could you start to review + test this? I will also test it soon. I think if we both agree this works as expected we can merge it.

I think what is missing is the integration into the UI. The user should be able to see these "server" messages aka prints on the OEP-Website.

After that it would be grat to try it out on the TOEP.

jh-RLI commented 3 months ago

I think we should also add a test for it (assertion), then we can be sure that future changes to the code will not affect this functionality.

Also, I think we can move some of the functionality out of views.py to keep it cleaner as it is already very bloated. We can discuss where exactly the code goes. This is not immediately necessary.

jh-RLI commented 2 months ago

I will change this to "draft Pull Request" until it is ready to be merged :)