V2, MAPS and Infrastructure - Design and Implementation Issues

V2Master

• Contents

  1. V2, MAPS and Infrastructure - Design and Implementation Issues
  2. Introduction
  3. V2 Issues
     1. V2 Design Issues
        1. Documents, Revisions and Folders
        2. Allow enter only one of min/max object classification fields (Status: undecided)
        3. Moving some model attributes to classifications (Status: undecided)
     2. V2 Implementation Issues
        1. Using DISTINCT on Search SQL (Status: undecided)
        2. Searching/Sorting Issues
           1. Sorting by Classification Code and Value (Status: solved)
           2. Selecting Predicate on Searching by Classification (Status: undecided)
           3. Classification Sorting is Always Behind Other Field Sorting (Status: undecided)
        3. Back/Cancel Buttons (Status: undecided)
  4. MAPS Issues
  5. Infrastructure Issues
     1. Vagrant File Share Performance

Introduction

Includes issues associated with:

1. V2
2. MAPS
3. Infrastructure

V2 Issues

V2 Design Issues

Documents, Revisions and Folders

How design the access rights for documents and revisions.

Assumptions:

1. Customers are likely to understand folders as a means of controlling who can view and update documents and revisions

Long-Term requirements:

1. It should be possible to hide documents from certain users
2. It should be possible to hide specific revisions from certain users
   1. Because the latest revision is not complete or not yet issued
   2. Because an intermediate revision is not issued

Issues:

1. If a revision belongs to a folder and a document not:
   • - How are updates to its document recode, the document code and classifications, controlled?

     - Every user who has in any folder update permission will have the possibility to create a version to every document where the user can read any of its revision.

2. If a document belongs to a folder and its revisions can belong to different folders:

   • - Every user who has in any folder update permission will have the possibility to create a version to every document the user can read.

3. If a document belongs to a folder, including all its revisions, how can you hide/show specific revisions?

Ideas:

1. Have a 'hidden flag' in revisions and an extra read role that allows viewing of hidden revisions
   1. The normal view role would not show hidden revisions
   2. Update role would include the ability to view hidden revisions

Suggested implementation

1. For now, implement a folder_id in documents, folder_id in revisions and file_assets will be synchronized with the associated document for performance reasons, first of all in the authorization. No hidden flag.

Allow enter only one of min/max object classification fields (Status: undecided)

Issue:

• Currently both of the min/max object classification fields are required if the min_max_flag is set in the associated classification. Is it necessary to allow to enter only one of them in that case? Only min or only max field?

Suggested implementation:

• It is simple a validation issue in model ObjectClassification.

Moving some model attributes to classifications (Status: undecided)

Issue:

• Moving some model attributes to classifications has the advantage that more than one values can be entered and users who don't need them can delete them from the system totally. Such attribute is e.g. Document.code_alternate. The disadvantage is, that implementing functionality, depending on that attribute, can be difficult. Such attribute is e.g. Document.document_type, where work flow can depend on it.

Suggested implementation:

• ??

V2 Implementation Issues

Using DISTINCT on Search SQL (Status: undecided)

Issue:

• If documents/revisions/tasks are sorted by a classification class, in which an object has more than one classification,

  then the object appears on the list more than once if we do not use the DISTINCT SQL keyword. E.g.:

   SELECT DISTINCT revisions.* FROM `revisions` INNER JOIN ...

  But if we are using the DISTINCT SQL keyword than the sorting doesn't seems to be correct, because the sorting is effective after the distinct filtering.

Suggested implementation:

• We should NOT use the DISTINCT SQL keyword and perhaps we should display a warning if potentially some records are displayed many times.

• The warning could be, e.g.: "WARNING: Revisions with more than one Location value will appear more than one time in the list".

Searching/Sorting Issues

Sorting by Classification Code and Value (Status: solved)

Issue:

• Currently is it not possible to sort by classification values because the classification values can be in different fields.

  The values in object_classification fields are used for sorting only if the classification is a so called zero level classification.

Suggested implementation:

• Use similar sorting with the appropriate (which occurs in a classification of the class) sort fields 'coalesced':

  ORDER BY `cl_s1`.`code` ASC, coalesce(`oc_s1`.`min_int`, `oc_s1`.`min_float`)

Selecting Predicate on Searching by Classification (Status: undecided)

• Issue:
  • Currently searching for Classifications is only a simple select list, it is not possible to use the predicates

    equals, not equals, in, not in, is present, is blank. Also the text classification value is a simple contains search. Should we implement this prediacte selects?

  Suggested implementation:
  • Could be very time consuming. Perhaps in a later version.

Classification Sorting is Always Behind Other Field Sorting (Status: undecided)

• Issue:
  • It is not possible to use classification sorting and after it other sorting.
  Suggested implementation:
  • Until we are using the ransack gem, it is not possible or at least we should change ransack.

Back/Cancel Buttons (Status: undecided)

• Issue:

  • Definition of unified coding is necessary for Back and Cancel buttons for all screens regarding the following aspects:

    • The screens can be called from different places, a method is needed to define the Back path.

    • There is no difference between Back and Cancel on edit and update screens.

    • The javascript back function can not be used on edit and update screens, because these screens could be re-rendered

      • on validation error, and so javascript (browser) back would lead to the same screen.

  Suggested implementation:
  • ??

MAPS Issues

Infrastructure Issues

Vagrant File Share Performance

1. There are potential performance issues with native Vagrant share_folder

   1. Vagrant document suggests using NFS shares instead
   2. We should do performance tests of document access and backups

   3. See: http://docs-v1.vagrantup.com/v1/docs/nfs.html

2. Vagrant share_folder suffers from a VirtualBox bug

   1. Work around is to set Apache config option: EnableSendFile off

   2. See: https://github.com/mitchellh/vagrant/issues/351

3. Vagrant NFS share bug
   1. Symptom: During 'vagrant up' the following is displayed:
      1. /etc/init.d/nfs-kernel-server: command not found

   2. The problem is that a Ubuntu NFS restart command is being run on the CentOS host

   3. See: https://github.com/mitchellh/vagrant/issues/1394