Deletions are marked like this. | Additions are marked like this. |
Line 106: | Line 106: |
=== Selecting Predicate on Searching by Classification (Status: undecided) | === Selecting Predicate on Searching by Classification (Status: undecided) === |
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.
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?
- Could be very time consuming. Perhaps in a later version.
- Currently searching for Classifications is only a simple select list, it is not possible to use the predicates
Classification Sorting is Always Behind Other Field Sorting (Status: undecided)
- Issue:
- It is not possible to use classification sorting and after it other sorting.
- Until we are using the ransack gem, it is not possible or at least we should change ransack.
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: