URGENT - GO emergency page incorrectly being renamed

[nanometrenat]

Page URL

https://go.ifrc.org/emergencies/7196/details

Environment

Production

Browser

Chrome

Steps to Reproduce the Issue

This emergency page has been in place for some time, and - whilst it was originally named Philippines - Cyclone Kristine - 2024, the operation/response rapidly expanded to cover six typhoons over a period of several months, so the emergency page was subsequently correctly manually renamed to Philippines: Typhoons and Floods - 2024 and has happily remained that name for some months now even when the emergency page was edited.

However, yesterday the emergency page was edited for the first time since last Friday's release, and whilst the PMER person was solely uploading a sitrep document (i.e. not making any changes to the main body of the page or other fields), after she saved the page renamed itself to PHL: Cyclone - 02-2025 -, which is incorrect.

This is incorrect on multiple levels:

1. The new automatic name implies the Typhoons happened in Feb 2025 when actually they happened in 2024 - this is for sure a bug, as the auto rename seens to be taking the date the page is edited rather than the date of the event.
2. Why is the emergency page being renamed anyway? The original name (Philippines Typhoons and Floods 2024) was the correct name for the operation as per the appeal documents etc. There was no intention by the operation to change the name, we would like it changed back please.
3. (typo) Why does the new automatic name structure have a - on the end with nothing after?

My PMER colleague has today gone in to edit the emergency to change the name back to what it should be, but again her change is overwritten to the automatic name - so there is no workaround for us to fix this operation ourselves.

I have looked at the issues in the [email protected] Release Note and think it must relate to changes made for #1382 and in particular sub-ticket IFRCGo/go-api#2266

However in that ticket it clearly states that For existing Emergencies, the title field will remain empty, and the summary will retain its current value. - which I read to mean that for existing emergencies nothing should change unless we want it to. Which is clearly not the case.

To reproduce this issue:

• click on the "edit emergency" button on the front end of an emergency page in GO (in this case, https://go.ifrc.org/emergencies/7196/details)
• it takes you to the admin site (in this case, https://goadmin.ifrc.org/en/admin/api/event/7196/change/)
• change something (not the title) - in this case we uploaded a sitrep
• click save
• you will see that the emergency title has been automatically renamed (on both front end and back end) to have country code + Disaster Type + today's month and year (rather than the month and year the emergency happened)

Expected Behavior

I expected the emergency page title to stay the same when no-one had edited the title

Actual Behavior

The emergency page title changed to an incorrect one.

Priority

Critical (Site is unusable)

Additional Context (Optional)

No response

[nanometrenat]

This is the history page for the emergency I logged the ticket about: https://goadmin.ifrc.org/en/admin/api/event/7196/history/

However I can see a bunch of other emergencies have also been affected by this - these emergencies were in January 2025 or in 2024, but as the page was edited in February they now have the incorrect date in the emergency name. Here is a table with just a subset of the incorrect names:

URL	Disaster start	Name prior to the release	New name that came automatically when page edited post-release
https://go.ifrc.org/emergencies/7272/details	December 2024	Ciclón tropical Chido	OM: Cyclone - 02-2025 -
https://go.ifrc.org/emergencies/6987/details	April 2024	Brazil Floods - Inundações no Rio Grande Sul	BRA: Flood - 02-2025 -
https://go.ifrc.org/emergencies/7081/details	July 2024	Philippines: Southwest Monsoon by Typhoon Carina - July 2024	PHL: Cyclone - 02-2025 -
https://go.ifrc.org/emergencies/7196/details	October 2024	Philippines: Typhoons and Floods - 2024	PHL: Cyclone - 02-2025 -

Note that the last two are both Philippines typhoons that happened several months apart and are unrelated emergencies - but now have exactly the same name and we can't tell them apart.

Thanks for your help looking into this.

[samshara]

@nanometrenat Currently, the emergency title is generated following the pattern: ISO-DisasterType-MM-YYYY-Title. The Title field is new, and for older emergencies, it remains empty. However, when an emergency is updated, the title is regenerated using this pattern.

We have not migrated old emergency names to the Title field, as this would require a heuristic to map them. Since the original Name field was a free-text field, users did not follow a consistent format.

Therefore, we need to ensure that the Title field is properly updated when an emergency is modified.

Now, with PR #2416 the start_date of an emergency is used correctly.

[nanometrenat]

Thank you @samshara for the update, firstly it is great that the start date will now be correct.

I'm not clear on the other comment though - are you saying that we can't edit emergencies any more and have the emergency still keep the name we want them to have? In many cases emergencies are more than one thing - e.g. cyclones AND floods, volcanic eruption AND tsunami (Tonga), similarly many times an emergency changes over time. Or changes its geographic coverage. So we need to ensure we keep the flexibility in naming. Who was consulted about forcing standardised naming rather than allowing users to name the emergency how they want them to be?

Similarly, it's very common to have multiple cyclones (or floods, or whatever) in the same country in the same month - so need the user to be able to distinguish between them. xref #1382 (comment)

The particularly crazy thing is, in many cases people don't even want to edit the emergency itself - just want to upload a document and leave everything else the same, or update an infographic on one of the tabs or something - but we don't give them the power to do that independently of editing the whole emergency. And we definitely need to be able to keep maintaining/adding documents ongoing without affecting the emergency page title.

@LukeCaley in @tovari's absence who can speak to the business requirements here? Also, who will put things right (revert) for the emergencies that have already been saved with the incorrect (February date, no description) edits due to this bug?

[nanometrenat]

Also a significant functionality change of this type would normally need to be communicated to users in advance- however it wasn't listed in Dani's highlights in the SIMS update or anywhere else that I saw (apart from the Github list). GO team (the IM team) please can we please always communicate changes that will freak out users when something happens that they aren't expecting? Users generally think this kind of thing is their own fault but it's not! Thanks

[nanometrenat]

Copying from the email thread so the info is together. From Dedi:

I’d like to follow up on the issue with renaming the emergency page.
I tried to update the emergency names for the Philippines:

• https://go.ifrc.org/emergencies/7196/details
• https://go.ifrc.org/emergencies/7081/details

However, I am unable to rename them from the GO backend because the “title box” has disappeared (see the attached screenshot).

[nanometrenat]

Zoli on email also advised

About the to-be-fixed task: I found 18 events on prod, their date could be fixed manually in the database (so no automation is needed).
The updated_at should be between the first prod deployment and today's hotfix:

[nanometrenat]

From @mmusori and @karanjaelijah on email:

Elijah and I were testing in stagging. If you make any sort of change on an Emergency page the name of the page is automatically changed to this new convention which in some cases completely changes what the title was trying to convey. See Mpox example below. Is it possible to roll back the Dev work until we have something that does not make such drastic unintended changes. And in the meantime, can we ask all Ims not to make any changes on their Emergency pages? Or any other solution is welcome at this time.

[samshara]

@nanometrenat

I'm not clear on the other comment though - are you saying that we can't edit emergencies any more and have the emergency still keep the name we want them to have? In many cases emergencies are more than one thing - e.g. cyclones AND floods, volcanic eruption AND tsunami (Tonga), similarly many times an emergency changes over time. Or changes its geographic coverage. So we need to ensure we keep the flexibility in naming. Who was consulted about forcing standardised naming rather than allowing users to name the emergency how they want them to be?

First, let's follow this naming convention:

• Title: The user-editable name of the emergency.
  • Example: In PHL: Cyclone - 10-2024 - Typhoons and Floods, the Title is "Typhoons and Floods".
• Name: The constructed name of the emergency.
  • Example: "PHL: Cyclone - 10-2024 - Typhoons and Floods"

1. Users can edit the emergency title. This is a new field. However, the emergency Name (the one displayed on emergency pages) cannot be edited because it follows a standardized format. This ensures consistency of names and prevents auto-translation from modifying country names / ISO.

2. Currently, emergencies cannot be associated with multiple disaster types. Simply changing the name may only address part of the issue, and associating names with disaster types might not be the ideal approach. We should have a discussion on this.

Similarly, it's very common to have multiple cyclones (or floods, or other disasters) in the same country within the same month—so users need a way to distinguish between them.

This can be handled by setting a unique title for each emergency.

I’d like to follow up on the issue of renaming emergency pages.
I tried updating the emergency names for the Philippines:

The Name field exists, please refer to point 1 above.

Proposed Solution

1. We will introduce a flag to differentiate between old and new emergencies. This flag will be set for all existing (old) emergencies.
2. If the flag is set and saved (using the Save button in the Django admin panel), users will then be able to edit the emergency name.
   Important: Auto-translation will not work in this case, as it cannot be applied dynamically. We will need to manually add any missing title translations for the name.
3. If the flag is unset and saved(using the Save button in the Django admin panel), then the name construction will remain active, and users will not be able to manually edit the emergency name. The auto-translation will work as expected.

Alternative Approach

1. Remove the title generation logic from emergencies, so the emergency name is initially set based on the Field Report.
2. This allows auto-translation to work on the emergency name. However, this may lead to inaccurate translations, as noted in issue #1032

cc @udaynwa @tovari

[samshara]

@nanometrenat, we will deploy the alternative solution above in the staging environment. Once this is done, we will notify you. Let's test it out.

[nanometrenat]

Thanks a lot @samshara for the clarity on internal terminology between "name" and "title" - that makes sense. From a user point of view the emergency name is the heading that you see in bold on an emergency page - but I appreciate that under the hood there may be a distinction between the fields. For my tickets recently I have been trying to look at GO from the point of an ordinary user (which I am, in my current job role!)

I still have many questions about who signed off these requirements in the first place though - to have the automated start of the name of the emergency page (rather than the field report) in terms of whether Operations were engaged in the decisions around the new naming convention - which results in a bunch of automated things to read before getting to the "meat" of the heading, and which doesn't seem to cater for some of the scenarios we have in the emergency world (multi-country/regional emergencies, disasters that cross categories or have different terminology used in different locations e.g. cyclone vs typhoon etc.).

I am interested why the desire for auto translation wins over general usability of the platform for people involved in operations, and for partners/donors/public who we are trying to surface our lifesaving work to. Again, this is a requirements/business design question rather than tech implementation question!

Thanks again for all your work on this.

[samshara]

@nanometrenat, it seems like the broader IM team may not have fully discussed the impact of this work, and it might have been overlooked. Since this was a relatively small task, our focus was more on ensuring a consistent name.

[frozenhelium]

I am interested why the desire for auto translation wins over general usability of the platform for people involved in operations, and for partners/donors/public who we are trying to surface our lifesaving work to. Again, this is a requirements/business design question rather than tech implementation question!

Hi @nanometrenat, regarding the automated translation of title part,

The overall goal here is not just prioritizing the support for the auto translation, but also to reliably standardize the title of field reports and emergency. The intent here is that, the title should be informative and easily identifiable while being flexible enough that user can build onto it. This approach also helps the automatic translation of title work more reliably.

The title standardization was previously achieved by doing the title generation as a one time process during the creation of field report, which kept the whole name of the field report (which also becomes title of the emergency) in title field. This approach has a few shortcoming. One of them being the incorrect auto translation. Another one being that the title would not reflect latest changes and state of the emergency. As you've previously mentioned, the details in emergency might get updated (for eg: impacted countries, or disaster type) over time and the updating title accordingly while maintaining the standard format solely relies on the user, which might not always be ideal situation. For example, it was completely possible for the users to rename the emergency to "Nepal flood 2024", or just "Flood in Nepal". This might confuse other users since there could be multiple such emergencies in longer term.

And also referring to the comment from issue #1382, if we need to include more info in the title (i.e. details of multiple appeals) then, in my opinion, it's better to generate the name from the system rather than relying on user to update it. So that we can avoid the need of updating title from the admin panel.

The translation issue which is mentioned in #1032 definitely sparked the title standardization conversation, but please keep in mind that we've implemented this feature to also keep the title of emergencies and field reports to a more predictable and reproducible pattern.

If you think that this impacts the general usability of the platform then we definitely need to discuss it futher and figure out better way to standardize the title which also elimates the need to manually edit it in the admin panel (We don't recommend using the admin panel for such frequent changes as it bypasses a lot of logic and checks implemented in the system). If emergency is something that need frequent update, maybe we should implement a workflow to do so in the frontend. Let us know what you think!

CC: @tovari @LukeCaley @mmusori @samshara @udaynwa

[nanometrenat]

Thanks @frozenhelium for the backstory. I do indeed think that this particular standardisation on the platform does impact the usability. My first approach when thinking about anything to do with emergency names/titles/headings/whatever would be to think about how the proposed approach would apply when in real life. And when I'm thinking about real life I would run through both the big emergencies (e.g. the ones pinned on the very front page (and the regional pages), and how they would look under the new proposal) plus a sample of smaller ones from multiple countries/multiple types and timeframes and sources and evolutions, some manually added, some created via FRs, some merged, some with/without appeals/DREFs etc. - just to see how the logic would apply in practice.

Know there may be differing views on this - but I think that using up all those characters at the start of what you see onscreen - and knowing that a bunch of our biggest emergencies are multi-country anyway, or multi-type, and evolve over time - isn't ideal. I don't think I know anyone who knows the 3 letter ISO codes for all the countries in the world, so to many users those 3 letters are meaningless. Similarly, when an Ops person here saw the new title today, they asked 'what are those numbers' - because 10-2024 wasn't a date format that is usual for them to see/use.

Personally I don't think that as a user the Syria or Brazil Floods emergencies (two that are pinned here) are appealing. Happy to have that discussion if others disagree - but I do think that it needs to be run past people involved in Ops.
Agree that we need to differentiate between Nepal Floods 2024 vs other Nepal Floods - but presumably that could also be done by improving the filtering and what's displayed on the various pages and search results, so that dates and appeal codes are shown as well as the title/heading/name, without having to actually include it as an inescapable part of the name.

[nanometrenat]

(We don't recommend using the admin panel for such frequent changes as it bypasses a lot of logic and checks implemented in the system) If emergency is something that need frequent update, maybe we should implement a workflow to do so in the frontend. Let us know what you think!

Users have no other way to update information relating to the emergency. Emergency operations continue for many months (used to be several years, now most EAs should finish after just one year) and in the initial phases of a large emergency we need to add information or documents or sitreps or updates or Mobtables etc. several times a day. Later stages will be less often. The revised Emergency Response Framework also puts requirements on operations to produce Sitreps more frequently than ever before (and sitreps etc. are not Appeal Documents so don't come via the auto sync process, have to be uploaded manually).

There is no interface to do this on the front end. They must be uploaded on the back end. The current user configuration for most users only allows them to do it via edit emergency. So we have no other option.

Bringing some of these functions to the front end and/or making them more user friendly has been on the to do list for many years. xref IFRCGo/go-frontend#927 IFRCGo/go-frontend#1357 IFRCGo/go-frontend#1699

[frozenhelium]

Thanks @nanometrenat for the insight on use-case of the emergency title! We'll have a discussion about it and also keep in mind the use case of title for the Ops. team. We'll discuss on how to restructure or properly construct the the title to make it more user friendly, clear and concise (and ultimately more usable) as well as the workflow that'll allow user to update title (If necessary) in more reliable way!

CC: @tovari @samshara @udaynwa @mmusori @LukeCaley

[mmusori]

@frozenhelium Thanks for the hotfix. @nanometrenat thanks for the detailed review.
The updating of the title is a solid requirement. I am looking at testing the consequences of the hotfix based on the following test criteria and expected behavior.

1. Make changes on a component of an emergency page.
   a. Expected behaviour: This will not result in a change in the title.
2. Created a FR and review the tile and change the title:
   a. Expected behaviour: We can efficiently change he title of the Emergency page to a custom name
3. Create emergency pages with a custom title. Repeat step 1.
   a. Expected behaviour: i. It is possible to create a custom title for an Emergency page.
   ii. Updating the emergency page does not result in a change in title.

[nanometrenat]

Hi @frozenhelium just coming back to this, for consideration when discussing any proposed future approach to structured naming:

... As you've previously mentioned, the details in emergency might get updated (for eg: impacted countries, or disaster type) over time and the updating title accordingly while maintaining the standard format solely relies on the user, which might not always be ideal situation.

And also referring to the comment from issue #1382, if we need to include more info in the title (i.e. details of multiple appeals) then, in my opinion, it's better to generate the name from the system rather than relying on user to update it. So that we can avoid the need of updating title from the admin panel.

A reminder that even the data in the structured fields within the system still relies on a user somewhere - whether a GO user or a user in the other IFRC systems that GO pulls data from. There are many cases where the structured data in the system doesn't get updated when it should - and there are many other cases where the structured data is correct and needs to stay the way it is but that that is not what we want to focus on when we communicate. Complex emergencies (conflict situations) being a good example. Cascading hazards (floods caused by cyclones and subsequent dengue outbreak due to those floods; drought leading to food insecurity) being another good example.

There are also internal mismatches for many emergencies - where the disaster type against the appeal/DREF is not the same as the disaster type on the GO emergency - yet the two are mapped together and both show on GO. Again, often there is a good reason for the difference! If automating, need to make the correct decision as to which of these fields to refer to! And also put in place the right business processes to ensure that they are updated if required. I've put more details over here: #1694

Auto-naming field reports is not such a big deal as they are a single point in time report based on information at that moment. For anything longer term though there needs more consideration.

Thanks as ever.

[nanometrenat]

xref IFRCGo/go-api#2422 for the hotfix used to revert. Thanks a lot team for fixing this - and for updating the changed names/titles also, hugely appreciated. @tovari let me know if I should close this ticket or if you want to keep it open for further discussion.

Also I had previously written the below but seemingly hadn't saved - so saving now! Cheers

Agree that we need to differentiate between Nepal Floods 2024 vs other Nepal Floods - but presumably that could also be done by improving the filtering and what's displayed on the various pages and search results, so that dates and appeal codes are shown as well as the title/heading/name, without having to actually include it as an inescapable part of the name.

@frozenhelium I'm not sure if I was explicit enough in my previous comment - the existing unique identifier for all IFRC-supported operations (DREFs of all kinds, Early Action Protocols, Emergency Appeals) is the Appeal Code - informally known as the MDR code - which is already integrated into GO. This is the code that is the reference for all donor comms (e.g when pledge contracts are signed, and pledge/appeal/emergency operations reports are issued) and is also the reference all internal emergency operations meetings - e.g. the below is the list of operations ongoing in Philippines right now, copied from the email in which the APRO Ops team ask for the weekly internal updates. The code for the operation I logged the ticket about above is MDRPH056

• MDRPH053
  Philippines – Floods
• MDRPH054
  Philippines – Flood/Habagat Enhanced by STY Carina
• MDRPH056
  Philippines – Typhoons and Flood EA  
• EAP
  • Philippines Flood (EAP2021PH02)
  • Philippines Typhoon (EAP2024PH03_MDRPH055)
  • Philippines Drought [in development]

MDR codes contain the ISO-2 country code as letters 4 and 5 (noting though that sometimes multi-country operations have different structures). There's no date encoded in the MDR code, but it's sequential so from that you can figure out ordering. MDR code is shown on emergency page and it would be super useful if it could be shown in search results and also be indexed in search xref #1639 (comment) as this is the primary identifier internally in IFRC