User Permissions and Editing Constraints

[robHitchcock]

User permissions and editing constraints need to be defined and enforced in the Manager.

1. BEDES approved atomic terms - by version. a. Regular users can search the current version dictionary of approved atomic terms. b. Admin users can create new and edit/delete existing atomic terms (including list options). New and modified atomic terms will be flagged as pending until the next official BEDES version release. Alternatively, a working copy of the current version release could be edited by Admin users separately from the current version. This would mean that all new application mappings (see below) can only be mapped to the current BEDES version.

2. BEDES approved composite terms a. Regular users can search the current list of approved composite terms. b. Admin users can create new, edit/delete existing composite terms, and approve user-defined composite terms. All modified approved composite terms must be created as new composite terms, leaving the original approved composite term untouched in case it has been referenced in application mappings.

3. BEDES user-defined composite terms a. Regular users can create new user-defined composite terms and edit/delete existing user-defined composite terms that they have created. Regular users cannot see or edit user-defined composite terms that other regular users have created. b. Regular users can search the current list of approved composite terms and user-defined composite terms that they have created. Regular users cannot see user-defined composite terms that other regular users have created. c. Admin users can view and approve/reject user-defined composite terms.

4. Application mappings: matching between application terms and BEDES terms a. Regular users can view the current list of approved application mappings. b. Regular users can create new user-defined application mappings, referencing approved atomic and composite terms and user-defined composite terms that they have created. Regular users cannot see or reference user-defined composite terms that other regular users have created. c. Admin users can create new, edit/delete existing, and approve user-defined application mappings.

[TravisWalterLBNL]

In 4. b., I think the last sentence should be "Regular users cannot see user-defined application mappings that other regular users have created.

[jateeter]

These use-cases (or workflows) are well articulated - thx Rob.

re: 4.b - I believe there should be both Public and Private applications. I certainly think that ESPM mappings are essential to "inherit" into my domain specific terms. As in ESPM will have an application term that maps to a specific composite term and I want my application terms to be be able to map, if desired, to the same composite terms. If you just make the composite term available (through anointing it as an "official" composite term), you will only solved half of the problem.

[jateeter]

re: #1 - I think we need not take such a "waterfall" approach to the management of the dictionary. I do like the approach of allowing certain aspects to be "provisional" and that a rigorous process (workflow) be defined to support the nomination, evaluation, and acceptance of new atomic terms, enumerations, and composite terms, but I don't think we should necessarily gate "versions" on a long cycle. I'm more in favor of a wikipedia approach (management at the granular level) and as much crowd sourcing (and low organizational inertia) as possible.

[jateeter]

re: #2 - I agree that in general mutations of existing composite terms should not be allowed as it side effects existing application term mappings. So a policy of "monotonic information growth" (as in an existing composite term is never mutated, but rather is left intact and a new "version" of the term is created) would be great. The disposal/archival of historic entities in that mutation chain introduces a new workflow/use-case.

[TravisWalterLBNL]

From an implementation point of view, it might be easier to fix issue #31 along with this one, rather than adressing them separately.

[robHitchcock]

Based on 3/20/2019 scrum discussion - I believe sections 3 and 4 need to be modified as follows (text in bold or surrounded by double asterisks to be deleted, text in italics or surrounded by single asterisks signs to be added):

3. BEDES user-defined composite terms a. Regular users can create new user-defined composite terms and edit/delete existing user-defined composite terms that they have created. Regular users cannot see or edit user-defined composite terms that other regular users have created. b. Regular users can search the current list of approved composite terms and user-defined composite terms that they have created. Regular users cannot see user-defined composite terms that other regular users have created. c. Admin users can view and approve/reject user-defined composite terms. d. All composite terms will be flagged as "approved" or "not approved" so that users can easily ### see which are which.

4. Application mappings: matching between application terms and BEDES terms a. Regular users can view the current list of approved and user-defined composite terms to create application mappings. b. Regular users can create new user-defined application mappings, referencing approved atomic and composite terms and user-defined composite terms that they have created. Regular users cannot see or reference user-defined composite terms that other regular users have created. c. Admin users can create new, edit/delete existing, and approve user-defined application mappings. d. All application mappings will be flagged as "approved" or "not approved" so that users can easily see which are which.

5. To track and display these differences, we suggest the following conventions and flags: a. Use a Scope attribute for both Composite Terms and Application Mappings (by which is meant an entire set of Application Term to BEDES Term mappings, not the individual term mappings). The Scope attribute should have the following enumerated options: user-private, user-public, BEDES. User-private means user-defined and not intended for viewing/editing by other users. User-public means user-defined and able to be viewed/edited by other users. BEDES means approved by the BEDES Team and viewable, but not editable by other users. b. For Composite Term list and search results lists a default setting should be to show (filter) only BEDES and user-public. Not user-private. (filter setting can be changed in list and search options) c. For Application list a default setting should be to show (filter) only BEDES and user-public. Not user-private. (filter setting can be changed in list options).

THESE CONVENTIONS NEED FURTHER DISCUSSION WITH MIKE TO ENSURE WE UNDERSTAND ALL CONSEQUENCES AND CAPABILITIES!

[TravisWalterLBNL]

When labeling composite terms, the terminology should be "BEDES Composite Term" or "User Composite Term", as indicated in issue #31.

[TravisWalterLBNL]

We've been changing our minds on this a few times, so here is the most recent specification:

These are the columns we should have and the values they can have in them: Owner: me, other-user-1, other-user-2, etc. Status: Public, Private, Approved Term Type: Atomic Term, Composite Term, Constrained List Option Data Type: Constrained List, Constrained List Option, Decimal, Integer, etc.

The term search results and the list of composite terms should have all 4 of these columns. The list of applications should only have owner and status.

The default status is private. Setting it to public allows all other users to view the term or application, but only the owner can edit it. When making something public, the owner's user name will be shown (as opposed to allowing the user to be shown as anonymous).

The default view in the term search results, list of composite terms, and list of application terms should be to show all items owned by me and all approved items. Items owned by others that have not been approved should not be shown by default, but there should be a way to show them easily. This should be done using a filter on the list of terms/applications.

Once a term or application has been approved, it's status should change to approved and it should no longer be able to be edited. Approving an application means also approving all the composite terms used in that application.

There should be an easy way to duplicate an existing application (so that someone can modify and approved application without having to re-map every term).

[mspears-lbl]

Composite term permissions as described should be up and running now. Will update the application permissions and all of the tables as described above in the next up date.

[TravisWalterLBNL]

I experimented with the newest version of the mapping manager, and I noticed a few things:

• In the composite term builder, when I click on Import BEDES Terms and search for a term (e.g., "title"):
  • The term type column has "BEDES Term". The allowable term types should be Atomic Term, Composite Term, and Constrained List Option.
  • There are blanks in the Data Type, Owner, and Status fields. Everything should have an owner and a status. If the term type is constrained list option, the data type should be too.
  • The status column should be called "Sharing".
• When I search for terms from the main page:
  • The "Type" column should be called "Term Type".
  • The owner and sharing columns are missing.
  • The type column has "BEDES Term". The allowable term types should be Atomic Term, Composite Term, and Constrained List Option.
• In the composite term builder, it looks like the visibility menu is letting me choose to make a term approved. Is this option only available for me because I'm a superuser/admin? A normal user shouldn't be able to make their term approved.
• In the list of applications, I see several that are owned by other people but are private. Am I seeing these because I'm a superuser/admin? A normal user shouldn't be able to see another user's private applications.
• In the list of application terms, are there supposed to be owner and status columns? I thought these were only supposed to apply to composite terms and to entire applications, but not the individual mappings between application terms and composite terms.

[mspears-lbl]

Made some updates to the various tables, everything except the Search for BEDES Terms table.

Other issues were because you had an admin account. I changed all of your admin accounts back to normal accounts, will provide details on the bedes admin account.

[jateeter]

[TravisWalterLBNL]

In the 'Search for Terms' results:

• The 'Type' column should be called 'Term Type'.
• The 'Category' and 'Unit' columns should be removed.
• There should be 'Owner' and 'Sharing' columns.
• In the 'Name' column, constrained list options should be listed as: ': '.

In the list of composite terms and application terms, the 'Sharing' column should only have 1 of 3 values: 'Public', 'Private', or 'Approved'.

In the 'Application Options' dialog, the 'Scope' field should be called 'Sharing'.

[TravisWalterLBNL]

In the "Search for BEDES Terms" results and in the lists of composite terms and application terms:

• The "Sharing" column should only have "Public", "Private", or "Approved". Things like "Approved - for use in all applications" and "Public - use limited to ..." should be truncated.

In the "Search for BEDES Terms" results:

• When I search for "energy", I see a composite term that is private and not owned by me. It has a really long name: "Energy Software Tool Energy Software Tool Version Energy cycle draw Building Energy Code Year Building Energy Code Or Standard".

On the "BEDES Term" screen for a constrained list:

• In the table of constrained list options, didn't we decide there shouldn't be "Data Type" or "Unit" columns (since the data type is implied and the unit is never applicable)?
• For the constrained list "Climate Zone", I was able to edit several things (URL, Data Type, the list options themselves). I shouldn't be able to modify atomic terms (at least until we start letting people make their own).

[TravisWalterLBNL]

In the composite term builder, the "Visibility" field should be called "Sharing", and the values should be "Private" and "Public", not "Public - use limited ...".

[TravisWalterLBNL]

In the composite term builder, if I have some terms owned by me and some owned by others, they all have the magnifying glass icon, but only mine have the X icon. This makes sense (I can only delete mine), but it messes up the horizontal alignment of the term names. The terms that aren't mine should have an extra invisible/inoperable icon that ensures all the term names line up.

[robHitchcock]

1. Owner and Sharing are not populated for Application Mappings to Atomic Terms.
2. User should be able to edit Sharing of overall Application Mapping between Private and Public (but not Approved) See attached screen shots for examples. Issue35.docx

[robHitchcock]

We need to revisit this issue and sort out what has been addressed and what still needs attention. And start separate new issues to obviate this too long issue thread.