= V2, MAPS and Infrastructure - Design and Implementation Issues =

[[V2Master]]

  <<TableOfContents>>

= Introduction =

Includes issues associated with:

 1. V2
 1. MAPS
 1. 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
 1. It should be possible to hide specific revisions from certain users
    1. Because the latest revision is not complete or not yet issued
    1. 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?
    1. 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.
 1. 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.
 1. 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
    1. 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
 1. Hidden revisions and restricted read permissions will not be implemented in the first release
 1. 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 Object``Classification.

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 
    1. Projects that don't need them can delete them from the system. 
 1. Affected attributes:
    1. ''Document.code_alternate''
    1. ''Revision.code_alternate''
    1. ''Task.task_type''
    1. ''User.company''
 1. 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
 1. 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 ...
    }}}
 1. 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
  1. 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''
    1. ''not equals''
    1. ''in''
    1. ''not in''
    1. ''is present''
    1. ''is blank''
 1. The text classification value is a simple ''contains'' search.
 1. 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
    1. 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
 1. 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
    1. There is generally no difference between the function of the ''Back'' link and ''Cancel'' button on ''edit'' and ''update'' screens
    1. A Java``Script-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 Java``Script (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!)
 1. 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
       1. 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
          1. 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.
 1. 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.
 1. 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.Name``With``Id''' = false
 1. 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.
 1. 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.
 1. 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
    1. We should do performance tests of document access and backups
    1. See: http://docs-v1.vagrantup.com/v1/docs/nfs.html

 1. Vagrant share_folder suffers from a Virtual``Box bug
    1. Work around is to set Apache config option:  '''Enable``Send``File off'''  
    1. See: https://github.com/mitchellh/vagrant/issues/351

 1. Vagrant NFS share bug
    1. Symptom: During 'vagrant up' the following is displayed:
       1. /etc/init.d/nfs-kernel-server: command not found
    1. The problem is that a Ubuntu NFS restart command is being run on the Cent``OS host
    1. See: https://github.com/mitchellh/vagrant/issues/1394