View Issue Details

IDProjectCategoryView StatusLast Update
0008483Talerexchangepublic2024-03-07 19:51
ReporterFlorian Dold Assigned Tosebasjm Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version0.9.4Fixed in Version0.9.4 
Summary0008483: exchange ToS are not properly rendered as HTML
Descriptionhttps://exchange.test.taler.net/terms

(Sections aren't rendered correctly, title is odd ("no title"))
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Relationships

related to 0008457 closedsebasjm webext requests ToS as text/xml and fails to render it 

Activities

Christian Grothoff

2024-02-21 20:32

manager   ~0021427

Last edited: 2024-02-21 20:33

Well, seems Stefan's conversion from Restructured Text to Markdown broke it. Do we know why it was converted to MD in the first place?

Christian Grothoff

2024-02-21 20:34

manager   ~0021428

Stefan, please clarify why you converted the (at the time working!) Restructured Text to Markdown for the Terms of service and privacy policy.

Stefan

2024-02-22 07:07

reporter   ~0021439

Look at https://bugs.gnunet.org/view.php?id=7882 which ends with Marc's note " The iOS app now successfully receives Markdown ToS."

Marc and I wanted to get MarkDown rendered instead of ugly plain text which is displayed very badly on iOS platforms.

https://bugs.gnunet.org/view.php?id=8003 solved the issue that the ToS generator generated invalid MarkDown.

Now we should ask us whether there is a way to let a MarkDown-tagged text file be displayed properly as plain text. MarkDown is required for iOS. When I git blame the ToS file exchange-tos-v0.rst I see that my last changes were applied on December 14. Was the file not working since then??

Thank you for your contributions to solve this issue. It will be needed for getting translations of the Terms of Service started in Weblate as we are heading for a whole bunch of languages we have to translate to.

Stefan

2024-02-22 07:09

reporter   ~0021440

Oh, and I never touched exchange-pp-v0.rst.

Christian Grothoff

2024-02-22 07:43

manager   ~0021441

I see. Well, in that case the answer is simple: please revert to proper Restructured Text, as the taler-terms-generator had been fixed to generate MD itself from the RST inputs, and so the source should be Restructured Text and NOT markdown! It works nicely for the other RST files.

Stefan

2024-02-22 09:12

reporter   ~0021442

Done: https://git.taler.net/exchange.git/commit/?id=0389821c4b15203aeca55262b865a0b87163d8ab
Let's see how it renders. Please make a new build and test it out. Thank you.

Christian Grothoff

2024-02-22 17:08

manager   ~0021460

Florian or Sebastian: I assume you can test this on test.taler.net / with sandcastle?

MarcS

2024-02-22 17:35

developer   ~0021462

I would expect HEAD to automatically pick this up - that's the main reason for it's existence, isn't it?

sebasjm

2024-02-23 13:53

developer   ~0021480

still testing, but this is what I see... asking the exchange for text/html and server replies text/plain
image.png (64,519 bytes)   
image.png (64,519 bytes)   

MarcS

2024-02-23 13:56

developer   ~0021481

That was similar 3 months ago, when iOS asked for text/markdown and first only got text/plain, and later the server claimed to send text/markdown but the content was still text/plain.
Took weeks until there finally was real markdown in the answer...

Christian Grothoff

2024-02-23 14:02

manager   ~0021482

I don't get it. Please do
curl -H 'Accept: text/plain' https://exchange.test.taler.net/terms
vs.

curl -H 'Accept: text/html' https://exchange.test.taler.net/terms

vs.

curl -H 'Accept: text/markdown' https://exchange.test.taler.net/terms

I always get the result in the correct format!

sebasjm

2024-02-28 14:38

developer   ~0021552

this works locally

cache may be a separated issue

Issue History

Date ModifiedUsernameFieldChange
2024-02-21 20:05Florian DoldNew Issue
2024-02-21 20:05Florian DoldStatusnew => assigned
2024-02-21 20:05Florian DoldAssigned To => Christian Grothoff
2024-02-21 20:32Christian GrothoffNote Added: 0021427
2024-02-21 20:33Christian GrothoffNote Edited: 0021427
2024-02-21 20:33Christian GrothoffAssigned ToChristian Grothoff => Stefan
2024-02-21 20:34Christian GrothoffNote Added: 0021428
2024-02-21 21:34sebasjmRelationship addedrelated to 0008457
2024-02-22 07:07StefanNote Added: 0021439
2024-02-22 07:09StefanNote Added: 0021440
2024-02-22 07:43Christian GrothoffNote Added: 0021441
2024-02-22 09:12StefanNote Added: 0021442
2024-02-22 17:08Christian GrothoffAssigned ToStefan => sebasjm
2024-02-22 17:08Christian GrothoffNote Added: 0021460
2024-02-22 17:35MarcSNote Added: 0021462
2024-02-23 13:53sebasjmNote Added: 0021480
2024-02-23 13:53sebasjmFile Added: image.png
2024-02-23 13:56MarcSNote Added: 0021481
2024-02-23 14:02Christian GrothoffNote Added: 0021482
2024-02-28 14:38sebasjmStatusassigned => informing
2024-02-28 14:38sebasjmResolutionopen => fixed
2024-02-28 14:38sebasjmNote Added: 0021552
2024-03-07 19:50Christian GrothoffFixed in Version => 0.9.4
2024-03-07 19:51Christian GrothoffStatusinforming => closed