gigascience / gigadb-website

Source code for running GigaDB
http://gigadb.org
GNU General Public License v3.0
9 stars 15 forks source link

File attribute, character limit when adding via Admin pages #2066

Closed tuli closed 2 weeks ago

tuli commented 1 month ago

User story

As a curator I want to associate sample value to a dataset file So that the the sample used or refered to by the file is linked

Acceptance tests

 Scenario: Can add very long sample value
    Given I have signed in as admin
    And I am on "/adminFile/update/id/13973"
    And I press the button "Show New Attribute Fields"
    When I select "Example data" in menu "FileAttributes_new_attribute_id"
    And I fill in the text input "FileAttributes[new][value]" with "embryophyta_odb10 C:99.1%[S:77.9%,D:21.2%],F:0.4%,M:0.5%,n:1614"
    And I press the button "Add attribute"
    Then I should see a file attribute table
      | Attribute Name | Value     | Unit |
      | last_modified  | 2013-7-15 |      |
      | Example data            | embryophyta_odb10 C:99.1%[S:77.9%,D:21.2%],F:0.4%,M:0.5%,n:1614       |      |
 Scenario: Can edit in a very long sample value
    Given I have signed in as admin
    And I am on "/adminFile/update/id/13973"
    And I press the button "Edit"
    And I fill in the text input "FileAttributes[edit][value]" with "Monday 15th July 2013, 00:00:00 AM Europe/Paris, 3463456435745634256234623456234562 bytes changed, version 235235.3423523"
    And I press the button "Save Attribute"
    Then I should see a file attribute table
      | Attribute Name | Value     | Unit |
      | last_modified  | Monday 15th July 2013, 00:00:00 AM Europe/Paris, 3463456435745634256234623456234562 bytes changed, version 235235.3423523 |      |
Scenario: I can expand the Value field for large input
Given I navigate to "/adminFile/update/id/13973"
When I want to add a large value of sample
Then I can expand the value field so I can see my whole entry 

Additional infos

Describe the bug There is a character limit on File Attributes when added via the File Admin page.

To Reproduce Steps to reproduce the behavior:

  1. Go to https://gigadb.org/adminFile/update/id/546450
  2. Scroll down to Attributes
  3. Note that "embryophyta_odb10 C99.1%[S" was truncated during spreadsheet upload (a different issue).
  4. Click Edit
  5. Attempt to add "embryophyta_odb10 C:99.1%[S:77.9%,D:21.2%],F:0.4%,M:0.5%,n:1614"
  6. Note that only "embryophyta_odb10 C:99.1%[S:77.9%,D:21.2%],F:0.4%," is allowed.

Expected behavior When I paste "embryophyta_odb10 C:99.1%[S:77.9%,D:21.2%],F:0.4%,M:0.5%,n:1614" I want the whole value to be pasted in.

Screenshots Screenshot 2024-10-22 at 14 28 54

Desktop (please complete the following information): iOS Venture 13.4 Browser Safari Version 16.5

Additional context This is for a dataset that I am making public. I can still do so w/o these values (I can add them later), but it's something that I'd like fixed soon please.

rija commented 1 month ago

Hi @luistoptal,

After checking the database schema (which allow long sample values), the issue seems to be only an HTML issue (max 50 limit in HTML).

This issue would benefit from a new test scenarios being added to tests/acceptance/AdminFileAttributes.feature. See the "Acceptance tests" section in the description of this issue for example scenarios.

luistoptal commented 2 weeks ago

@rija in sql/gigadb_tables.sql I see

CREATE TABLE file_attributes (
    id integer NOT NULL,
    file_id integer NOT NULL,
    attribute_id integer NOT NULL,
    value character varying(50),
    unit_id character varying(30)
);

wouldn't that mean that teh max value length is set to 50 also from the DB schema?

rija commented 1 week ago

@rija in sql/gigadb_tables.sql I see

CREATE TABLE file_attributes (
    id integer NOT NULL,
    file_id integer NOT NULL,
    attribute_id integer NOT NULL,
    value character varying(50),
    unit_id character varying(30)
);

wouldn't that mean that teh max value length is set to 50 also from the DB schema?

Hi @luistoptal, that file doesn't represent the state of the database schema (it should probably be deleted) the schema being used is obtained from running database migrations. See: https://www.yiiframework.com/doc/guide/1.1/en/database.migration to verify what is the current database schema obtained after running the database migrations, you will have to connect to the database server with a postgresql client (e.g: psql command or GUI apps like DBeaver or Pgadmin):

$ psql -h localhost -p 54321 -U gigadb -d gigadb -c "\d file_attributes"
Password for user gigadb:
                                       Table "public.file_attributes"
    Column    |          Type           | Collation | Nullable |                   Default
--------------+-------------------------+-----------+----------+---------------------------------------------
 id           | integer                 |           | not null | nextval('file_attributes_id_seq'::regclass)
 file_id      | integer                 |           | not null |
 attribute_id | integer                 |           | not null |
 value        | character varying(1000) |           |          |
 unit_id      | character varying(30)   |           |          |
Indexes:
    "file_attributes_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
    "file_attributes_attribute_id_fkey" FOREIGN KEY (attribute_id) REFERENCES attribute(id)
    "file_attributes_file_id_fkey" FOREIGN KEY (file_id) REFERENCES file(id) ON DELETE CASCADE
    "file_attributes_unit_id_fkey" FOREIGN KEY (unit_id) REFERENCES unit(id)

if you do that, you will see that the max value is actually 1000, not 50, nor 150.

rija commented 1 week ago

Hi @luistoptal, also for this issue:

rija commented 1 week ago

Hi @luistoptal, However, the PR #2069 doesn't implement the third acceptance scenario. That is still to be done.

I suggest you rebase your PR onto develop to get the main fix, and focus your PR on implementing the third scenario?

luistoptal commented 1 week ago

@rija I updated my PR with the suggested changes