Bug: No-Op `FIELD HUMAN NAME` in Edit Grammar Element UI

[zheylmun]

Describe the bug

The Edit Grammar Element screen in the server has a FIELD HUMAN NAME for each field of the element.
It is editable, but saving the element with content makes no change to the document, and the change is not persisted.

To Reproduce

1. Run Server & open web-ui
2. Edit Grammar
3. Select Grammar Element to edit
4. See no-op text field below Field Name

Expected behavior

It doesn't look like the field is actually tied to anything in the document when editing a grammar, so I'd expect that it is only displayed in cases where it has a backing representation in the document.

Screenshots

Environment

MacOS / Safari

[stanislaw]

Hi @zheylmun, thanks for creating the issue.

I must admit I don't understand where exactly the bug is. I double-checked and ran manually the existing tests, and I can confirm that the changed human titles are reflected in both the UI and the .sdoc source file.

• tests/end2end/screens/document/edit_document_grammar_element/edit_grammar_rename_field_human_title
• tests/end2end/screens/document/edit_document_grammar_element/edit_grammar_add_human_title

It is editable, but saving the element with content makes no change to the document, and the change is not persisted.

Maybe there is something special in your setup that is not covered by the existing end2end tests. Let's find out.

[zheylmun]

Hello @stanislaw! Thanks for the quick response! (And also the totally awesome requirements tool!) I am using 0.9.1, maybe it has already been fixed? I'll do some more testing here. It's not an issue for me at all, just noticed that it didn't seem to work when trying to set up a server based workflow for some non-technical team members.

Just tried again with a cleanly cloned version of my requirements:

• No warnings when starting the server
• Added a description to UID
• PERF: POST /actions/document/save_grammar_element 0.003s INFO: 127.0.0.1:54354 - "POST /actions/document/save_grammar_element HTTP/1.1" 200 OK - Seems like it thinks it saved ok
• No change in .sdoc file

[stanislaw]

@zheylmun I tried reproducing this one more time with the end2end tests that I mentioned above as well as editing the grammar / the human title field of StrictDoc's own docs and it is working correctly: I can see the change reflected in the file, and it is modified.

Would you mind creating a minimal reproducer with the exact steps that you are using?

[zheylmun]

@stanislaw, I'll try to set up a minimal file with just the grammar in the next day or two.

[zheylmun]

Apologies for the delay! I was able to create a small file to reproduce, along with figure out where it happens:

Running the server in a folder with only the following file I was able to reproduce the issue:

[DOCUMENT]
TITLE: Example
UID: VC-SOFTWARE-SPEC
VERSION: Git commit: @GIT_VERSION, Git branch: @GIT_BRANCH
DATE: @GIT_COMMIT_DATETIME
PREFIX: EXAMPLE-SPEC-
ROOT: True

[GRAMMAR]
ELEMENTS:
- TAG: TEXT
  FIELDS:
  - TITLE: UID
    TYPE: String
    REQUIRED: False
  - TITLE: STATEMENT
    TYPE: String
    REQUIRED: False
- TAG: SECTION
  PROPERTIES:
    IS_COMPOSITE: True
    PREFIX: None
    VIEW_STYLE: Narrative
  FIELDS:
  - TITLE: UID
    TYPE: String
    REQUIRED: False
  - TITLE: TITLE
    TYPE: String
    REQUIRED: True
  - TITLE: STATEMENT
    TYPE: String
    REQUIRED: False
- TAG: REQUIREMENT
  FIELDS:
  - TITLE: UID
    HUMAN_TITLE: UIDs will be human readable and follow a structure rather than use random strings
    TYPE: String
    REQUIRED: False
  - TITLE: STATUS
    TYPE: String
    REQUIRED: False
  - TITLE: TITLE
    TYPE: String
    REQUIRED: False
  - TITLE: STATEMENT
    TYPE: String
    REQUIRED: False
  - TITLE: RATIONALE
    TYPE: String
    REQUIRED: False
  - TITLE: COMMENT
    TYPE: String
    REQUIRED: False
  RELATIONS:
  - TYPE: Parent
  - TYPE: File

Editing the HUMAN FIELD NAME of a requirement saved exactly as expected. Editing the HUMAN FIELD NAME of the text element did not. Verified on both Windows and MacOS