kgrid/kgrid-library

The Object Library protects and supports management of Knowledge Objects, making it easy to access and deploy them.

kgrid-library's Issues

Object Detail Page - Versioning

1. Additional fields for versioning
2. Improve the object rendering model to remove the constraints currently imposed on the backend

ObjectTeller header fixed-top offset is off for logged-in state

Check the fixed-top trigger offset for before&after loggin in

(Rebranding) Home page - Object tile style

1. hover state;
2. font;
3. Indicators.

Add info to /health endpoint for adaptors

Add list of activators to /health

Front end check-up and improvement

App Level:

1. If not logged in, bypass the user/me check;

LIbrary Operation

1. Add library setting UI and enable the connection from externalized configurations;
2. Layout improvement, make corrections for window resizing;
3. Improvement of library user management overlay;
4. Add Import/export Object;

User Management: (pending backend)

1. Add sign-up UI;
2. Add request password reset UI;
3. Add password rest UI.

Object Level:

1. Plan for adding UI element to handle publishing use case;

Misc.

1. Styling, js improvement and cleanup

(Rebranding) NavBar

1. Add 'Sign up' button
2. Move server name to the navbar
3. Add buttons to the user dropdown

(Rebranding) Extract common styles from components

Common style to be extracted:

1. Header list for tab - font, hover state;
2. Dropdown menu list - font, hover state;
3. Buttons - primary, secondary, hover state;
4. Hyperlinks - font, hover state;

Additional:

1. vue-datepicker will need to be customized to comply with the style guide;
2. Overlay is pending

Add basic access control to Library

This is about authorization. See #11 for authentication

• User access to objects for create, edit, delete, view
• Use only the existing auth method (session based) with login and local database

(Rebranding) Object Detail Page - Action list

1. Use icon with caption when hovered;
2. move to banner area;
3. Style pending

(Rebranding) Home page - Filter panel

Filters display will be moved to above the overall Filter control panel.

(Rebranding) Object Detail Page - part 1

1. Remove back to library button; (Use browser button);
2. Change the Public/Private to dropdown;
3. Change the styles for the text

Pending the finalization at 7/22 meeting

(Rebranding) Object Detail page - Editor initiate with active tab

Initiate the editor with the active tab consistent with the tab in view

Library shows a cached object or a blank page for non existing object

