V2, MAPS and Infrastructure - Design and Implementation Issues

V2Master

Introduction

Includes issues associated with:

  1. V2
  2. MAPS
  3. Infrastructure

V2 Issues

Access Rights for Documents and Revisions (Status: Decided)

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 was never issued

Issues:

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

    2. Every user who has an 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:

    1. Every user who has an 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. Implement 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

Decision:

  1. The document's folder will will determine the access and update permissions for all its revisions and associated files
    1. Use the folder_id in the documents record to grant access to revisions
  2. Hidden revisions and restricted read permissions will not be implemented in the first release
  3. Working files should only be accessible to users with the update role on the document's folder

Allow entry of only one of min/max object classification fields (Status: Decided)

Issues:

  1. Currently both of the min/max object classification fields are required fields if the min_max_flag is set in the associated classification.

    1. The are use cases when only one of the min/max fields would be used. E.g. Setting only the min field could mean that the classification is valid from the min value chainage to the end of the tunnel

Suggested implementation:

  1. It is simple a validation issue in model ObjectClassification.

Decision:

  1. Leave the validation as is for now and re-evaluate later based on customer feedback

Moving Model Attributes to Classifications (Status: Done)

Issue:

  1. Moving some model attributes to classifications has advantages:
    1. More than one classification value can be entered
    2. Projects that don't need them can delete them from the system.
  2. Affected attributes:

    1. Document.code_alternate

    2. Revision.code_alternate

    3. Task.task_type

    4. User.company

  3. A disadvantage is that it may, later, be desirable o have a steering field in object tables, which can be used to select which classification fields should be enabled and what workflow type should be applied to the object

Decision:

  1. Remove all classification-like fields from the main table

  2. Do not implement a steering field for the first release

Using 'Distinct' in Search SQL (Status: Open)

Issue:

  1. 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 ...

  2. 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:

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

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

Sorting Lists by Classification Code and Value (Status: Solved)

Issue:

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

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

Suggested implementation:

  1. 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`)

Specifying Selection Predicates on Searching by Classification (Status: Decided)

Issue:

  1. Currently searching for Classifications is only a simple select list, it is not possible to use any of the following predicates

    1. equals

    2. not equals

    3. in

    4. not in

    5. is present

    6. is blank

  2. The text classification value is a simple contains search.

  3. Should we implement this predicate selects? This is likely to be time consuming.

Decision:

  1. Leave this as-is for now and re-evaluate later based on customer feedback

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

Issue:

  1. It is not possible to use classification sorting and after it other sorting.

    1. This is a limitation of the ransack gem

    2. Changing the ransack gem is likely to be difficult and time consuming

Decision:

  1. Leave this as-is for now and re-evaluate later based on customer feedback

Back/Cancel Buttons (Status: Decided)

Issue:

  1. The current screens inconsistently make use of Back links, and Cancel buttons

  2. A unified coding is standard is required. The following aspects should be considered:

    1. The same screen can be called from different places, and there is no universal method to determine the correct Back path

    2. There is generally no difference between the function of the Back link and Cancel button on edit and update screens

    3. A JavaScript-based back function cannot be used on edit and update screens, because these screens mare have been re-rendered due to a validation error. A JavaScript (browser) back would simply cause the form to be re-submitted

Suggested Implementation:

  1. Screens should not have Back links.

    1. Since the V2 system is REST based, the user can simply use the browser's back button instead (which is what it's for!)
  2. Screens with an input form should have a cancel button.
    1. The cancel button should return to a pre-defined (and fixed) path, based on the data element. There are two cases:
      1. Editing existing records: Return to the redord's detail screen or list, as appropriate
      2. Creating a new record:
        1. If the record can only be created from once place, such as adding an addition element to an existing record:
          1. Go to the record's detail screen or list of records
        2. Otherwise go to the home page

Decision:

  1. Implement the suggested implementation

Full Path in the Classification Select Lists (Status: Open)

Issue:

  1. It is not easy to see in Edit Classification's classification select list which classification is about, if some sub level have the same name.

    • The tree is seen if the select list is opened.

Suggested Implementation:

  1. The select list could contain the full path. Disadvantage: the select lists will be very wide.
  2. The code could be displayed in the front of the name and the code should be unique at least in classification class.

Opening/Closing Blocks on the GUI (Status: implemented)

Issue:

  1. What would be the best solution? Save the open/close block status on id base or not?

Suggested Implementation:

  1. Generally the name in HTML tag data-container is used with a prefix as cookie name for saving the status.

  2. Basically the open/close block status will be saved not on id base, e.g. the Identification block on the document detail screen will be opened in the same manner for all documents. This is provided by the setting Settings.SXS.Application.OCC.NameWithId = false

  3. It is possible to force to save the status the id in the HTML: data-save-mode="with-id". This setting is used currently on document detail for the individual revisions and on task detail on the individual notes.

  4. It is possible to disable saving the status in the HTML: data-save-mode="false". This is used currently on list screens in add to basket block.

  5. The prefix of the cookie name and the expire time of the cookie are set in: Settings.SXS.Application.OCC.Prefix and Expire, and currently set to "v2_occ_" and 7 days respectively.

MAPS Issues

Infrastructure Issues

Vagrant File Share Performance (Status: Open)

  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

V2Issues (last edited 2013-10-03 13:54:28 by 172)

Copyright 2008-2014, SoftXS GmbH, Switzerland