Skip to content

Overview of design: read-only / editable databases and activities #7

@tmillross

Description

@tmillross

This is a brief description of the design plan for distinguishing when the interface is read-only and when edits can be made by the user to particular activity-related fields. Design adheres to to #6 and addresses ideas on "separation between data exploration and editing" raised here. The more detailed behaviour in psudocode is described in subsequent issues.

  1. Two layers of protection from accidental user data edits: at the [project&]database level, and the activity level
    a. When database is set to editable, the user then has the ability to set a specific activity to editable
    b. Once activity is editable, user interface data modifications are synced with the activity database (usually JSON file) in real time: the state of the interface is always consistent with the data state in memory or on disk
    c. Thus, there is no “save” button required (or associated extra user click-action)
  2. A user may still make a change to a field accidentally once the fields are editable
    a. Under this circumstance, they can identify that this change has been made
    b. And ideally be able to undo/revert the change, either automatically or manually

Behaviour as experienced by user:

  1. In database list, a checkbox in column “Read Only” is visible, default = checked
    a.The rows are colour-coded OR show a padlock icon, which is unlocked or locked.
  2. When read-only, no changes can be made to any data within that database. This includes:
    a. Editing existing activities
    b. Adding new activities
    c. Adding new biosphere flows
  3. On open activity panels (on the left), a checkbox: “Read Only” is visible, default = checked
    a. The checkbox is ‘greyed out’ when the database the activity belongs to is read-only
    b. A tooltip informs the user why it is grey
    c. When unchecked (clicked) for a visible (open) activity, specific data fields in the tables below become editable
  4. Changed data is recognisable and reversible as described in Tracking GUI changes to activity data #10

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions