Differences between revisions 16 and 17
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
Line 18: Line 17:
== V2 Design Issues ==

=== Documents, Revisions and Folders ===

How design the access rights for documents and revisions. 		== Access Rights for Documents and Revisions (Status: Decided) ==
Line 25: Line 20:
Line 29: Line 23:
Line 33: Line 26:
    1. Because an intermediate revision is not issued     1. Because an intermediate revision was never issued
Line 36: Line 29:
Line 38: Line 30:
  - 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. 		    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.
Line 41: Line 33:
  - Every user who has in '''any folder''' update permission will have the possibility to create a version to every document the user can read.     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.
Line 45: Line 37:

1. Have a 'hidden flag' in revisions and an extra read role that allows viewing of hidden revisions 		 1. Implement a ''hidden flag'' in revisions and an extra read role that allows viewing of hidden revisions
Line 50: Line 41:
Suggested implementation 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
Line 52: Line 47:
 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.
Line 54: Line 48:
=== Allow enter only one of min/max object classification fields (Status: undecided) === == 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) ==
Line 57: Line 63:
 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? 		 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.
Line 61: Line 88:
  * It is simple a validation issue in model ObjectClassification.   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"
Line 63: Line 91:
=== Moving some model attributes to classifications (Status: undecided) === == Sorting Lists by Classification Code and Value (Status: Solved) ==
Line 66: Line 94:
 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. 		 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.
Line 72: Line 98:
  * ??  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`)
    }}}
Line 74: Line 103:
== V2 Implementation Issues ==

=== Using DISTINCT on Search SQL (Status: undecided) === 		== Specifying Selection Predicates on Searching by Classification (Status: Decided) ==
Line 79: Line 106:
 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. 		 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.
Line 87: Line 116:
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". 		Decision:
 1. Leave this as-is for now and re-evaluate later based on customer feedback
Line 91: Line 119:
=== Searching/Sorting Issues ===

==== Sorting by Classification Code and Value (Status: solved) ==== 		== Classification Sorting is Always Behind Other Field Sorting (Status: Open) ==
Line 96: Line 122:
 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. 		 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
Line 100: Line 126:
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`)
}}} 		Decision:
 1. Leave this as-is for now and re-evaluate later based on customer feedback
Line 106: Line 129:
==== Selecting Predicate on Searching by Classification (Status: undecided) ==== === Back/Cancel Buttons (Status: Decided) ===
Line 108: Line 131:
 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? 		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
Line 114: Line 138:
 Suggested implementation:
  * Could be very time consuming. Perhaps in a later version. 		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
Line 117: Line 149:
==== Classification Sorting is Always Behind Other Field Sorting (Status: undecided) ==== Decision:
 1. Implement the suggested implementation
Line 119: Line 152:
 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:
  ??
Line 140: Line 156:
== Vagrant File Share Performance == == Vagrant File Share Performance (Status: Open) ==

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

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