-- The CSV data download function does not honour 'columns=' QS
   parameter.

   Most probably the CSV and other spreadsheet files should contain
   just the selected columns from the table.
 (RM#1096, https://projects.ibt.lt/repositories/issues/1096)

-- When navigating to the new record creation through a 'new' link in
   a record creation form, suggestions are not offered if reading the
   table HTTP page does not require authenticated user.

   This manifests when GET is permitted without authentication, and
   only POST requires authenticated user.
 (RM#1097, https://projects.ibt.lt/repositories/issues/1097)

-- [HIGH] A missing 'revision_id' column in a view triggers "HTTP
   status 500" error.

   When accessing
   'https://plbd.ibt.lt/db/BVTS_test2/experiment_itc_protein_compound_view',
   the following error page is returned:

	HTTP status 500 /.../
	'SELECT *' failed: Unknown column 'revision_id' in 'field list' at /var/www/web-apps/restfuldb/lib/Database.pm line 2494.

   The issue manifests itself in the current trunk (please use 'svn
   annotate BUGS.txt' in the relevant branch to find the revision), but
   also in the tagged release v0.15.1.

   The error is not returned if the resulting view contains
   'revision_id' (e.g. in
   https://plbd.ibt.lt/db/BVTS_test/experiment_itc_protein_compound_view
   as of the date of filing the bug). The 'revision_id' column was not mentioned in the
   ..._restful metatable description of the view.
 (RM#1050, https://projects.ibt.lt/repositories/issues/1050)

-- Feature request [LOW]: users wish to query joined tables.

   Currently, the RESTful layer only allows to query one table; this
   is true both for Web interface and for programmatic queries. For
   more complicated queries, either several subsequent requests must
   be made, or as special VIEW which joins tables must be implemented.

   We should think whether it is possible to formulate queries that
   include related table columns
   (e.g. `../experiment_itc?filter=date>"2020-01-02" AND
   protein_batch.protein = "hCA2" AND compound_batch.compound =
   "VD20"`). Such queries would require server-side JOINs, but the
   middleware can figure out when these need to be made from the
   table.column compound column (filter property) names.
 (RM#1023, https://projects.ibt.lt/repositories/issues/1023)

-- Feature request: add possibility to download only the requested
   related tables, not all of them.

   Currently, when a REST request is made to download an individual
   record, or a list up to specific depth, *all* related tables are
   queried and their data are returned. This is often suboptimal,
   especially when a record has a large number of related entries but
   only a small number of them is required for processing.

   We should have a possibility to specify which related records are
   to be queried and downloaded, and return only those related
   records.

   The current workaround would be to send several REST queries, but
   this may be slow and does not ensure atomicity, thus is not always
   acceptable.
 (RM#1024, https://projects.ibt.lt/repositories/issues/1024)

-- Feature request: implement possibility to duplicate only the main
   record, not the related ones.

   In the current "save as new" implementation, if the edited record
   has multiple related records pointing to it, all these records are
   duplicated (with the existing information) when "save as new" is
   invoked.

   In some cases such behaviour might be desirable, but in many cases
   it makes not sense; for example, if we have an experimental data
   structure:

	Table:sample <-1:N- table:batch <-1:N- table:experiment

   then duplicating all experiments is actually totally *wrong* when
   we invoke "save as new" for a sample batch.

   One of the possible GUI solutions (The most convenient?) would be
   "Edit single" and "Edit multiple" buttons for editing the records.

   Another solution would be for the "Edit" button to load just the
   main table for editing, and have a button "add related tables" (for
   editing) in the form. This latter solution however would require
   two clicks instead of one for editing also related tables, and
   this might be annoying when many experiments need to be edited.

   Implementing this feature might also address concerns in issues
   #953 and #848.
 (RM#1025, https://projects.ibt.lt/repositories/issues/1025)

-- Feature request: implement user authentication via the '?key=…'
   QS parameter.

   Sometimes, using x509 certificates is awkward, and using access key
   might be a simple but still acceptable alternative. Redmine uses
   it. We should check however that the key is transmitted encrypted
   when https is used.
 (RM#1026, https://projects.ibt.lt/repositories/issues/1026)

-- Feature request: policy: all ID fields that can be automatically
   generated should be generated.

   All fields that the database can generate automatically, should be
   generated and assigned, and not asked. In particular, external
   identifiers (such as SolsaID for samples) SHOULD be generated of
   autosuggestion is on for a submitting user. For a new record to be
   created, only one unique ID should be provided, and should be
   enough (for instance, only ID, only UUID, only SolsaID or only
   label/code if label of code are unique).

   The general policy should be that all IDs that can be generated
   should be generated. When a JSON/XML is POSTED or PUT to a *new*
   record ID, that record ID should be used as a record to be created,
   and we should not require the same ID to be also present in the
   submitted data file (JSON/XML/CSV/...). Since this operation can
   potentially lead to an unintended creation of a record, this
   feature may be used when explicitly requested with a QS parameter
   ('?autoid=true').

   More detailed policy could be as follows:

   a) if the primary key `id` column is auto_increment in the
   underlying DB, it may be left out and will be created by a database
   (this is already implemented); if, however, the `id` is not
   autoincrement, it MUST be provided (what is the current
   implementation?);

   b) if an external key (such as SolsaID) has the suggestion
   configured, it may be left out and will generated on the server
   side; otherwise it MUST be provided;

   c) UUID, if not provided, is always autogenerated, unless
   explicitly forbidden by the RestfulDB configuration for this
   database.

   In the above text, "provided" means: either present in the posted
   JSON/XML file or used in the URI as a record identifier.
 (RM#1027, https://projects.ibt.lt/repositories/issues/1027)

-- Feature request: label/code autosuggestions in spreadsheets.

   Automatically generate autosuggested labels and pre-fill
   spreadsheet templates with them.
 (RM#1028, https://projects.ibt.lt/repositories/issues/1028)

-- Feature request: generate drop-down menus for selecting values in
   templates.

   Modern spreadsheet applications have a 'validate data' feature,
   which in addition allows to fill in data by selecting a value from
   a set of values in a different column range (using key:value
   correspondence). For efficient search, the values must be sorted in
   the selection range (at least for LibreOffice).

   If our Perl libraries permit, this should be implemented in
   download templates. The maximum amount of selection values should
   be use configurable; 1000 should be a default maximum, but can be
   overridden.
 (RM#1029, https://projects.ibt.lt/repositories/issues/1029)

-- Feature request: show foreign keys in spreadsheets using
   fk_format.

   In the Web, FK values are now shown very nicely, and uniqueness
   is ensured by inspecting just schema (i.e. independent of data,
   which is good). The same values should be used in returned
   spreadsheet values, and allowed in the uploaded filled
   spreadsheets.
 (RM#1030, https://projects.ibt.lt/repositories/issues/1030)

-- Feature request: use unique labels when present for linking keys.

   Labels or codes are more convenient for human handling; when
   present, they could/should be used instead of UUIDs or along with
   UUIDs.

   If this feature is implemented, and also if FK format display is
   present, then UUIDs may be left out; thus, when downloading
   templates, checkboxes are desirable: [x] include UUIDs (default
   off); [x] autogenerate labels (default on); [x] include primary key
   IDs (default off)
 (RM#1031, https://projects.ibt.lt/repositories/issues/1031)

-- Warning "Non-numeric date value \dots" is issued when uploading
   XLSX files.

   Strangely, a warning "Non-numeric date value '2017-11-29'
   encountered in XLSX file, leaving as is. at
   /var/www/web-apps/restfuldb/lib/RestfulDB/Spreadsheet.pm line
   195. (7 times)" is issued (multiple times) when uploading the
   'sample-for-upload-2021-03-11.xlsx' file (MD5:
   18a8dd96bf88bbba6fabd64d835921c1), even though dates looked nice
   and were actually accepted. The dates were centred – could that be
   the reason?
 (RM#1032, https://projects.ibt.lt/repositories/issues/1032)

-- When editing a record with an image, a warning "Cannot insert file
   contents of field 'image': either file cannot be read \dots" is
   issued.

   Cannot insert file contents of field 'image': either file cannot be
   read or not a file submitted. at
   /var/www/web-apps/restfuldb/lib/Database.pm line 598.
 (RM#1033, https://projects.ibt.lt/repositories/issues/1033)

-- Feature request: database name should be ignored in per-database
   metadatabases.

   When per-database configuration database (metadatabase) is used,
   column descriptions are only meant for the database that is being
   served. Therefore, the 'dbname' column is irrelevant, and it's use
   and check does not help: when database is renamed, the
   configuration stops working until database name is changed in
   several tables.

   Thus when an individual per-database configuration is used, the
   'dbname' column should be neither used nor queried, so that if this
   column is missing, no error is reported. The database name MUST be
   assumed to be the database name of the actual database that is being
   served.
 (RM#1034, https://projects.ibt.lt/repositories/issues/1034)

-- Adding or removing columns should not collapse selections to column
   lists.

   Currently, when '?columns_remove=colname1,colname2' QS option is
   used, it is transformed into the 'columns=...'  list which is
   longer and more difficult to edit (e.g. if a wrong column was
   excluded, there is not previous URL on the URL bar to edit).

   The suggestion would be to shorten the QS parameter names to
   'cadd=' (for adding columns), 'cdel=...' for excluding columns, and
   leave these options as they are of they fit the QS. The order pf
   processing should be the following (in the order specified):

   a) default column list is taken;

   b) if 'columns=...' QS option is present, it overrides the default
   column list;

   c) if 'cadd=...' columns are specified, they are added to the
   column list;

   d) if 'cdel=...' columns are specified, they are removed from the
   resulting list.

   Ideally, the columns to display should be expressed by the shortest
   possible combination of the 'columns', 'cadd' and 'cdel'
   parameters; but finding the shortest combination might take long to
   compute (knapsack problem?), thus a simple heuristics should be
   used. (RM#951, https://projects.ibt.lt/repositories/issues/951)

-- In the 'file' tables, 'filename' field should be editable.

   Although this field is generated by default, a user may wish to
   "rename" the file in the database.

   In general, all fields should be configurable as editable (another
   value or column in the `description` metatable?).
   (RM#952, https://projects.ibt.lt/repositories/issues/952)

-- Editing tables with a lot of connected records takes way too long.

   When a record is requested for editing which has a lot of other
   table records pointing to it (e.g. a user with many experiments
   done and with many publications), the edit form takes much too long
   to load to be usable (1min for some PLBD authors). NB: the display
   of the same data record takes much shorter...

   As discussed on the wide, for now the related table should simple
   be loaded shortened, e.g. only <=30 records should be loaded. In
   the future, we may add explicit requests to load more data, add
   pagination to related tables (also in the editing mode), add
   selection possibilities and/or add explicit button to add/remove
   the related tables for editing (S.G. 2021-03-04 Nr.3 NB8).
   (RM#953, https://projects.ibt.lt/repositories/issues/953; duplicate
   of RM#848)

-- Confusing error message in when JSON data are posted without the
   "type" field.

   The server in this case constructs incorrect the SQL statement and
   replies "You have an error in your SQL statement", which does not
   help to determine the reason why the request did not work.

   Moreover, the "type" (essentially meaning the table for insertion)
   information is available in the request URI when JSON is posted to
   a data or table record. In this case "type" should be optional and
   should be derived from the URI. If "type" is present in the
   submitted JSON however it MUST be checked against the table name
   provided in the URI and error message MUST be generated if the two
   do not match (S.G. 2021-03-04 Nr.2 NB8). (RM#954, https://projects.ibt.lt/repositories/issues/954)

-- No way to authenticate when using GET request.

   If GET requests are served unauthenticated, there is no means to
   provide authentication credentials and thus no means to view
   confidential fields.

   A possible easy solution would be to provide authentication token
   outside the HTTP(S) authentication scheme, with '?key=...' query
   string, in a similar way like Redmine does it. (S.G. 2021-03-04 Nr.1
   NB8). (RM#955, https://projects.ibt.lt/repositories/issues/955)

-- Feature request: Requests to non-unique labels should display several
   cards?

   Although we now think about labels as unique, there are possible
   use cases where labels are not unique and designate groups of
   records. If such label is an extkey and an URI is used to such
   label, it seems reasonable to expect that all records bearing that
   label are returned. This would mean several cards displayed on the
   HTML page (nothing special...).

   This feature would require and deliver similar functionalities as
   the feature to display several cards when several comma-separated
   unique IDs are used in the URL (S.G. 2021-02-25 Nr.12 NB8).
 (RM#1000, https://projects.ibt.lt/repositories/issues/1000)

-- BUG [HIGH]: Field value suggestions with digits in the middle are
   processed incorrectly.

   For example, the 'hCA2-VD20-SG0001' suggested value will be
   scrambled by the regexps in the suggestion engine if the value from
   this suggestion range already exists. Such suggestions are much
   needed for the new PLBD. Hopefully the fix will be simple, just a
   regexp change in the suggestion code (S.G. 2021-02-25 Nr.11 NB8).
 (RM#957, https://projects.ibt.lt/repositories/issues/957)

-- The `id` column in the RestfulDB metadata 'regexp' table should be
   autoincremented.

   The same probably applied to all (or at least to most) `id`...

   (S.G. 2021-02-25 Nr.5 NB8).
 (RM#958, https://projects.ibt.lt/repositories/issues/958)

-- Suggestions for column values in the New entry forms should be
   done for all types, not only for 'extkey'.

   The current behaviour when only the 'extkey' coltype values are
   suggested leads to unexpected behaviour and extra work in
   configuration. Moreover, sometimes we will wish to have field
   input suggestions but to assign coltype other than 'extkey' to the
   column, for instance when URIs for that column are not served
   (S.G. 2021-02-25 Nr.9 NB8).
 (RM#959, https://projects.ibt.lt/repositories/issues/959)

-- Feature request/idea: use HTML5 date picker for dates?

   Suggested by BVTS users.

   (S.G. 2021-09-25 Nr.4 NB8)
 (RM#1001, https://projects.ibt.lt/repositories/issues/1001)

-- Feature request: autogenerate field values on the server side.

   Some fields can be derived from other information on the server
   side when server is so configured. For example, if a user enters
   SMILES for a chemical compound, then mol. weight and SVG structural
   formula can be automatically generated as reasonable defaults if
   the user does not provide these data items. Note that this is not
   denormalisation since the user can choose values and
   representations different from the ones that were generated, based
   on additional information that is not in the database.

   Idea: with AJAX queries, the insertion can be queried by the
   browser and inserted into the form upon the user's request even
   before the form is submitted.

   This feature is much needed by BVTS chemists :).

   To make this feature generic, we will have to introduce a
   configuration table that will list Unix filters to construct
   derived values (STDOUT) from the provided values (STDIN or CMD
   line) (S.G. 2021-02-19 Nr.4 NB8).
 (RM#1002, https://projects.ibt.lt/repositories/issues/1002)

-- Feature request: automatically suggest 'label' field values.

   Since it now seems that file names are most appropriate as labels
   in file<->experiment and similar link tables, and since we use JS
   anyway for Select2, we should think about how to suggest a selected
   file fk_format description as a label text.

   There was a positive feedback from V.P. about our suggestion
   mechanism; in particular, it was noted that the values should not be
   inserted as defaults into the entry fields, but instead listed next
   to it with the "insert" button. If the user does not select the
   "insert" option, the field remains empty; after insertion the field
   can be edited.

   This is the same use interaction as is implemented for our date,
   time and extkey suggestions. With labels, however, the source of
   label text is different – the label text comes from the user
   selection in the Select2 drop-down. Also, uniqueness of the
   suggestion needs to be ensured (thus we will probably need an AJAX
   query to the server) (S.G. 2021-02-19 Nr.3 NB8).
 (RM#1003, https://projects.ibt.lt/repositories/issues/1003)

-- Feature request [HIGH]: search by chemical structural formula needs to be
   implemented on SMILES and other chemistry fields.

   In the Web GUI, this feature can be presented as a special
   comparison operator, "chemically identical/similar", and a
   possibility to enter SMARTS as a search value. A further GUI
   element on entry field might open a JS chemical draw applet where a
   user can draw a chemical formula or fragment, and SMARTS/SMILES
   string is generated from this drawing and inserted into the search
   field.

   We need to make this feature completely generic; i.e. it seems that
   there is a need to implement per-column configuration of "search
   functions" and "search inputs". BTW, the same "inputs" can be used
   also in the record "Edit/New" forms! (S.G. 2021-02-19 Nr.2 NB8)
 (RM#1004, https://projects.ibt.lt/repositories/issues/1004)

-- Spreadsheet tables (CSV, ODT, ...) do not return image information.

   The returned image (or file) contains empty column, which looses
   information. We should return some indication of the image/file/BLOB
   information:

   a) if a HTTP hyperlink is generated by the server, URI of that link
   can be inserted as a value. That this is an extra indirection will
   have to be implied from the column type. Especially on uploading
   such forms, the RestfulDB middleware MUST NOT replace file contents
   with the link;

   b) another possibility is to use =hyperlink(https://....) function;
   this works at least in LibreOffice when importing CSV files.

   c) Maybe images and files can be inserted into spreadsheet format
   files (ODS and XLSX do allow inserting images, don't they?), and
   then extracted upon upload?

   d) Maybe images (small) can be placed as BASE64 or HEX encoded
   blobs into cell values? Or Netpbm/SVG streams for raster/vector
   graphics?

   e) Maybe images can be included into CSV+ZIP format files, and
   referenced in the CSV tables using file:// or https:// URIs?

   We should pick the most portable (between spreadsheet engines) and
   least error-prone method(s) (S.G. 2021-02-18 Nr.1 NB8).
 (RM#964, https://projects.ibt.lt/repositories/issues/964)

-- Feature request: pressing "edit" button for a view should offer a
   selection page to edit underlying tables.

   When pressing "Edit" or "New" in the VIEW presentation page, an
   intermediate page should be presented that explains how views are
   composed and why different (original, underlying) tables should be
   edited instead. A set of links should then be presented to a user,
   each link leading to an edit form of one underlying table, which
   can be edited. Not sophisticated analysis of the VIEW code should
   be performed, only a table list should be extracted. No attempt
   should be made to "edit" a view, in the sense that user enters data
   she/he wants to see in the view, and the backend tries to derive
   data changes that are needed to achieve that result – this is too
   complicated and not always unambiguous.
 (RM#1005, https://projects.ibt.lt/repositories/issues/1005)

-- When generating new record or editing forms, views SHOULD NOT be
   included into the 'add table' list.

   This is because editing views has no sense in the database; only
   original tables can be edited, and views will be regenerated and
   connected automatically.
 (RM#965, https://projects.ibt.lt/repositories/issues/965)

-- Feature request: in RestfulDB metatables, the `id` column should be
   autoincremented.
 (RM#1006, https://projects.ibt.lt/repositories/issues/1006)

++ In the RestfulDB `numbers` table, `range` must be `text`, not a
   small varchar.

   Otherwise many suggestions do not fit (S.G. 2021-02-25 Nr.10 NB8;
   S.G. 2021-03-04 Nr.4 NB8).
 (RM#967, https://projects.ibt.lt/repositories/issues/967)

-- Files with empty filenames can not be downloaded.

   This is because with the empty file name, a file download link is
   not shown. Fallback is needed: show default '9/content' style download
   link.
 (RM#968, https://projects.ibt.lt/repositories/issues/968)

-- Getting error: "test_samples_restful.db_users' does not exist.

   A non-existing metadatabase table ideally should not case an error
   and a crash, but rather a warning (S.G. 2020-11-25 Nr.1 NB7).
 (RM#969, https://projects.ibt.lt/repositories/issues/969)

-- Feature request: RestfulDB should allow to retrieve multiple records
   (cards, table rows) using multiple IDs.

   This can be very handy in multiple circumstances, for example when
   giving a link to multiple experiments that yielded an average
   value.

   The URI example could be:

	https://plbd.ibt.lt/db/public/experiment_itc/1234,3456,7890

   to retrieve experiments with IDs 1234, 3456, 7890. The same should
   work with SolsaIDs, UUIDs and other identifiers that do not have
   comma as their component. One need to think how to generalise this
   for arbitrary identifiers than can have comma's (use filters for
   tables?) (S.G. 2020-09-25 Nr.1, NB7; S.G. 2021-02-25 Nr.13 NB8).
 (RM#1007, https://projects.ibt.lt/repositories/issues/1007)

-- Retrieving complicated views can be very slow.

   For instance, loading the `intrinsic_parameters` view from the BVTS
   binding database takes very long to respond; it could take about 1
   min. on SOLSA server virtual machine! Sure, views are slower to
   load than properly indexed tables, but the SELECT time from the
   mentioned view is about 3s as compared to 0.03s from the table:
   100-fold slowdown, for sure, but not up to 1 min...

   This is a serious usability concern. It seems that the RestfulDB
   layer adds extra queries from the view, and thus should be
   optimised (S.G. 2020-09-25 Nr.2, NB7) (RM#848,
   https://projects.ibt.lt/repositories/issues/848).

-- Feature request: FK representations should support <sub> and <sup>
   HTML tags. (S.G. 2020-09-24 NB7).
 (RM#1008, https://projects.ibt.lt/repositories/issues/1008)

-- Non-existing columns described in '..._restful' DB cause "HTTP
   500".

   This manifests as a nuisance when columns are renamed or removed
   from the main database but their descriptions are still left in the
   corresponding '..._restful' meta-database. Apparently the metadata
   reader attempts to query a non-existing column values and fails.

   This behaviour is contrary to the original design principle where
   the RestfulDB layer attempts to make a best possible representation
   even if metadata are missing. Wrong metadata should cause similar
   behaviour as missing metadata.

   Reproducing or checking this behaviour should be possible by taking
   any working test installation of RestfulDB and renaming a column
   has a metadata table description. Possibly, only columns that have
   fk_representation formats are affected (S.G. 2020-09-24 NB7).
 (RM#972, https://projects.ibt.lt/repositories/issues/972)

-- Feature request: implement search of a string (e.g. compound name)
   in *all* columns of a table. We can probably do this in RestfulDB
   layer, adding search field '*' (as an "all fields" wildcard) and
   constructing (field1 LIKE '%string%' OR field2 LIKE '%string%' OR
   ...) query for all fields. This should be done if it does not take
   too much code and time (S.G. 2021-02-19 Nr.1 NB8).
 (RM#973, https://projects.ibt.lt/repositories/issues/973)

-- GUI: when selecting a column for searching, irrelevant search
   operators are shown in selection list and can be selected
   (e.g. "starts with" for foreign key searches).
 (RM#974, https://projects.ibt.lt/repositories/issues/974)

-- GUI: when downloading spreadsheet templates for data entry, default
   number of generated sample rows should be more than 0 (e.g. 10).
 (RM#975, https://projects.ibt.lt/repositories/issues/975)

-- BUG [HIGH]: When templates are downloaded, the tables that are not
   supposed to be entered by data managers MUST NOT be included into
   the spreadsheet tab list. For example, all *_history table MUST be
   excluded. Other excluded tables are 'version' and 'revisions'
   (these are currently not included, which is correct)
   (S.G. 2021-02-18 Nr.3 NB8).
 (RM#976, https://projects.ibt.lt/repositories/issues/976)

-- BUG [HIGH]: When templates are downloaded, VIEWs MUST NOT be included into
   the spreadsheet tab list (S.G. 2021-02-18 Nr.3 NB8).
 (RM#977, https://projects.ibt.lt/repositories/issues/977)

-- Feature request [HIGH]: in the downloaded tables, tabs with tables
   *to* *which* the main requested table points must be included,
   possibly with all their values. This will then allow to find the
   required value to be linked using the data IDs and other feature in
   the pointed-to tables. For example, when adding new experiments,
   author table tab should be included; the operator can then pick the
   author (in the form of author.id, author.uuid or author.orcid) from
   the adjacent tab. This can possibly also be implemented as a data
   range restriction and drop-down list in the entry cells of the
   spreadsheets. NB: for this to work efficiently, the pointed-to
   table must be sorted by the search column.

   Caveat: when tables are very large, the requests may take too much
   time and consume too much memory in both client and server
   side. Thus, the pointed-to table download MUST be optional
   (although MAY be "on" by default), and a mechanism must be provided
   to limit the number of records (and maybe add selection criteria).
 (RM#978, https://projects.ibt.lt/repositories/issues/978)

-- BUG: viewing 'revision' with large number of insertions 'hangs' the
   server. (BUG uuid:e1af651e-7416-11eb-a363-9bdd2271778b,
   uuid-sha1:ca17af)
 (RM#979, https://projects.ibt.lt/repositories/issues/979)

-- BUG: The '*_history' tables are no longer shown when displaying
   'revision' cards, since history tables are excluded from the related
   tables lists. This solution, even though it is correct for all
   other tables, makes it impossible to look for *deleted* rows in the
   Web GUI. Thus, history tables MUST be show as related tables for
   revisions. However, this interacts with BUG:uuid-sha1:ca17af, since
   the number of records and tables can be very large. Thus, the
   amount of data transferred in a single URL request must be
   reasonably limited, and mechanisms must be provided to get all data
   in multiple pages (S.G. 2021-02-18 Nr.4 NB8).
 (RM#980, https://projects.ibt.lt/repositories/issues/980)

-- Feature request: automatically calculate some derived fields from
   submitted data upon insertion. E.g. provide default calculated
   values for summary chemical formula and molecular weight of a
   compound when SMILES string is inserted into a table. This can be
   implemented by configuring certain columns of the table as
   calculated by Unix filters provided in the `*_restful` configuration
   databases.
 (RM#981, https://projects.ibt.lt/repositories/issues/981)

-- GUI: There must be a mechanism provided to delete related table
   records before "save as new"; or to exclude related table records
   from being duplicated.
 (RM#982, https://projects.ibt.lt/repositories/issues/982)

-- Feature request [HIGH]: search for chemical structural formulae
   (identical/similar) is very much needed.
 (RM#983, https://projects.ibt.lt/repositories/issues/983)

-- Future enhancement: PostgreSQL should be implemented as a possible
   backend; however in a 'zero-config' setup as we have now, there is
   now way to specify the default databases engine.

   We can however proceed as follows: we try to connect to various DBs
   (MySQL/MariaDB, PostgreSQL), configured and compile/install
   time. If a database engine does not respond, we silently skip to
   the next one. Whenever we find a database with requested name, we
   store the engine reference and configuration in the Database
   object, and from that point on use the detected engine to make all
   queries. This autodetection MUST NOT be done when the engine is
   explicitly specified in the QS parameter, '&engine=....'.

   Caveat: this feature can only be used if it does not add noticeable
   time delays for missing databases; thus the timeouts MUST be very
   short for this to be usable (S.G. 2021-02-19 Nr.5 NB8).
 (RM#984, https://projects.ibt.lt/repositories/issues/984)

-- Missing feature [HIGH]: documentation needs to be
   updated/finalised...
 (RM#985, https://projects.ibt.lt/repositories/issues/985)

-- Usability: the RestfulDB layer seems to add significant processing
   time over the pure SQL client response time. Some of this time is
   network connection to the HTTP server, but we should carefully
   profile how much processing time do the *.pl scripts take, and
   minimise it as much as possible. As a radical measure,
   reimplementing RestfulDB components (db.pl, edit.pl) as C++
   compiled and optimised binaries might be needed. Another
   enhancement possibility might be FastCGI or other Perl-interpreter
   pre-loading servers.
 (RM#986, https://projects.ibt.lt/repositories/issues/986)

-- Feature request: for the table 'related_samples' and similar tables
   that have two references to the same table, we need to tell
   the composite form generator to represent it table only once.
 (RM#987, https://projects.ibt.lt/repositories/issues/987)

-- !! insertions of duplicated unique keys are not reported as errors
      as of current ^/trunk; checked good revision is 'svn up -r673'.
 (RM#988, https://projects.ibt.lt/repositories/issues/988)

-- !! Usability bug: there is no longer way to add lithology_img
      images! The problem is that the 'natural_sample' is merged with
      the 'sample' in the edit form, but the related tables to be
      added are only shown for the 'sample' table, and there is no way
      to navigate to the 'natural_sample'...
 (RM#989, https://projects.ibt.lt/repositories/issues/989)

-- I mark the previous bugs as solved (++), the solution being the fix
   in the `description` metadata table. We should think, however, how
   to make the system more serviceable in the future.
 (RM#990, https://projects.ibt.lt/repositories/issues/990)

-- Minor GUI blooper: table 'samples' has column 'origin', however, drop
   down menu for search contains 'origin_id' for this column. It is not
   trivial to understand that user wanting to list all entries from
   New Caledonia is not able to do so by querying for
   'origin_id=New+Caledonia'.
 (RM#991, https://projects.ibt.lt/repositories/issues/991)

-- Upon changing entry's external key ('extkey') REQUEST_URI stays the
   same, and the user might arrive at an empty page if the REQUEST_URI
   points at the now-non-existing record. Such situations have to be
   detected and resolved using for example UUIDs.
 (RM#992, https://projects.ibt.lt/repositories/issues/992)

-- 1:1 related tables should not be mentioned in the 'experiment...'
   drop-down list, only 1:N tables.
 (RM#993, https://projects.ibt.lt/repositories/issues/993)

-+ History tables should be ignored (when described with
   'visualisation="none"'). (Partial ad-hoc fix in
   ^/branches/saulius-searching).
 (RM#994, https://projects.ibt.lt/repositories/issues/994)

++ Totally strange table editing form for images with 'format',
   'cssclass', etc. -- Reason: does not check 'fk' column type, just
   the presence of non-null fk_target. Should check also column type.

-- ID suggestion code is confused when non-numeric prefixes overlap
   for different ranges, e.g. 'VU-0000-0001' and VU-SZ00-0001'.
 (RM#995, https://projects.ibt.lt/repositories/issues/995)

-- Suggestion of the PublicID (SolsaID) does not work for a new user
   that has no records yet recorded in a database.

   The reason why this is happening is that the new users lacked
   SELECT privilege on the restful.* tables. Need to think how to
   change this behaviour, otherwise we get to the situation when
   suggestions of the IDs on the Web do not work for no obvious
   reason.
 (RM#996, https://projects.ibt.lt/repositories/issues/996)

-- Creation of the new record works incorrectly if the table (and engine?) is
   specified in a query string, and not in the request URI.
 (RM#997, https://projects.ibt.lt/repositories/issues/997)

-- Request for 'database/sample/' should be served identically as
   'database/sample' (unless we assign special meaning for 'sample/'?).
 (RM#998, https://projects.ibt.lt/repositories/issues/998)

-- Unexpected behaviour upon 'search within':

   [Mon Apr 23 10:51:02.270089 2018] [cgi:error] [pid 23151:tid 140175258617600] [client 172.17.170.148:48994] AH01215: /home/saulius/public_html/restful/website/cgi-bin/db.pl: WARNING, incorrect filter expression '((year >= 2010) AND (title LIKE "Bragg")) AND (title LIKE "%")':: /home/saulius/public_html/restful/website/cgi-bin/db.pl, referer: https://perly-gate.ibt.lt/~saulius/restful/website/iucr.sqlite3/biblio?filter=%28year+%3E%3D+2010%29+AND+%28title+LIKE+%22Bragg%22%29&offset=0&order=year%3Ad%2Cjournal%3Aa%2Cvolume%3Aa%2Cissue%3Aa%2Cfirstpage%3Aa&rows=100&select_column=title&select_not_operator=&select_operator=like&search_value=%25&select_combining=within&.cgifields=select_combining
 (RM#999, https://projects.ibt.lt/repositories/issues/999)
