Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source X fields in staging iD have offset delete behavior #892

Open
danrademacher opened this issue Oct 4, 2024 · 3 comments · May be fixed by OpenHistoricalMap/iD#226
Open

Source X fields in staging iD have offset delete behavior #892

danrademacher opened this issue Oct 4, 2024 · 3 comments · May be fixed by OpenHistoricalMap/iD#226
Assignees
Labels
bug Something isn't working ID

Comments

@danrademacher
Copy link
Member

Bug description
On staging.openhistoricalmap.org, where we deployed the latest iD changes with automatically incrementing Source X fieldsets, there's a weird offset of the delete behavior.

Here's a schematic of what is happening:
image

It looks to me like the Source fieldsets get created as Source, Source 1, Source 2,... but the trashcans are pointed at Source 1, Source 2...

What should be happening?
Since the base Source fieldset in the preset can never be deleted, it should never get a trashcan. Trashcans should appear only starting with Source 1 and the /trashcan on a fieldset should delete that fieldset, not the next one down.

Repro Steps
Please provide detailed instructions to reproduce the behavior:

  1. Go to https://staging.openhistoricalmap.org/edit
  2. Enter any string in the Source field
  3. Use the Add Field menu to add Source 1
  4. Use the trashcan on Source to delete Source 1
@danrademacher danrademacher added bug Something isn't working ID labels Oct 4, 2024
@pedromml
Copy link

pedromml commented Oct 4, 2024

Hey Dan!
I replicated the bug and here's what is going on:
Source 1 only shows up when there is data on Source, so, when the data on Source is deleted, Source 1 becomes hidden again. I made this behavior so that the user wouldn't find themselves in a situation where Source 1 was visible and empty, but Source wasn't visible, with the intent to guide the user to fill in the source fields in increasing order.
Do you think it makes sense to change this behavior?

I thought that the purpose of the trashcan button was to clear the data on the field, but not necessarily remove the field entirely. If the trashcan in Source is removed, it would be the only field that doesn't get a trashcan when there is data on it.

@1ec5
Copy link
Member

1ec5 commented Oct 8, 2024

Clicking the delete button should delete the tag associated with the field. It’s only a coincidence that it happens to cause the following field to get hidden. That said, some users might be accustomed to seeing an ✖️ button associated with each field, based on using other software, so they might mistake the 🗑️ button for that functionality.

Would it be possible to still keep, say, Source 1 and Source 2 visible as long as source:3=* has a non-empty value?

@pedromml
Copy link

It is possible to keep Source 1 and 2 visible if source:3=* has a non-empty value. I'll be working on that shortly

@pedromml pedromml linked a pull request Oct 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ID
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

3 participants