Confirmed users
383
edits
Gaia/SMS/Scrum/2.2S13: Difference between revisions
Jump to navigation
Jump to search
m
→Day 6: 12th May
| Line 285: | Line 285: | ||
=== Day 6: 12th May === | === Day 6: 12th May === | ||
====Steve==== | |||
* Create subtasks for composer/conversation separation. | |||
** {{Bug|1161985}} - [Messages][NG] Split recipient and non-compose related styling from compose.css, will create a WIP for recipients.css separation | |||
** Got some feedback from form duplication clean up WIP. Will polish it in background. | |||
* {{Bug|1162031}} - [Messages][New Gaia Architecture] use the bridge with a shared worker | |||
** Utilize browserify to package the lib into another name for testing first. Will start from draft(since mobilemesage/contact seems unable to work in worker yet) | |||
**:(Oleg) You'll probably need to keep eye on my PR that modifies drafts as well to have less conflicts :) | |||
**: (Steve) yeah I know you're also working on this part | |||
* Gave some feedback for notification system message issue | |||
Today: | |||
* Create more subtasks for composer/conversation separation in js part. | |||
* Start from moving the draft into worker and utilize the threads lib. | |||
* Review draft handling patch | |||
* Some tasks for background | |||
** Fix the attachment menu for closing the option menu manually | |||
** gaia-component stuff | |||
** file loading in Tamplate.js | |||
====Julien==== | |||
* Absent/no report | |||
====Oleg==== | |||
* {{Bug|1155509}} - [Messages][New Gaia Architecture] Split ThreadList view from current structure | |||
** Started to work on this again, remove some more InboxView-ConversationView dependencies (related to contact change, drafts update and few others) (in progress). | |||
** I still see that we have three dependencies that I don't have good plan for: | |||
*** When we enter conversation we need to mark conversation as read in InboxView (and when this conversation is rendered, it was a problem when app was opened from notification for example) - here we can probably rely on future service that will emit appropriate event and local IDB; | |||
*** ConversationView currently decides whether or not InboxView will show "draft saved" bottom banner - will probably be resolved once we change drafts auto save/discard behavior discussed in dedicated email thread recently; | |||
*** When we delete message in conversation view and if it was the last one - we should update Conversation in InboxView - we can probably resolve it with our own messaging service that fires event (we currently have ondeleted event in mozMobileMessage but it only contains messageId, so that InboxView can't know from which thread message was deleted). | |||
:(Steve) About the deletion in Inbox, I think you could get threadid from Threads, but you might need to expose a method for it(or fire a event from Threads once we move it to "service") | |||
:(Oleg) Yeah I was thinking about our custom service that knows from which thread message was deleted, with just mozMobileMessage event I need single messages map in threads to do fast lookup, or Threads.js has single messages map already? | |||
:(Steve) Ya I think Threads.js maintains a messages map now | |||
:(Oleg) Good, will check this out, thanks! If we delete message then it should guarantee it was added to this messages map. I think we don't have cases when message is deleted without visiting thread (only if we remove conversation from InboxView, but in this case we don't need to update conversation :)) | |||
* {{Bug|1010216}} - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI | |||
** Handled feedback comments and asked for review (in review). | |||
* {{Bug|1156464}} - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app. | |||
** Got Steve's feedback, Steve do you think we can have v2.2 solution for both v2.2 and master (I plan to have integration test for master once dependency is resolved, not sure if v2.2 gets this fix - {{Bug|1162899}} - [B2G Desktop] navigator.mozHasPendingMessage always returns false in in-process app) and improve for master later if needed? (in progress). | |||
:(Steve) Shouldn't we nominate 1162899 as 2.2 blocker as well? I'm fine if we use same approach for 2.2/master(actually I'm not sure if we can get much benefit from changing navigation part in master now) | |||
:(Oleg) Yeah, I'd keep it as in v2.2 patch currently, it will likely change in master anyway, maybe we'll have much better idea for ng later. | |||
* {{Bug|1127398}} - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu | |||
** No progress since yesterday (in background). | |||
Other: | |||
* Left feedback for Steve's patch related to moving toasters to Compose; | |||
* Left some more thoughts on improving inter-app integration tests in Johan's PR. | |||
Today: | |||
* Will handle review/feedback/need-info requests; | |||
* Will work on review comments and assigned bugs. | |||
=== Day 7: 13th May === | === Day 7: 13th May === | ||
=== Day 8: 14th May === | === Day 8: 14th May === | ||