Deletions are marked like this. | Additions are marked like this. |
Line 68: | Line 68: |
* We should use the ''DISTINCT'' SQL keyword and to display a warning if potentially some records are displayed many times. | * We should '''NOT''' use the ''DISTINCT'' SQL keyword and perhaps we should display a warning if potentially some records are displayed many times. |
Line 71: | Line 71: |
=== Sorting by Classification Code and Value (Status: undecided) === | === Sorting by Classification Code and Value (Status: solved) === |
Line 79: | Line 79: |
* ?? |
* 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`) }}} |
V2, MAPS and Infrastructure - Design and Implementation Issues
Introduction
Includes issues associated with:
- V2
- MAPS
- Infrastructure
V2 Issues
V2 Design Issues
Documents, Revisions and Folders
How design the access rights for documents and revisions.
Assumptions:
- Customers are likely to understand folders as a means of controlling who can view and update documents and revisions
Long-Term requirements:
- It should be possible to hide documents from certain users
- It should be possible to hide specific revisions from certain users
- Because the latest revision is not complete or not yet issued
- Because an intermediate revision is not issued
Issues:
- 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.
- - How are updates to its document recode, the document code and classifications, controlled?
- 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.
- If a document belongs to a folder, including all its revisions, how can you hide/show specific revisions?
Ideas:
- Have a 'hidden flag' in revisions and an extra read role that allows viewing of hidden revisions
- The normal view role would not show hidden revisions
- Update role would include the ability to view hidden revisions
Suggested implementation
- 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.
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".
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`)
MAPS Issues
Infrastructure Issues
Vagrant File Share Performance
There are potential performance issues with native Vagrant share_folder
- Vagrant document suggests using NFS shares instead
- We should do performance tests of document access and backups
Vagrant share_folder suffers from a VirtualBox bug
Work around is to set Apache config option: EnableSendFile off
- Vagrant NFS share bug
- Symptom: During 'vagrant up' the following is displayed:
- /etc/init.d/nfs-kernel-server: command not found
The problem is that a Ubuntu NFS restart command is being run on the CentOS host
- Symptom: During 'vagrant up' the following is displayed: