Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requesting edits to public entries #181

Open
1 task
dandavies99 opened this issue Oct 12, 2022 · 0 comments
Open
1 task

Requesting edits to public entries #181

dandavies99 opened this issue Oct 12, 2022 · 0 comments
Labels
backend related to the backend enhancement New feature or request frontend related to the frontend permissions to do with roles, permissions, guardian etc.

Comments

@dandavies99
Copy link
Contributor

dandavies99 commented Oct 12, 2022

Problem

There are good reasons that most data types cannot be edited by normal "contributor" users after they've been made public. The main reason is that other users can include the entries as related objects for their own entries - e.g. a common anode component may be used by many different users to define different cells (devices). If the component were possible to edit, the change would affect all the devices.

It would be useful to have some mechanism to safely change these after being made public though. E.g. if a mistake was made, or if additional parameters need to be added.

Proposed solution

High-level:

  • From the frontend point of view, it would be useful to have an edit button appear as usual, then a "request changes" button. This would send the requested changes to a database maintainer for approval or rejection.
  • Some view will be required for the maintainer to approve or reject the changes, at which point the actual object is updated.
  • It would probably be good to first implement Improved object history tracking #73 first. That way, if some change is made that does cause confusion, users can see what changes were made and when to work out what went wrong.

Possible workflow:

  • "Request changes" creates a copy of the model with the updated fields.
  • In the database maintainer view if the maintainer clicks "approve":
    • The actual original model is updated according to the fields on the temporary model
    • The temporary model is deleted
  • If the maintainer clicks "reject":
    • No changes are made and the temporary model is deleted

The above workflow would possibly require a new simple model that links the temporary and original objects, e.g. ChangeRequest. This is created when "request changes" is clicked and is deleted along with the temporary object when changes are approved or rejected by the maintainer.

Possible blockers

  • Would any unique constraints within the underlying model get in the way of the temporary objects being created? e.g. if no two devices could have the same name, the temporary object wouldn't be allowed unless the name field was being changed.

Aha! Link: https://imperial-college-ict.aha.io/requirements/RSE-138-6

@dandavies99 dandavies99 added the permissions to do with roles, permissions, guardian etc. label Oct 12, 2022
@dandavies99 dandavies99 added this to the Milestone 2a milestone Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend related to the backend enhancement New feature or request frontend related to the frontend permissions to do with roles, permissions, guardian etc.
Projects
None yet
Development

No branches or pull requests

1 participant