[Awaiting Payment 25th June] [QBO] Implement the Required toggle in the RHP with multiLevel tags.

[trjExpensify]

Coming from here and a follow-up to this PR.

1. We need to implement a new command to allow making an individual tag level required (i.e Customers required, Classes not required)
2. Add the Required toggle in the RHP of each tag level when multiTags are enabled with QBO, like so:

CC: @luacmartins @s77rt @hayata-suenaga @aldo-expensify @zanyrenney

[melvin-bot]

Current assignee @trjExpensify is eligible for the NewFeature assigner, not assigning anyone new.

[trjExpensify]

That PR is still in review.

[trjExpensify]

That PR has merged. @hayata-suenaga this is backend right to implement that command?

[hayata-suenaga]

@trjExpensify, yes it involves the backend change.

Currently, we have SetPolicyRequiresTag.

That code is just enabling all tags in the tags list if there is a tags list (I assume this means that the parent level tags or multi level tags).

We either need to create a new Web-E command or modify the existing command to accomodate the multi level tag situation.

I'll try to work on this but might need some help from @aldo-expensify. I'll open a draft PR today and assign @aldo-expensify so that we can work together.

[trjExpensify]

Cool, I was looking at this on OldDot early to see what we call when we set one of the levels as required:

.. and equally, enable/disable one of the imported tag list's tag values:

Not sure if you looked at that, or if it's helpful here.

[hayata-suenaga]

Memo for myself

Policy_Taglist_Set_Required

tagListIndex -> index of the tag list? each tag list doesn't have an ID?
requireTagList -> boolean indicating if each tag list is required

PolicyAPI::setTaglistRequired

• Should I create a new command or should I conditionally send the onyx update?

[hayata-suenaga]

memo for myself: Is there something that needs additionally done for the command meant for New Expensify?

[hayata-suenaga]

Reopened an App PR here for this issue (the previous one has issues with merge conflicts) 🙇

[aldo-expensify]

Fixed lint issue with PR #42972

[hayata-suenaga]

With Aldo's final help, the PR has been deployed. removing the reviewing label

[hayata-suenaga]

Payment for @s77rt for the reviewer role after the regression period.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[hayata-suenaga]

Checked the above deploy blocker and commented there

[trjExpensify]

Looks like we're working on a follow-up here.

[hayata-suenaga]

Yes, Rodrigo is working on a regression fix in this PR

[hayata-suenaga]

The fix for the regression was deployed to production.

The payment is handled in this issue. Closing this issue now. Thank you everyone!

[trjExpensify]

Alright, but doesn't that mean @s77rt is required payment of $125 for the initial PR?

[hayata-suenaga]

that's right! Good thing I didn't close this issue 😓

[hayata-suenaga]

@trjExpensify, if you could handle that payment, I'd appreciate it 🙇

[trjExpensify]

Cool, @s77rt sent you an offer! Payment summary as follows:

• $125 for the C+ review of the PR

Thanks!

[s77rt]

@trjExpensify Accepted! Thanks!

[trjExpensify]

Paid!