1010135 - Should go back to event detail view after we edit an event.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Calendar, defect)

Description

[Evan Tseng [:evanxd]]

STR:
1. Add a event.
2. Edit the event.
3. Click done to save.

Expected:
Back to the detail event view.

Actual:
Go to month view.

Please refer to https://bugzil.la/1007546#c6.

Comment 1

[Igor]

I would like to work on this.

Comment 2

[Miller Medeiros [:millermedeiros]]

Igor, the code that handle this is kinda confusing but take a look at `views/event_base.js` and `views/modify_event.js` and search for `returnTo()` and `returnTop()`... that is basically what needs to be changed. It would be great if we could simplify this logic. Let me know if you need any help.

Comment 3

[Igor]

Thanks @millermedeiros, I will look into that. 

I would like to also confirm something: what is the expected behavior after the user ADDs an event? Should it show the event or should it go back to the month view?

In my tests it seems that _returnTo and _returnTop both point to the correct place in persistEvent when editing an event, but they are not used right now.

Comment 4

[Igor]

Tagging :millermedeiros.

Comment 5

[Igor]

I think I got it working now. My solution is to propagate the returnTop variable to all views that inherit from EventBase. This way they always know where to go back to. The value is copied in the dispatch method and is propagated in persistEvent and primary (Edit button). 

However, I also think that the actual code with returnTo and returnTop is confusing. Specially since returnTop actually modifies _returnTop (sets it to undefined)... And I don't think I understand why returnTo exists... The only important view to be stored is the top-level one, no? The other ones are redirected using router.go or use history.back() if we want to cancel "edit"... Can I try to simplify this?

Comment 6

[BMO Automation]

Firefox OS is not being worked on