The option to access sources external link is not present

[IbrahimTh1]

URL

https://www.openstreetmap.org/edit?way=856101520#map=13/25.56010/56.17584

How to reproduce the issue?

Until a few days ago, sources with an internet address could be directly accessed using the link similar to the one highlighted in red in the attached screenshot.
Now, that direct link no longer exists for data listed in the "source" section.
With this feature removed, it creates more workload and makes it more difficult to use the links in the "source" section.
Is this a temporary issue?
Regards

Screenshot(s) or anything else?

Which deployed environments do you see the issue in?

No response

What version numbers does this issue effect?

2.34.0

Which browsers are you seeing this problem on?

Chrome

[tordans]

I still see the button and it still works

[IbrahimTh1]

I still see the button and it still works

Yes, the button works for options: Image, Wikidata and Wikimedia Commons, but it no longer works for the sources option.

[tordans]

Thanks, thanks for clarifying. This was changed in #1508 because the source tag is recommended to be used on the changeset mainly, see https://wiki.openstreetmap.org/wiki/Key:source

You can still use it of course, it is just not promoted anymore.

[IbrahimTh1]

Thank you very much, Tordanes.
Does this mean I'll no longer be able to use source tags by clicking on the icon linking to the corresponding web page?
If so, they've really complicated our work, since when there are multiple sources, I'd have to search for the corresponding line, copy it, and then paste it into the browser.
It was much better before.

[tordans]

Does this mean I'll no longer be able to use source tags by clicking on the icon linking to the corresponding web page?

I don't think that was possible ever. It is possible for the website field for example. But the source field was a semiCombo field like this one:

Regardless, I agree the UI did expose the data a lot more before.

It was much better before.

… for your usecase. The question is, is there a solution that resolves the usecase from #1469 as well as yours. I don't see one ATM.

[IbrahimTh1]

Thank you very much.
Best regards

[tyrasd]

no longer be able to use source tags by clicking on the icon linking to the corresponding web page?

This actually used to be possible: The source field did/does link websites if the respective "chip" starts with https://, as seen here in the changeset-source field:

It would be possible to partially undo #1508 by making the universal source field only show up when a map feature already has a source tag: that way, existing tagged source-URLs and other source values remain visible on the UI (and can be easily removed when they are out of date, for example), but the field would remain unavailable through the Add field UI:

data/fields/_source.json

{
    "key": "source",
    "type": "semiCombo",
    "label": "Sources",
    "snake_case": false,
    "caseSensitive": true,
    "stringsCrossReference": "{source}",
    "autoSuggestions": false,
    "universal": true,
    "prerequisiteTag": {
        "key": "source"
    },
    "terms": [
        "reference"
    ]
}

I'm not sure if that would add even more confusion, though… 🤔

[IbrahimTh1]

Thank you very much, Martin.

Technically, I don't know what the best solution would be, but I do know that the current application has complicated our work when handling sources that begin with https://. It used to be much easier.

Simply to see if a record already has a certain source assigned or not, I have to go to the sources line and read it in its entirety (which is complicated enough to read when multiple sources are added).

The only solution I've found to continue working is to click the View on openstreetmap.org option, where you can see the sources better, and then click directly on the link https://www.openstreetmap.org/node/5713026025#map=19/24.951136/56.149294&layers=P

Any solution adopted that makes work easier will be welcome.

Greetings

Ibrahim

[tordans]

I like the idea, Martin but lets double check #1469 (comment) first. We can still do it anyways, but I would like to know the outcome … :)

[tordans]

data/fields/_source.json

@tyrasd that would introduce a new concept of unsearchable fields, right? Because ATM the concept of searchable:false is only documented for presets, not fields. Also, we should add a property to the data and not just rely on the underscore-conventions (because that is documented as just a quick way to see that this flag is there.
https://github.com/ideditor/schema-builder