Uploaded image for project: 'Atlas Module'
  1. Atlas Module
  2. ATLAS-166

Allow more than own owner for a marker

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: TBD
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Complexity:
      High

      Description

      The OpenMRS Atlas should support sites that choose to have more than one person capable of maintaining their markers. The creator of a marker should be able to designate 1-to-n delegates who can also manage the marker(s).

      We don't want or need to create a complicated permission scheme for the Atlas, so, from the users' standpoint, simply having a list of OpenMRS IDs of who can manage the marker as an additional property of any marker would suffice.

      Once implemented, any user in the list of owners for a marker would see the marker just like they had created it (e.g., see the edit option, be able to change any properties, and even delete the marker).

      In the 1.x and 2.x versions of Atlas, the auth table was created to manage authorization of marker changes.

      • A principal represents the person or process (e.g., module) with authority
      • The token represents the optional secret (password or auth token) needed to be authorized. For proper security, the token should be salted and one-way hashed, so even someone with access to the token could not reverse engineer the secret – i.e., the only way to verify a secret is to perform the salted one-way hash and compare the result with the value in the database.
      • The privileges attribute determines the privileges granted to the principal.
      • An expires timestamp is used to allow authority to be granted temporarily – i.e., if not null, this attribute defines when the authority expires.

      One of the design decisions is whether or not being the creator of a marker implies authorization – i.e., can someone who created a marker later forfeit authority over the marker. While this can simplify marker creation (i.e., no need to create a corresponding auth record anytime someone creates a marker). This would mean the creator for a marker would be consider the "owner" of the marker and we would need to allow ownership to be transferred (i.e., changing of the creator, ATLAS-167).

      The types of privileges needed would be:

      • PING – can update stats; cannot modify details (name, description, etc.); cannot change privileges; cannot remove marker
      • EDIT – can edit any details; cannot changes privileges or remove marker
      • ALL – can do anything with a marker, including changing authorizations, changing ownership, or removing the marker

      Someone authenticated as the creator of a marker would be equivalent of having ALL privileges.

        Attachments

          Activity

            People

            Assignee:
            heliostrike Sai Sandeep Mutyala
            Reporter:
            burke Burke Mamlin
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: