Ability to set status back from closed -> open

[LucieGueuning]

it becomes mission history. I want to change status back to explo. I couldn't. Would you mind, manually, re-iterate this event back to 'explorations status' please?

Status should be editable even once the project is closed.

[matthewberryman]

@LucieGueuning I have re-opened that particular event in the database. @qclin Please work on functionality so that end users (with operator permissions - ref. other write-protected APIs) can re-open events; needs event status set to 'active' and also need to revert event.metadata.event_status as well.

[LucieGueuning]

You didn't re-open the flood and dam collapse. You re-opened the Flood in Cambodia which is also good. Please re-open the following one:

[LucieGueuning]

@matthewberryman Urgent as I would like to send out email with link to this specific event

[matthewberryman]

@LucieGueuning on it, will send you a whatsapp when ready.

[matthewberryman]

@LucieGueuning This is now fixed, my bad for getting confused earlier (I hadn't had enough coffee ;) - see whatsapp for more details.

[LucieGueuning]

User is not allow to edit status back to monitoring. Issue while having event closed still under monitoring status. Should be notice as completed (stayed as a monitoring event).

should be consider in Phase 2 Extension

[matthewberryman]

@LucieGueuning This was added in the code but it didn't deploy due to a build failure, now rectified, and this is now being deployed to dev.

[matthewberryman]

@qclin

[matthewberryman]

This got lost in some other changes and needs to be put back in.

[mehrdadgit]

Hi @matthewberryman @qclin With the current way of handling events and missions this is a bit tricky; so in order to this as properly as possible, some points to consider are as follows.

Current state:

• when an event is updated (PUT api/events/:id ) if req.body.status === 'inactive' a new mission is created and the event metadata is copied to the mission properties.
• This newly created mission does not keep track of the id of original event. So, despite the fact original event record is there, there is no way of knowing to which event a mission belongs. Also a mission might get edited by a user while the original event record stays the same/out-of-date.
• In my opinion, for handling re-opening of a mission, in terms of API, this has to be revised so that we have consistency and a clear logic.

A couple of alternatives in handling this:

1. Get rid of missions table and define a mission as any event with status === 'inactive.
2. Backfill the id of event when creating a mission like a event_id field in properties or a brand new, non-json field. When the user wants to re open a mission: just change the status of the corresponding event then delete the current mission record from DB. (note the mission might have been edited but the original event record will not have the latest changes).
3. Keep DB structure as is and when you need to reopen a mission -> create a brand new event ( with a new id) based on the mission. (and to avoid duplicated records: delete the event record when is turned to mission and vice versa)

(1) is my favourite option but I believe it would need require a lot of re-work in terms of currently stored missions in DB, front-end changes, etc ? (3) seems like a bit of extra-work as well ? (2) might be easiest at the expense of lost consistency to some extent...

In any case, I suggest a separate endpoint possibly under api/missions/reopen to handle reopening of an event, and in terms of UI I suggest a separate button on missions modal rather than trying to capture the status-change of the mission.

Just suggestions and observations; hope that helps, and sorry for long message :)

[matthewberryman]

@mehrdadgit Thing is there are a lot of missions now in prod, and (2) tracking event_id is what I had in mind for this.

[matthewberryman]

But for (2), can we not copy JSON properties/metadata back over? That helps ensure consistency. Although if problematic it's not too huge an issue, as this is mostly for accidental closure so there shouldn't be too much of a gap.

[mehrdadgit]

ok @matthewberryman how do we deal with finding the event id of currently stored missions in DB ?

[matthewberryman]

@mehrdadgit I'm not worried about those (I can manually find and reopen and copy if necessary in those cases)

[mehrdadgit]

Done on issues/174 branch needs operator with write permission for testing.