feat: display activity assignment target (M2-7407, M2-7408)

[qiushihe]

📝 Description

🔗 Jira Ticket M2-7407
🔗 Jira Ticket M2-7408

This PR implements the display of activity assignment target, when the target is not the same as the respondent.

📸 Screenshots

Activities Listing Screen

🪤 Peer Testing

1. Sign into the admin app using full-account-1
2. Create an applet with 3 manual-assigned activities: activity-1, activity-2 and activity-3
3. Invite full-account-2 to the applet
4. Add 2 more limited accounts: limited-1 and limited-2
5. Assign activity-1 to full-account-2 with limited-1 as target
6. Assign activity-2 to full-account-2 with limited-2 as target
7. Assign activity-3 to full-account-2 with full-account-2 (i.e. "self") as target
8. Sign into the mobile app as full-account-2
9. Click on the applet from the applets listing screen
10. At this point, the assignment target badge should be visible for activity-1 and activity-2, but not activity-3
11. Start either activity-1 or activity-2
12. At this point, the assignment target badge should be visible on every step of the activity
13. Start activity-3
14. At this point, the steps of the activity should not have any assignment target badge

✏️ Notes

This PR also implements parts of: 🔗 Jira Ticket M2-7408

For M2-7408, both the assignment target badge and the assignment target banner are implemented in this PR. However, since the mobile app is currently missing the "welcome" screen, the banner is temporarily placed in ActivityItem.tsx, and is hidden. When the related bug ticket is being worked on (https://mindlogger.atlassian.net/browse/M2-7917), the banner should be moved into the correct place on the welcome screen.

[farmerpaul]

Hey @qiushihe, before I go too deep into your code, I thought I'd share some feedback in testing this PR as I think it may entail some (hopefully minimal) refactoring.

I have many activities, flows, and assignments locally, since I've been working on MI Assign for some time. In the Web App, each activity assignment is listed as a distinct item, including those for in-progress activities and flows.

However in the mobile app, I still only see one instance of each activity/flow, despite the fact many of these activities/flows have several assignments.

Web	Mobile

Being able support increased granularity of activites/flows, including in-progress activities/flows – now tracking the assignment as well – was a non-trivial part of the work I did for M2-7405 and M2-7406.

I see that this was not made explicit in the Jira ticket, and I apologize for not thinking to mention it. Maybe I thought that since you'd reviewed my work on M2-7405 you'd have clocked that, but I shouldn't have assumed!

Anyway I suspect adding that support will just require building upon your current work. Please let me know if you have any questions around this change!

[mbanting]

I see that this was not made explicit in the Jira ticket, and I apologize for not thinking to mention it. Maybe I thought that since you'd reviewed my work on M2-7405 you'd have clocked that, but I shouldn't have assumed!

Anyway I suspect adding that support will just require building upon your current work. Please let me know if you have any questions around this change!

Oh no. Looking at the AC for M2-7407 this was clearly not stated and is missing entirely. There's actually several differences in the AC between this ticket and the web version, M2-7405 even if there shouldn't be.

Left a comment on the ticket for Cari. Let's take the conversation there and perhaps huddle in the morning.

[qiushihe]

@farmerpaul I just pushed up all the refactor works I've been working on for the past several days. And I think I got everything covered. So this is now ready for review.

Please take a look when you get a chance. Thanks!

[farmerpaul]

Just noted a couple remaining issues, which we've discussed via Slack:

• This work isn't behind the feature flag enableActivityAssign yet – please make sure functionality is unchanged when this feature flag is turned off. And when the flag is "ON":
  • When an activity is set to auto-assign = false, and it has no manual assignments, I was still able to see the activity in the list of activities to be able to take. Unassigned activities should in fact be omitted from the list.
  • Update activity/flow progress store record key to only have target subject specificity when it's not self report

I know you're working hard on this and I appreciate your persistence! ❤️

[qiushihe]

Hi @farmerpaul I finally finished all the changes, including the feature flag and those other changes you requested.

The feature flag is only checked at 1 place: on line 135 of src/widgets/activity-group/model/services/ActivityGroupsBuildManager.ts, so you only have to edit that if you want to toggle to see the differences.

Please take another look. Thanks!

I'm also happy to do more walkthrough/huddle/whatnot too 😄

[farmerpaul]

I have a bit more feedback @qiushihe. I reviewed commit by commit to help me digest what the changes were more easily (and prevent my browser from to slowing to crawl during review). But even so, I will admit I only skimmed some of the more bulky commits in order to maintain my sanity, as it's a lot for me to absorb!

I really appreciate the walkthroughs you've given both via huddle and the demo, and I understand the majority of the refactoring changes you've made. But nevertheless I may have missed some details – hopefully QA will catch anything I've missed.

[qiushihe]

@farmerpaul okay I think I got everything covered. Please take another look. Thanks!

[farmerpaul]

Hey Billie, great work on all of this!! Thank you for making those changes. I have one last request, but preapproving because I have total faith you'll be able make this change without further approval, and I'd like to speed along getting this into QA.

Another change I made in the web app was to sort the activities/flows according to the AC. The AC says to sort only by subject first name, but I opted to sort both by first name, then last initial.

The original sort method is also inefficient, performing two calls to .filter(), then two calls to .sort(). I optimized it to use a single .sort() call, as well as taking into account target subject. Here's my version, feel free to copy-paste/adapt:

  const sort = (eventEntities: EventEntity[]) => {
    eventEntities.sort((a: EventEntity, b: EventEntity) => {
      const aIsFlow = a.entity.pipelineType === ActivityPipelineType.Flow;
      const bIsFlow = b.entity.pipelineType === ActivityPipelineType.Flow;

      // Order flows first
      if (aIsFlow && !bIsFlow) {
        return -1;
      } else if (!aIsFlow && bIsFlow) {
        return 1;
      }

      // Then order by entity order
      const orderDiff = a.entity.order - b.entity.order;
      if (orderDiff !== 0) return orderDiff;

      // Then order self-reports first
      if (!a.targetSubject) {
        return -1;
      } else if (!b.targetSubject) {
        return 1;
      }

      // Then order by target subject first name
      const firstNameDiff = a.targetSubject.firstName.localeCompare(b.targetSubject.firstName);
      if (firstNameDiff !== 0) return firstNameDiff;

      // Then order by target subject last name
      return a.targetSubject.lastName.localeCompare(b.targetSubject.lastName);
    });
  };

Then it's just called using:

    sort(eventEntities);