In a new browser or incognito tab open a non-existing ko (e. g. https://library.kgrid.org/#/object/ipp%2FNonExistingObject) to get the blank page.
Open a library and click on an existing KO. Then try the non-existing one to get the previous ko showing.

Add "versions" to the front end

A rough, MVP implementation of the core feature set around versions to let folks play with it in the library front end

Part 1

• View a list of versions for a particular object (expand a KO on the master list? Version slider from the KO detail?)
• view detail of a particular version
• Add and delete a version (simple user entered version string, maybe default to "patch increment)
• copy url for a particular version

No need to put a lot of constraints in but add and copy should fail if that ARK/version already exists

Part 2

• Copy a version of a KO from an external library into this one

No need to put a lot of constraints in but add and copy should fail if that ARK/version already exists

(Rebranding) NavBar

1. Change the styles for the navbar items;
2. Change the hover state for the nav bar;

Expected to be done 7/20

Library user authentication (epic)

This is not about ko association with users/owners/collaborators). It's about managing a users account with a particular library

Sooner

• Allow users to change their own password via edit profile and/or reset password workflow
• allow "forgot my password" resets via email

Later

• Add "remember me" capability. Not sure if this is needed soon....
• Allow users to authenticate with GitHub. Maybe allow access to collections/objects based on project/team membership. Compare this with providers like Auth0. Not needed soon.
• Allow users to authenticate with an account in a different library. Possibly this could mean an account at the "grid level" would allow authentication as a "user" to any "public" library, though not necessarily with elevated privileges. This might mean that a user has access to her own items (as owner, collaborator) and maybe the ability to import and/or create new KOs. Lots of work to model this correctly at the grid level

Delete history for all config credentials

Provide server-side application authentication (via Oauth)

Use an authorization grant or access token (see GitHub api docs for examples)

https://github.com/settings/tokens
https://github.com/settings/developers
https://developer.github.com/v3/oauth/

Date/time values are date only

fedora says:

fedora: created
2017-08-17T14:29:37.052Z
fedora: lastModified
2017-08-17T14:29:37.052Z

The API (/knoweldgeObject) returns:

"lastModified": "2017-08-17T04:00:00.000+0000",
"createdOn": "2017-08-17T04:00:00.000+0000",
"

I turned on automatic formatting of dates to test by adding this to my local, external application.properties file:

spring.jackson.serialization.write-dates-as-timestamps: false

Migrate the build package to Webpack 2

Webpack 1 has been deprecated. The build configuration needs to migrate to Webpack 2 to use some modules of the latest version.

provenance - log key user/system operations on individual KOs

Only create is logged now. We need the logging of key user and system ops like create , update, publish, delete

there is a separate issue for logging usage (checkin, checkout, updates, pub/sub scenarios, etc.)

Add in-app user help & means to manage in-app user help content

Split this issue into in-app help for different activities in the Library. Going forward we will just add/update/revise help as part of each story

Add FHIR mapper

To map FHIR resources to 'standard' ko parameter map.

In the long run we may need a set of mappers to go from various standard input formats to a ko-specific paramater format (could be a simple map or json-schema-style input.)

The needs of a ko are much simpler than the needs of the full execution stack model, which includes verification, type-checking, metadata about the ko and it's execution environment. The actual input to a ko is a transform of the input using the rules defined by the i/o spec and possibley ko metadata

Also, need mapping of outputs to FHIR

Library import/export

rename/reorg OT repo to "library"

Remove all "Object Teller" naming in code, site, docs, etc.

User authorization for KOs (epic)

• Update the kgrid model to make user (owners, collaborators) a first-class entity in the kgrid model, esp. in the fedora model

• move users into fedora (arkIds? Other ids? currently using email for lookup and synthetic id). Perhaps move the "user profile" to fedora with all the associations but leave the identity/authentication outside. I.e. you have an account with the library and can log in, but what you can do depends on the additional roles and associations in your profile.

• Associate and users (collaborators, owners) to KOs. This implies a simple "owner/editor/user" model for KOs (NOT the same as the roles for administering the library.)

• Add "my objects" capability (this is just to get familiar with the necessary queries/handling for the person <-> ko associations)

• Integrate with "public/private" model. Can see public objects but only "my" private objects

• Update the /user api and /ko api to handle missing, unauthorized, and otherwise unattainable KOs correctly as resources, e.g. 401, 403, etc. as http status with appropriate error messages

• Work out how to grant access to other applications, specifically SPAs (probably session-based is okay) and execution stacks (public only? user/collection based auth keys? Don't know)

Add management/actuator endpoint security

Probably just add an externally configurable basic auth administrative user, with a commonsense default

might need to update the spring boot security configuration

externalize library settings, user db, identity service

From @pboisver on January 18, 2017 19:31

These are going to be read only configuration settings. Includes the database settings, for user repository. Also includes base URL of the fedora instance, and/or maybe separate urls for the repo, fuseki, solr, etc.

As always, sensible defaults or make them required.

Provide an endpoint the reports the settings, appropriately secured.

Copied from original issue: kgrid/kgrid-activator#2

(Rebranding) Overlay Layout

1. CTAs will be moved to the bottom of the overlay;
2. The success/error message will be displayed in CTAs for user managemnt overlays (login, add user, update user, etc.)
3. The success/error message will be displayed next to the CTAS for Object management (create, edit, etc.)

Library Front-end work for rebranding

As part of the rebranding effort, the library front-end work includes:

1. Update to the rebranded name and Logo;
2. Use the color pallet to be developed and add a skin so that overall style, font, color will be consistent with kgrid.org;
3. Prime navigation bar - CTAs, Style, Hoverstate, etc;
4. Banner - style, context, CTAs;
5. Search bar - dropdown, sorting;
6. Filter control - update the graphic;
7. Static pages (contact us, about, faq) - Content;
8. Object View page - Letter case, Public/Private, Object-level action dropdown;
9. Overlay - TBD

Refactor versions to make version full fcrepo containers

The basic motivation for not using the built-in fcrepo version management mechanism is that:

1. all fcrepo version are immutable, which we mostly want but which is hard to use because we need to flag ("withdrawn) and possibly annotate immutable version.

2. Managing the list of versions is problematic because they are not searchable and would require maintain separate container triples to accommodate discovery and management.

switch to Slug: header instead of "Version:"
extend/implement constraints as needed

(Rebranding) Overlay transition effect

Fix the modal area to fade away instead of slidiing.

Add security for management/actuator endpoints

Probably best to use the basic auth security mechanism in Spring Security and allow a DevOps user configured with credentials in the app properties

Updates to Publishing workflow (epic)

• We may need to move assignment of a permanent ark id to the "publish" operation; that is, allow creating and editing of KOs local to the library ("draft") with temporary ark ids (or other local ids.) This would be tantamount to the business rule: "ark ids are assigned when a draft ko is published. A ko can be "draft" or "published" independently of whether it is "public" or "private".

• There will have to be followup to determine the business rules around when a ko can modified...only when draft? Does it need to be cloned if already "published"? If "public"? Can it be versioned with the same "published" ark id, or does it need a new one? Can it be retracted/returned to draft form?

• Also, bugs:

  • currently can't "publish" a 99999 test ark id if it has already expired, so we have failure scenarios in some of our test environments. (Manual scenarios)

Add kgrid.med.umich.edu for local public library

We need to have a local public library available for use by consumers of KOs. Currently we don't have a public instance, only dlhs-fedora-dev-a.umms.med.umich.edu:8080 available on the intranet/via vpn.

• Start with asking [email protected] for the domain sent email
• point a subdomain "test.kgrid.umich.edu" to "kgrid-test.miserver.it.umich.edu"
• deploy the object teller to the MiServer test instance
• add a virtual host
• integrate with the local stack (also deployed on kgrid-test.miserver.it.umich.edu; possibly with "stack.kgrid.med.umich.edu" mapped)

metadata, KOs - updates

Add any KO metadata related stories here. As they get separated out and worked on, cross them off and add a point to the relevant issue(s). Add icon (#2)

Who's who

• Add organization metadata. Can organizations own KOs? Must they?
• Allow multiple owners (this really affects the usage scenarios; might only want one)
• Allow multiple collaborators (this really affects the usage scenarios)
• Allow owners to be added/identified by ORCID; ditto collaborators
• Clean up and standardize what we record about who made a change in the provenance model. (Remember we are recording fact triples not strings.)

Citations

• Support PMID lookup for quickly adding a citation

(Rebranding) Sorting

1. Change the Style of the sorting button;
2. Combine the sorting key and sorting order into the select;
3. Modify Vue.js code to accommodate the changes;

Expected to be done 7/21

execution - log usage (checkout, etc.)

there is a separate issue for logging usage (checkin, checkout, updates, pub/sub scenarios, etc.)

metadata - multiple contributors