Show withdrawn codelist codes as withdrawn (v2.03) #175
Conversation
andylolz
force-pushed
the
142-show-withdrawn-v2.03
branch
from
6c77d7c to
632313e
Compare
andylolz
changed the title
andylolz
changed the title
andylolz
force-pushed
the
142-show-withdrawn-v2.03
branch
from
632313e to
62472d2
Compare
|
This issue has come up in Myanmar for the following code, which is repeated in the
|
|
^^ Tagging @PetyaKangalova and @bill-anderson, because they’re both on the email thread with Valerie from the DAC technical team, who also raised this as an issue and seemed happy with this solution. |
|
Requires PR #222 on IATI-Websites: |
|
@Ocre42 the wording looks good to go |
gen.py
Outdated
| @@ -503,6 +503,9 @@ def codelists_to_docs(lang): | |||
| if not fname.endswith('.json'): continue | |||
| with open(json_file) as fp: | |||
| codelist_json = json.load(fp) | |||
| for i, x in enumerate(codelist_json['data']): | |||
| if ('status' in x and x['status'] != 'active'): | |||
| codelist_json['data'][i]['code'] = codelist_json['data'][i]['code'] + " (withdrawn)" | |||
There was a problem hiding this comment.
This looks like it amends withdrawn codes in order to display them differently. I wonder if would be better to do this in the template.
It would save a loop (since there’s already a loop that happens in the template) and might look neater. Also, I guess changing codelist codes like this could lead to surprise consequences – I don’t know.
There was a problem hiding this comment.
Yeah, seems sensible to do it in the template instead, although I recall @Ocre42 mentioning something being a bit of a nag to deal with in the template (can't recall the full conversation, so deferring to him here). If that wasn't the case, doing it on the template should be the preferred implementation.
There was a problem hiding this comment.
I've followed your suggestion but github is still having some issues updating requests, thanks for the suggestion @andylolz
|
Is this due to be deployed? I notice lots of things have been fixed recently (which is great) but nothing has been deployed. Is that in part because deploying is a faff? |
|
Hey @andylolz yes this is all due to be deployed, we're still focussing on SSOT till the TAG, just avoiding atomic deployments in favor of bigger batches of work. |
Cool! That’s good to know.
Fair enough. I guess this is because the process of deploying the reference site is a bit involved?
Cool! Thanks |
Ish, plush also trying to be a bit less reactionary and more stable when we perform these sort of operations. Plus, the backup system is all over the place (1kb change results in a full site backup, 10 small deployments might end up eating all of our space and... well, I can let you imagine the rest...) and till all of the Ops and infrastructure side of IATI gets allotted some time and love, it'll stay like that, so we have to be very cautious |
If deploying were cheap (even just deploying to staging) then I’m not sure why it wouldn’t be done frequently. Currently I do appreciate it very much isn’t cheap – it’s complicated! But staging could be continuously deployed (to github pages or other) from version branches (by travisCI or other). Even feature branches could be auto-deployed, so that BAs could see how their changes will appear. This would create a feedback loop that would help avoid syntax errors on production. See #164. |
This relies on IATI/IATI-Codelists#155.
It adds a “Status” column to the codes tables like this one:
http://iatistandard.org/codelists/Sector/#codes
The values in the cells of the status column are either:
withdrawal-dateandactivation-dateare not shown.Refs #142.
Looks like this:
