Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#10817 closed defect (fixed)

friendstray does represent buddies of a shared activity we have not joined yet

Reported by: erikos Owned by: erikos
Priority: high Milestone: 11.2.0-M4
Component: sugar Version: Development build as of this date
Keywords: collaboration Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

Steps to reproduce:

A: share Activity

B: in the friendstray of B you will see A and B even so we have not joined the shared activity yet.

We listen to activity-added from the neighborhood model, but this is emitted whenever a new activity is added to the neighborhood view not when we have joined it.

Related commits: ef45d2946f45ebfd3c50154b74c2b53b936724a9

Change History (14)

comment:1 Changed 4 years ago by erikos

  • Priority changed from normal to high

comment:2 Changed 4 years ago by erikos

  • Action Needed changed from code to review
diff --git a/src/jarabe/frame/friendstray.py b/src/jarabe/frame/friendstray.py
index 31a9809..4055340 100644
--- a/src/jarabe/frame/friendstray.py
+++ b/src/jarabe/frame/friendstray.py
@@ -75,6 +75,10 @@ class FriendsTray(VTray):
     def __neighborhood_activity_added_cb(self, neighborhood_model,
                                          shared_activity):
         logging.debug('FriendsTray.__neighborhood_activity_added_cb')
+        active_activity = shell.get_model().get_active_activity()
+        if active_activity.get_activity_id() != shared_activity.activity_id:
+            return
+
         self.clear()
 
         # always display ourselves

The code path that listens for the 'activity-added' signal is used to track the following use case: 'A' starts an activity (he gets the 'active-activity-changed' signal from the shell), he then at a later point shares the activity. In order to track joining/leaving buddies he needs to get the shared activity. On other machines if we receive the 'activity-added' signal we can ignore it, therefore the check if the current active activity is the shared one.

comment:4 Changed 3 years ago by erikos

When testing please be aware that #10801 is not fixed yet.

comment:5 Changed 3 years ago by erikos

  • Action Needed changed from review to test in build

sugar-0.92.2.9.gb092121-1.fc14.olpc.noarch.rpm, build 871

comment:6 Changed 3 years ago by godiard

Working in 871

comment:7 Changed 3 years ago by dsd

Fails for me, confirmed twice. A=XO-1, B=XO-1.5, both running 11.2.0 candidate build 871

  • Boot both laptops, connect to adhoc network, check that they can see each other in neighborhood view
  • Open neighborhood view on B, press frame key to open frame
  • Open Speak on A, enable sharing with entire neighborhood
  • B's neighborhood view updates to show that A is sharing the activity, and at the same time, A appears in the friends tray in B's frame, even though B has not joined yet.

comment:8 Changed 3 years ago by dsd

  • Action Needed changed from test in build to add to build

Wasn't shipped in build 871 as planned

Fixed in sugar-0.92.2.9.gb092121-1.fc14.olpc.noarch.rpm

comment:9 Changed 3 years ago by erikos

sugar-0.92.3.1.gc106a82 is the exact build name, is in my public repo.

comment:10 Changed 3 years ago by dsd

  • Action Needed changed from add to build to diagnose

The above test case still fails for me in exactly the same way in 11.2.0 candidate build 873, which includes sugar-0.92.3.1.gc106a82

comment:11 Changed 3 years ago by erikos

  • Action Needed changed from diagnose to add to build

Is in sugar-0.92.3.4.g50b9373-1.fc14.olpc.noarch.rpm

When testing please be aware of #10801, which is not fixed yet.

comment:12 Changed 3 years ago by erikos

  • Action Needed changed from add to build to test in build

Did land in 874.

Does work fine for me, tested in 874.

comment:13 Changed 3 years ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

Now working for me in 11.2.0 candidate 874.

Note: See TracTickets for help on using tickets.