show recents in participants page based on action type

@eVoloshchak @mountiny
Details
Currently, the recent list on the participants’ page displays the participant details of the most recently changed reports at the top. This PR, now, shows the participant details of the most recently changed reports at the top only when they were involved in the action for which these reports are shown. For example, when user A generates a scan receipt money request in a 1:1 DM for User B, the recent list shows participant B in the recent list since the 1:1 DM chat report has a recent history of a scan money receipt.
How do we do this?

For Money Request action types:
We have three types of money requests i.e. manual, scan, and distance which are the three types of action for money requests. These actions are initiated by the user via the tab selection. Further, for manual and scan money requests, the user can additionally trigger a fourth action i.e. split action by clicking on the split button on the participants’ page.
For identifying the reports based on these four types the action, we rely on the transactions available locally in Onyx as follows:
Split: When the comment source is set to split within a transaction.
Scan: When there is a valid receipt within a transaction
Distance: When the transaction contains a  customUnit type and custom unit name as Distance
Manual: None of the above
For transactions of a given action type, we identify their respective chat reports i.e. 1:1 DM Chat Repot or Workspace Chat Report via the money request report. The most recent of these chat reports will be displayed.

For Task action type:
During task creation, we display the participants’ page during the assignment of the task. This is what makes the task action type.
Here, we identify the parent chat report of all tasks available within Onyx. The most recent of these chat reports are displayed in the recent list.

Note
Since we depend on transactions and task reports to find the most recent chat reports, it is possible that we do not find the most recent chat report just because the dependant transactions and task reports are not available locally in Onyx even though the chat report is locally available. This scenario occurs when the remote user generates a transaction/task that is not yet accessed locally by the local user or during a fresh sign-in. Further, it may be possible that the transaction/task report and the parent chat report are locally present but the intermediate reports are not present locally. Such chat reports will be missing from the recent list as they could not be traced back from the transaction/task report.
Conclusion: Currently, we will use when its available as there is some BE planning that is pending as mentioned here
Fixed Issues
$ https://github.com/Expensify/App/issues/34227
PROPOSAL: https://github.com/Expensify/App/issues/34227#issuecomment-1908444762
Tests
Precondition: For Money Requests, ensure that all previous money requests are paid.
Test 1: Task Creation

User A shares task with User B in 1:1 Chat Report.
Click Global FAB -> Assign Task
Enter task title and click Next
Click on Assignee to open participants page
Verify that recent list shows User B as the first one

Test 2: Manual Money Request

User A generates a Manual money request for User B in 1:1 Chat Report
Click Global FAB -> Request Money -> Manual tab
Enter amount
Click Next to launch Participants’ page
Verify that recent list shows User B as the first one

Test 3: Split Money Request

User A generates a Split money request with User B in 1:1 Chat Report
Click Global FAB -> Request Money -> Manual tab
Enter amount
Click Next to launch Participants’ page
Click Split on one of the participant (Note: Do not select User B).
Verify that recent list shows User B as the first one

Test 4: Scan Receipt Money Request

User A generates a Scan receipt money request for User D in 1:1 Chat Report
Click Global FAB -> Request Money -> Scan tab
Choose a receipt file to launch the  Participants’ page
Verify that recent list shows User D as the first one

Test 5: Distance Money Request

User A generates a Distance money request in Workspace X
Click Global FAB -> Request Money -> Distance tab
Select a start and finish waypoints
Click Next to launch the  Participants’ page
Verify that recent list shows Workspace X as the first one

Test 6: Add Comment to a Chat Report that has a previous manual money request

User A adds a new comment for User B  in 1:1 Chat Report (Note: User B already has a previous manual money request)
Click Global FAB -> Request Money -> Manual tab
Enter amount
Click Next to launch Participants’ page
Verify that recent list shows User B as the first one

Test 7: Test for default recent list
Precondition: Have split requests with few participants in User A’s account

SignIn as User A.
Click Global FAB -> Request Money -> Manual tab
Enter amount and click Next to launch Participants’ page
Click Split on all the participants.
Verify that recent list shows the default list as shown before the implementation of this feature.

Note: All the above 7 tests can be performed by initiating a money request/task creation from remote user. However, the only thing to take care of is that the local user should open the respective transaction/task.

[x] Verify that no errors appear in the JS console

Offline tests
Same as the Steps in Tests Section.
QA Steps
Same as the Steps in Tests Section.
Notes

Please refer the notes section in PR description for exceptions.
While testing money request steps, it has been observed that the Report Preview timestamp does not update when there are previous open money requests. Because of this, adding a new money request when there are previous open money requests will not bring this report in the top of the recent list. So, for testing this PR, please ensure that there are no previous open money requests. This means that all the previous money requests must be paid.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[ ] I included screenshots or videos for tests on all platforms
[ ] I ran the tests on all platforms & verified they passed on:

[ ] Android / native
[ ] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes

[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)

[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web - Safari

Test 1: Task Creation
https://github.com/Expensify/App/assets/3004659/09965979-832a-413d-8dcd-138f57f4e931

Test 2: Manual Money Request
https://github.com/Expensify/App/assets/3004659/50213899-a738-4659-bd43-0cd40a5ffc40

Test 3: Split Money Request
https://github.com/Expensify/App/assets/3004659/693f83c1-99ae-4b6e-b06f-32efaec493a2

Test 4: Scan Receipt Money Request
https://github.com/Expensify/App/assets/3004659/63d5cbd5-b99a-456c-99ba-70a1a91a7b71

Test 5: Distance Money Request
https://github.com/Expensify/App/assets/3004659/4ecee920-faaa-499c-904c-54884a03f507

Test 6: Add Comment to a Chat Report that has a previous manual money request
https://github.com/Expensify/App/assets/3004659/63fb43c0-a511-41aa-bdb5-9594f49392ba

Test 7: Test for default recent list
https://github.com/Expensify/App/assets/3004659/eb97a284-4a99-40ad-bf61-c154f684f7a5

Mobile Web - Safari

Test 1: Task Creation
https://github.com/Expensify/App/assets/3004659/aa367be1-8087-4d09-a15e-dbbbe49809d1

Test 2: Manual Money Request
https://github.com/Expensify/App/assets/3004659/c019c969-a64c-4688-b850-45e03d55f633

Test 3: Split Money Request
https://github.com/Expensify/App/assets/3004659/d0348068-0e37-4891-a48e-90f4676f30d3

Test 4: Scan Receipt Money Request
https://github.com/Expensify/App/assets/3004659/6109b04b-acb3-427d-a661-ce02a1c6ccfa

Test 5: Distance Money Request
https://github.com/Expensify/App/assets/3004659/eaccc165-5555-4ff2-99a0-86ea88c265b3

Test 6: Add Comment to a Chat Report that has a previous manual money request
https://github.com/Expensify/App/assets/3004659/72470f7f-f42d-494e-b645-6f1b84a1e54f

Test 7: Test for default recent list
https://github.com/Expensify/App/assets/3004659/ba031dc3-b898-43c1-bfb1-619176fc023c

Desktop

Test 1: Task Creation
https://github.com/Expensify/App/assets/3004659/90e40bfb-cd6f-480b-9513-cad7769ae805

Test 2: Manual Money Request
https://github.com/Expensify/App/assets/3004659/44308dee-c21a-4567-948a-7b7fa13f95f0

Test 3: Split Money Request
https://github.com/Expensify/App/assets/3004659/5c11fabe-1c15-4f53-9a13-9c87bb3ba49e

Test 4: Scan Receipt Money Request
https://github.com/Expensify/App/assets/3004659/b3d5aa44-d539-4725-81e6-712c3c0e08d2

Test 5: Distance Money Request
https://github.com/Expensify/App/assets/3004659/b08fb307-8de1-41c8-a227-f9ed71d80d5c

Test 6: Add Comment to a Chat Report that has a previous manual money request
https://github.com/Expensify/App/assets/3004659/50403452-e8bf-4e7e-b2de-e09d87504163

Test 7: Test for default recent list
https://github.com/Expensify/App/assets/3004659/2324f328-f45a-463c-a01c-54e4a806a8d0

iOS

Test 1: Task Creation
https://github.com/Expensify/App/assets/3004659/254e205c-a640-4cda-bf08-2ed0d8b06d33

Test 2: Manual Money Request
https://github.com/Expensify/App/assets/3004659/b29dfed5-c170-4973-9014-b401492101f7

Test 3: Split Money Request
https://github.com/Expensify/App/assets/3004659/aee7a60d-bdb5-47c6-bd19-7b4cf3752332

Test 4: Scan Receipt Money Request
https://github.com/Expensify/App/assets/3004659/a26ad55c-194c-4924-9fa4-11de8d1f8e91

Test 5: Distance Money Request
https://github.com/Expensify/App/assets/3004659/4efc252b-371e-475b-a0e5-3411773fe37f

Test 6: Add Comment to a Chat Report that has a previous manual money request
https://github.com/Expensify/App/assets/3004659/c2da921c-0b4c-48ae-a698-39d88c8327f6

Test 7: Test for default recent list
https://github.com/Expensify/App/assets/3004659/ea667790-e90f-485e-803e-8e33255c66ae

Android
TODO

Mobile Web - Chrome
TODO

thanks! thats your eta to get this ready for a review?

Sorry. Unfortunately, I could not complete this today.
And, I think I may need more time as this is complex enough to easily cause regressions.
Since it’s late night here, I will have a look into this tomorrow and arrive at a proper ETA.

@eVoloshchak @mountiny
The PR is ready for review.
I have documented the implementation details in Details section of the checklist.
Also, I have tested with web safari environment and works well too.
Post review, I will complete testing for the remaining environments too.
Thanks for your patience.

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Bug:

Click Global FAB -> Request Money -> Manual tab
Enter an amount
Click Next, select a user (userA) from the Participants list
Click Request
Click Global FAB -> Request Money -> Manual tab
Enter an amount, click Next
Verify that recents list shows userAas the first one
Click Global FAB -> Request Money -> Scan tab
Upload a receipt file
Select a different user (userB) from the Participants list
Click Request
Click Global FAB -> Request Money -> Manual tab
Enter an amount, click Next
The first user in recents list is userB, while it should be userA, since this is a manual tab

https://github.com/Expensify/App/assets/9059945/a82fdd6f-3e8f-4f45-a6f6-65d0f76b8407

14. The first user in recents list is userB, while it should be userA, since this is a manual tab

In your test video, I notice that User<EMAIL_ADDRESS>had two existing requests present when the scan receipt was generated.
Can you please check if one of the other two requests is manual?
And if there is a manual request, I think it is expected to show<EMAIL_ADDRESS>at the top for this new manual request because this is the most recent report which had changes and which also has a manual request in it.
Does this make sense?

@eVoloshchak
Thanks for your feedback. I have integrated your feedback comments. Tests well too.
Please review.

@mountiny @eVoloshchak
I just added a section Points to note in the PR details description here with some open points.
What are your thoughts on these?

https://github.com/Expensify/App/assets/9059945/df4b1eb8-7ae6-4626-b4bc-5f3f42251334
Blocked by this issue (also present on main), endless skeleton view after logging in

@eVoloshchak can you run npm ci please?

@mountiny, that did the trick, thank you!

Since we depend on transactions and task reports to find the most recent chat reports, it is possible that we do not find the most recent chat report just because the dependant transactions and task reports are not available locally in Onyx even though the chat report is locally available. This scenario would most likely occur when the remote user generates a transaction/task that is not yet accessed locally by the local user or during a fresh sign-in.

This is a valid point. Especially if you consider the case where the user is logged in on multiple devices, the transactions won't be available locally
@mountiny, is this something we'd like to resolve (also that would require quite a few changes on the back end)?

The existing implementation considers recent changes only within chat reports while showing the recent list of participants’ page. This means that changes in transaction reports, task reports, money request reports, and thread reports would not be considered while showing the recent list on the participants’ page.

I think it should include all of the available transactions (not only from chat reports). @mountiny, do you agree?

It may be possible that the transaction/task report and the parent chat report are locally present but the intermediate reports are not present locally. Such chat reports will be missing from the recent list as they could not be traced back from the transaction/task report.

This is similar to the first point, it would require changes to the back end (not sure how feasible it is, we can't load ALL of the transactions. We could load only the recent ones, since it's all we need)

is this something we'd like to resolve (also that would require quite a few changes on the back end)?

Lets just use this when its available for now any backend changes would have to be planned more

I think it should include all of the available transactions (not only from chat reports)

Not sure what this means exactly, when you request money its on the expense reports, tasks can be anywhere

This is similar to the first point, it would require changes to the back end (not sure how feasible it is, we can't load ALL of the transactions. We could load only the recent ones, since it's all we need)

again, if not available default to the classic behaviour

@mountiny
Thanks for your feedback.
So, that means two queries got clarified, and only one more is left. Here are some more details about this query.

Not sure what this means exactly, when you request money its on the expense reports, tasks can be anywhere

Let’s take the example of a money request.
When we generate a money request (say Manual), there are three reports representing this manual request. A) Chat Report B) Expense/IOU Report C) Transaction Details Report. Currently, we only look at the Chat Report to see if that has changed to qualify for a berth in the recent list. The question here is this:
Do we also have to look at the changes in the expense/iou report and transaction detail report for adding the participant to the recent list is the question here?
Also, a similar question arises for tasks as well. While the parent chat report of the task may not have changed, the task report itself may have a new comment added recently.
Does that mean the participant will be added to the recent list because of the new comment in the task report?

@rojiphil for requests, we care about the highest context - so the DMs or the workspace chat
for tasks we care about the particular page, so if I created a task in some report with reportID = 123 I want to add it there

Thanks for bringing clarity on these.

for requests, we care about the highest context - so the DMs or the workspace chat

Ok. So, the current implementation is good enough here.

for tasks we care about the particular page, so if I created a task in some report with reportID = 123 I want to add it there

Ok. So, here we care only about the parent report of the task report via parentReportID.
Currently, the implementation cares about the top-most report.
I will change this to consider only the parent report and resend it for review again.

Update:
The work is still in progress on the PR here. The changes look good and testing is in progress.
I will be able to send it across for review tomorrow my day.

@eVoloshchak
I have updated the PR checklist with additional details + screenshots for 4 platforms.
As the PR looks good in testing, please review the recent changes and let me know if any changes are required.
Meanwhile, I will complete the testing on the remaining 2 platforms (i.e. android & mweb chrome) tomorrow.

@eVoloshchak
The remaining platforms are also tested and works well.
The PR checklist is also done.
All yours for review.

https://github.com/Expensify/App/assets/9059945/a4660162-b4a3-41e0-b4b2-36241592f60d
There's a bug when performing a manual request. It works correctly when requesting money from a user you haven't interacted with, but an existing user with already existing IOU requests is not at the top of recents list
cc: @rojiphil

There's a bug when performing a manual request. It works correctly when requesting money from a user you haven't interacted with, but an existing user with already existing IOU requests is not at the top of recents list

@eVoloshchak
Exactly. That’s what I meant in the following note to QA in PR description.

1	While testing money request steps, if there is an existing Report Preview due to open money requests, the Report Preview timestamp does not update. Because of this, adding a new money request when there are previous open money requests will not bring this report in the top of the recent list. So, for testing this PR, please ensure that there are no previous open money requests. This means that all the previous money requests must be paid.

This looks like a regression introduced recently in the latest main.
Attaching a test video to demonstrate this:
Or is this intentionally added recently?
What do you think?
cc @mountiny
https://github.com/Expensify/App/assets/3004659/aa4861a1-1804-4ad5-b100-bd669b958ba7

@rojiphil @eVoloshchak I think my main concern with this change is the impact on performance. Its quite a big change to the already tight getOptions method.
Could you time the difference the getOptions take on main vs this branch for the same high-traffic account?

I think my main concern with this change is the impact on performance. Its quite a big change to the already tight getOptions method.
Could you time the difference the getOptions take on main vs this branch for the same high-traffic account?

I think I get your concern. Looking into this today.

I think my main concern with this change is the impact on performance. Its quite a big change to the already tight getOptions method.
Could you time the difference the getOptions take on main vs this branch for the same high-traffic account?

While experimenting with Timing.start and Timing.end within getFilteredOptions here on my HT account, I could not notice any significant difference between the latest main and feature branch. For money requests, the timings remain around 100ms whereas for tasks it comes to around 50ms.  Maybe we need to do more tests here.  @eVoloshchak Can you also please check on your HT account if there is a noticeable timing difference?
Here are the results:

And, here are the test videos for reference:

Main Branch
https://github.com/Expensify/App/assets/3004659/ec928b7a-1ecc-4c92-bcfd-b239506ddff6

Feature Branch
https://github.com/Expensify/App/assets/3004659/cd26f15d-01ce-4ad8-931c-446a6a60ab16

I think you could use the transactions created for that too

Currently, I am looking into this to see how we can use transactions created and get this done optimally. I will provide an update on this tomorrow my day.

@rojiphil can you merge main? I will try to create a build and then we can test on those with large accounts from internal employees

can you merge main? I will try to create a build and then we can test on those with large accounts from internal employees

@mountiny I just merged. But, I am new to this Ready to Build state. So, not sure if you want the merge to be done just before generating the build. Anyway, I will make myself available during your day so that we can take this forward.

and then we can test on those with large accounts from internal employees

I love this idea. Along with the performance check, I think this will also help us get feedback on the feature logic itself if any.

I have triggered the build

@kacper-mikolajczak @adhorodyski also curious what you think of the changes in the PR and if you can see there woul dbe potential impact on performance

I just merged again to resolve a merge conflict

I've measured getFilteredOptions taking ~30% more time compared to main
On a HT account the time fluctuates around 100-150ms, no noticeable difference compared to main when using the app

I think you are referring to the fluctuations when you mentioned ~30%. Is this correct?

Also, I just re-reviewed the changes we made in this PR. While I can think of getTransactionsByActionType here that can take some time when there are lots of transactions, we have neatly called this only for recent list fetch of money requests. Further, we have also ordered the transactions so that the most recent ones will be at the top for a quick search. Also, we return early after finding out the most recent n reports. On the other side, if no transactions are found at all, the default flow remains pretty much the same.  So, purely from the code perspective, while I agree that there will be additional computations I do not know what can cause a major hit on performance.
Curious to know your thoughts as well on any suspicious code that can impact performance.
One of the alternatives we can consider is relying only on transactions to arrive at the recent list. But this would mean that we have to agree on not supporting the Test 6 case. And I am not sure if we want to go this way. Also, I do not see any significant advantage here as we return early after identifying the most recent n reports.

I think you are referring to the fluctuations when you mentioned ~30%. Is this correct?

@rojiphil, I meant that with this change calling getFilteredOptions takes 30% more time on average (very roughly)
In practical terms, it means these changes are adding 30-50 ms, which given that the HT account has hundreds of contacts, doesn't seem like a problem

30% sounds quite a lot to be fair this can go out of hands with heavy accounts (much larger than high traffic - its closer to what admins of large policies can experience)

30% sounds quite a lot to be fair this can go out of hands with heavy accounts (much larger than high traffic - its closer to what admins of large policies can experience)

I am still not sure of the 30% impact on performance. But I also agree that having that kind of impact would not be good. Not feeling quite well today. I will have a fresh look at this tomorrow and provide an update.

I just checked again. And surprisingly, my HT account gives better performance for this PR implementation than the earlier (default) implementation. But I don't think the PR implementation has optimized the earlier implementation. Looks like for manual action type, the reports for the recent transactions were already on the top of allReportOptions. Also attaching the summary screenshot and test videos for reference.
For now, I have committed some code changes for timing logs. While the code can be tested as it is for the new logic, the earlier default logic can be tested by just replacing actionTypeForParticipants here with an empty string. Additionally, we can uncomment here to know the current action type used. And the timing log is already available here.
Please try this out on your HT account. Curious to know how the timing logs turn up for you.
Regarding the implementation logic itself, I think the only implementation that can add significant time complexity is the fetching of transactions. For this, I have shared my comment here. What do you think about this?
cc @mountiny @eVoloshchak

Recent Reports By Action Type
https://github.com/Expensify/App/assets/3004659/6fb0e33c-7498-41f2-850c-0ce981e88736

Recent Reports By Default
https://github.com/Expensify/App/assets/3004659/96912925-fc1e-4eff-84aa-f86535b312a2

Looks like we are stuck on the issue of 30% impact on performance which honestly I am not able to quantify. Even in the main branch without any of our PR changes, I see a similar behavior as mentioned here. So, not sure of the way ahead.
@eVoloshchak @mountiny What do you think we could do to take this forward from here?

@rojiphil I have asked for some other eyes on this PR but yeah I guess we will have to try this out. @rojiphil could you sync up with main please?

Thanks @hurali97 for your review comments. I have integrated your feedback and committed the code changes.
Please let me know if any other review feedback changes need to be made.

@rojiphil just to give us more confidence @OlimpiaZurek is implementing reassure tests for getOptions method which will hopefully give us more peace in mind for this change if all goes well https://github.com/Expensify/App/issues/38165

@rojiphil The new reassure test is merged so can you sync up with main please to we can see if there will be any diff shown? https://github.com/Expensify/App/pull/38387

@mountiny Merged. Regarding reassure test, I am not aware of the internals of the reassure performance but I searched for getFilteredOptions in logs and this is what I got. Hopefully, I am looking at the right place.

This seems ok to me. Also, if we are moving ahead, I will need to test this once more as quite some time has passed since we implemented this.

@rojiphil yeah that is what we are looking for, however I agree that to properly capture the impact we might need more complex scenario here.
Can you please resolve the conflicts and retest?

@rojiphil more conflicts

more conflicts

Sorry. I was not able to spend time on resolving conflicts. I will prioritize my day tomorrow on resolving them and retesting.

Can you please resolve the conflicts and retest?

Resolved the conflicts and retested too. It needed minor fixes but the core logic remains the same. The reassure performance tests also passed well. LGTM.

Test 1: Task Creation is failing for me

@eVoloshchak That’s an interesting observation. I was not able to get this problem as I was not that quick in coming back to the task creation to check if the assignee participants page is updated. For some weird reason, here it looks like the reports do not immediately include the newly created task report which is why the assignee participants page is not updated. However, this is only observed for a short period of time. It may be that the API response/pusher updates will later populate the reports with the newly created report and the assignee participants page will show the updated participants. Although I think we should fix this I also think this falls outside the scope of our current work here. Also, as it is momentary in nature it may also quality as a super-edge case. Anyway, I am making a note of this in the PR description. Does this make sense?
https://github.com/Expensify/App/assets/3004659/c14222e3-bc2f-477b-b210-df6a0a6fcd90

It may be that the API response/pusher updates will later populate the reports with the newly created report and the assignee participants page will show the updated participants. Although I think we should fix this I also think this falls outside the scope of our current work here. Also, as it is momentary in nature it may also qualify as a super-edge case

Can confirm it does work after some time (or a page refresh).
My main concern is that also means this feature won't work while offline, since we need to wait for the API response
How hard would it be to use pending actions in addition to recent actions to fix this?
On a side note, could you merge main please?

My main concern is that also means this feature won't work while offline, since we need to wait for the API response
How hard would it be to use pending actions in addition to recent actions to fix this?

@rojiphil, gentle bump on this question

It looks like the option list is not getting updated for the intermediate reports and gets updated only for the last updated report when there are multiple reports updated at the same time. In our use case here, we update two reports at the same time i.e. Assignee Report and Parent Report. The attached screenshot for logs how the assignee report does not get considered for option list updation but the parent report does here. We consider only the lastUpdatedReport here. This is the reason for the problem mentioned here. To be able to consistently reproduce the problem, we can test this in offline scenarios. A recent PR here for caching search options introduced these changes.
@eVoloshchak  Can you please confirm if you share a similar understanding here?

It looks like the option list is not getting updated for the intermediate reports and gets updated only for the last updated report when there are multiple reports updated at the same time. In our use case here, we update two reports at the same time i.e. Assignee Report and Parent Report. The attached screenshot for logs how the assignee report does not get considered for option list updation but the parent report does here. We consider only the lastUpdatedReport here. This is the reason for the problem mentioned https://github.com/Expensify/App/pull/35431#issuecomment-2043291681.

@rojiphil, thank you for the thorough explanation!
It is my understanding that we don't need a lastUpdatedReport variable, is that correct?

It looks like the option list is not getting updated for the intermediate reports and gets updated only for the last updated report when there are multiple reports updated at the same time. In our use case here, we update two reports at the same time i.e. Assignee Report and Parent Report.

This is the actual bug we need to fix. Was it introduced by https://github.com/Expensify/App/pull/38207?

This is the actual bug we need to fix. Was it introduced by #38207?

@eVoloshchak Yes. That's correct. The performance improvement via caching search options caused this.


duplicate folder ID

ansicon@debian:~$ syncthing-cli folders add vz_iso /tmp/
ansicon@debian:~$ syncthing-cli folders add vz_iso /tmp/
ansicon@debian:~$ syncthing-cli folders list
ID:                              default
Path:                            /root/Sync/    (directory)
Folder master:                   false          (master)
Ignore permissions:              false          (permissions)
Rescan interval in seconds:      60             (rescan)

ID:                              vz_iso
Path:                            /tmp/                  (directory)
Folder master:                   false                  (master)
Ignore permissions:              false                  (permissions)
Rescan interval in seconds:      0                      (rescan)
Invalid:                         duplicate folder ID

ID:                              vz_iso
Path:                            /tmp/                  (directory)
Folder master:                   false                  (master)
Ignore permissions:              false                  (permissions)
Rescan interval in seconds:      0                      (rescan)
Invalid:                         duplicate folder ID

Q: Doctor, it hurts when I do this.
A: Well, then don't do this.


Support Dahua doorbells

I am using this integration with my doorbell and it seems to work but it's missing the doorbell button binary_sensor. It would be very cool to have that too.

I also have a Dahua doorbell. I'm not sure what you mean by the doorbell button binary_sensor. I'll dig into it and try to find out and add support for it. Luckily I have a unit already so I can test easily. I'll keep you posted.
Is this just a sensor that triggers when the doorbell is pressed?

@bogdanr This is done and added in 0.7.0
It'll add a binary sensor for the button press:

Please reopen if there's any issues. Thanks!

could this support amcrest doorbells too?

I don't know. Would just have to try.

just have, video feed ok,
motion alert works,
inferred switch does off- auto.
motion detection doesn't seem to switch on/off at device.
no binary sensor for button press.   callnotanswered and invite are the same messages afaik

great integration btw, my Dahua cam works a treat with it, thank you

@rroller I have a VTO2202F doorbell which have remote unlocking, can you add this as a binary sensor?

@HappySl0th sure! Can you enable debug logging and send me the event data in the logs? The event is already fired on the HA event bus so you might be able to capture it there. Once I know the event details I can add the sensor.

Also can you create a new issue to track this in.


Detekt 1.17.0-RC1 does not work

Expected Behavior
Detekt should work as is when upgrading to Detekt 1.17.0-RC1
Observed Behavior
Running detekt task failed ./gradlew detekt
Steps to Reproduce
Run the detekt with 1.17.0-RC1:
Execution failed for task ':detekt'.
> Could not resolve all files for configuration ':detekt'.
   > Could not find io.gitlab.arturbosch.detekt:detekt-cli:1.17.0.
     Searched in the following locations:
       - file:/Users/cazhang/.m2/repository/io/gitlab/arturbosch/detekt/detekt-cli/1.17.0/detekt-cli-1.17.0.pom
       - https://jcenter.bintray.com/io/gitlab/arturbosch/detekt/detekt-cli/1.17.0/detekt-cli-1.17.0.pom
     Required by:
         project :

Context
Reported by @theexiile1305 in https://github.com/detekt/detekt/pull/3455#issuecomment-830649659
Your Environment
Buildscan: https://gradle.com/s/awheke433xwa2

From https://search.maven.org/search?q=a:detekt-gradle-plugin, the downloaded jar detekt-gradle-plugin-1.17.0-RC1.jar has version.properties with detektVersion = 1.17.0.
The cause could be in buildSrc/src/main/kotlin/Versions.kt - When we publish the artifacts to mavenCentral, Versions.DETEKT = 1.17.0 instead of 1.17.0-RC1.


How to get latest w/ customizations?

I've added items to sources_no_forked (supertab). Now, when I do git pull --rebase, i get
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.

git stash
git pull --rebase
git stash apply


failed to execute goal org.codehaus.mojo:jaxws-maven-plugin1.9:wsgn

		<plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>jaxws-maven-plugin</artifactId>
			<version>1.9</version>
			<executions>
				<execution>
				 <id>wsgen-from-jdk</id>
					<goals>
						<goal>wsgen</goal>
					</goals>
				</execution>
			</executions>
			<configuration>
				<!-- service endpoint implementation class name. -->
				<sei>
					org.opensoa.repository.ws.RepositoryWebService
				</sei>
				<!-- Specify that a WSDL file should be generated in ${resourceDestDir} -->
				<genWsdl>true</genWsdl>
				<sourceDestDir>E:\Nihal\openSOAsrcnoclass\openSOAsrc\repository\core\src\main\java\org\opensoa\repository\ws</sourceDestDir>
				<verbose>true</verbose>
			</configuration>

			<!-- if you want to use a specific version of JAX-WS, you can do so like this -->
			<dependencies>

				<dependency>
					<groupId>javax.jws</groupId>
					<artifactId>jsr181-api</artifactId>
					<version>1.0-MR1</version>
				</dependency>

			</dependencies>
		</plugin>
		<!-- End JAX-WS -->

You need to provide much more info, the error output in the console for example. Also, a standalone test project would also help to reproduce.
But, I would start by upgrading to v2.4 of the plugin. v1.9 is extremely old and there will be no fix for that.

Closing. Please open a new ticket if the problems persists with version 2.4+!


Label tooltip implementation needs portal

Default implementation uses an info icon for tooltip, and the width of the tooltip is very narrow on account of this. We need to either make it a portal based tooltip by default or expose the mechanism to make it a portal based tooltip

Tracking fix with ENG-39123


King therenas dropped the stormwind Crown too

@YakaryBovine I'd like to do this.

For clarity: Terenas is meant to just drop the Crown of Lordaeron when the Capital Palace dies. This is a pretty funny bug.


Add a workflow to triage new issues and pull requests

I don't need this. The project workflows are enough for now.


Can only have one canvas per page?

Hey,
I tried making an IHaskellDisplay instance for static-canvas (see here) but found that if I had two canvases rendered using buildScript in the same HTML page, then the first one would just be modified by the commands in the second one.
This seems like a bug? Sadly static-canvas (which is awesome!) is not really useable with IHaskell until that's fixed...
Perhaps add a buildCanvasUniq function that works by storing a global counter in IO (with just an unsafe global MVar) that increments the counter every time it makes a new canvas. This is a bit ugly but works. Or allow buildScript to take a name, and offload that unsafe ugliness to IHaskell and other users :)

Thanks, I'll work on it.

Checkout the buildScript' function in 0.2. Let me know if this is what you need to make an IHaskellDisplay.
btw. thanks for the kind words on reddit and in your blob post


Enable coverage from Spring driven tests

I'd like to be able to configure the process engine with Spring and override the default behavior of bootstrapping camunda from the camunda.cfg.xml file.

Many thx @lldata for this improvement. Apologies that it took somewhat longer than it should to appreciate it publicly! 👍 (This issue closes together with #10)

The spring style of initialising a process test coverage rule seems to be problematic, because as a consequence, the coverage report on a class level is missing. I opened #16 and would appreciate any observations and/or feedback on this. Maybe I am just missing something?


Updated regular expressions, fixed a few bugs, added tests for v0.15.0

X token can now properly parse float timestamp strings
Time strings in basic and extended format are now parsed using a regular expression
"Z" is no longer stripped from the end of the string to prevent mutating the passed in datetime string. I changed it to now split on the "Z" as well as the + and -, so the parsing logic now understands that a tz is present and will parse it accordingly (rather than going on the assumption that the logic defaults to UTC and ignores the Z, it is now more explicit with a tzutc object).
Removed stripping of trailing whitespace
Added a number of tests for regular expressions and the basic format
ParserError exceptions that were thrown when the day_of_year logic encountered an error were not shown to the user because they were being prematurely caught. I fixed this by adding a new ParserMatchError that inherits from ParserError that can be caught by the internal logic and allow the ParserErrors to propagate.
ParserError now inherits from ValueError, which makes more sense then a RuntimeError.
Removed warnings and incremented version.

Note: tests seem to be passing, but we are still not at 100% coverage.

Codecov Report

Merging #639 into Version-0.15.0 will not change coverage.
The diff coverage is 100%.

@@              Coverage Diff              @@
##           Version-0.15.0   #639   +/-   ##
=============================================
  Coverage             100%   100%
=============================================
  Files                   8      8
  Lines                1511   1507    -4
  Branches              235    233    -2
=============================================
- Hits                 1511   1507    -4

Impacted Files
Coverage Δ

arrow/factory.py
100% <ø> (ø)
:arrow_up:

arrow/parser.py
100% <100%> (ø)
:arrow_up:

arrow/arrow.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ed75554...66d09f8. Read the comment docs.


Add version: LuaLS.lua-language-server version 3.2.0

Pull request has been created with Komac v1.9.1 :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/116128&drop=dogfoodAlpha

@wingetbot waivers Add Validation-Executable-Error


Training

How long does it take usually to train a voice model? I have 1 hour wav file, GTX 1660 super.

If you use a pretrained model, a few hours will be enough


Backup/Restore Access Denied in secured cluster using common names

Hi,
i have a secure cluster that uses common names to identify the server/client certificates. I now wanted to enable the BackupRestoreService by adding
    "addOnFeatures": [       "DnsService",       "BackupRestoreService"     ]
to my cluster config file.
When i now open the service fabric explorer, i get an "Access Denied" error message. It fails to get backup restore policies. Same error message pops up when i browse through my applications.
As the backup restore service worked in a dev cluster, i looked for some differences and saw that the dev cluster configuration uses thumbprints instead of common names. So i changed that and it works.
For easier rollout of certificates i would prefer using the common names though.
Thanks for listening!

Thanks for feedback and Glad to know your issue is resolved.

@athinanthny
So I just encountered this same behavior.  I'd deployed a cluster initially using thumbprint-based certificates and then switched it over to a Common Name based deployed by following the documentation.  The cluster successfully switched over to the Common Name certificate, but the BackupRestoreService was broken as a result.  Anything at all I tried to do in SFX that had to do with backups failed with Access Denied errors and, after successfully authenticating to the cluster with the Connect-SFCluster cmdlet, attempting to do anything with backup and restore cmdlets failed with authorization errors.
I re-deployed the cluster from scratch and BackupRestoreService seems to be working just fine, and the cluster was deployed using Common Name certificate.  So the cluster config still references the certificate thumbprint, but the cluster itself is using Common Name.
Please explain any known limitations or guidance in regards to switching a cluster from Thumbprint-based deployment to Common Name based deployment as it relates to the BackupRestoreService, or just any guidance at all using the BackupRestoreService on clusters using Common Name certificate deployments.  It would be helpful if there was documentation that clarifies the expected behavior and/or any known limitations.


glibc, openssl: unbreak cross eval (with minor caveats)

It's certainly better to have those two caveats than not evaluate.
Both seem rather niche.  Unfortunately I failed to find a better way.
I started testing builds of several cross variants; all seem OK.
Fixes https://github.com/NixOS/nixpkgs/issues/79610 (with minor caveats)

Tested building bash on some cross examples that came into my mind:
nix build -f . bash --arg crossSystem '(import ./lib).systems.examples.armv7l-hf-multiplatform'
nix build -f . bash --arg crossSystem '(import ./lib).systems.examples.aarch64-multiplatform'
nix build -f . bash --arg crossSystem '(import ./lib).systems.examples.musl64'

Is the separateDebugInfo completely separate?

It's separate in the sense of being put into a separate output.

I merged relatively fast to avoid additional cherry-pick after 20.03 branch-off.


In NoiseAugment, call assert for data in [0, 1] only if clip is True

Just a small fix that removes an unnecessary assert in NoiseAugment.
Calling NoiseAugment for data that is not in the range of [0, 1] should be possible.
Noise augment warps skimage.util.random_noise internally, that can handle any input range.
For clip==False there should be no assert in any case.
I have left the assert in place for when clip==True as it seems reasonable.
Note however that this creates an arbitrary restriction. Even for clip==True, skimage.util.random_noise can handle inputs outside of the range [0,1] it just clips the output after adding the noise.
Pre-Merge Checklist:

[no] if this PR adds a feature: request merge into the latest development branch (vX.Y-dev)
[no] if this PR fixes a bug: request merge into the latest patch branch (patch-X.Y.Z)
[yes] PR branch name is short and describes the feature/bug addressed in this PR
[yes] commit messages are consistent
[not yet] changes reviewed by another contributor
[yes] tests cover changes
[not tested] all tests pass

Seems reasonable to move the assert. I agree that the assert seems overkill. Maybe we could just change it to a warning or a debugging message?

Otherwise can probably go ahead and merge this

merged into the patch-1.2.3 branch


Relative paths in imported files do not work correctly

When importing a less file the less.js changes the relative paths in that file so they will still work. Example:
File structure:
main.less
    imports
        subdirectory
            import.less

main.less:
@import "imports/subdirectory/import";

import.less:
.example {
    background-image: url('../images/bg.gif');
}

Expected output:
.example {
    background-image: url('imports/subdirectory/../images/bg.gif');
}

But it becomes:
.example {
    background-image: url('imports/subdirectory/imports/subdirectory/../images/bg.gif');
}

Edit:
The behavior changed in less.js version 1.1.5, but is still wrong.
Edit2: The behavior is back to the original issue again, since the hotfix of 1.1.5. Updated the example above.

Something to do with passing paths to new less.Parser(...)...

@duncansmart, did you already see this: https://github.com/cloudhead/less.js/issues/542#issuecomment-3437549 ?

Well, actually because of a couple of reasons:

I'm quite short of time myself (last stage of thesis internship, other personal projects which are important but I don't have the time for)
I would have to get to understand the less.js code + learn git.

So yeah, I would really like helping project like less.js with pull requests, but can't right now.


sbt error

Looks like the jersey dependency version is not being resolved.
[warn] ==== Akka Snapshot Repository: tried
[warn]   http://repo.akka.io/snapshots/com/sun/jersey/jersey-client/[revision]/jersey-client-[revision].pom
[info] Resolving jline#jline;2.12.1 ...
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn] 	::          UNRESOLVED DEPENDENCIES         ::
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn] 	:: com.sun.jersey#jersey-core;[1.17,1.18): not found
[warn] 	:: com.sun.jersey#jersey-client;[1.17,1.18): not found
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn]
[warn] 	Note: Unresolved dependencies path:
[warn] 		com.sun.jersey:jersey-core:[1.17,1.18)
[warn] 		  +- pl.newicom:resttest_2.11:0.3.0-SNAPSHOT (/home/ajay/activator/workspace/ddd-leaven-akka-v2/e2e-tests/build.sbt#L10)
[warn] 		  +- pl.newicom:e2e-tests_2.11:0.1-M2
[warn] 		com.sun.jersey:jersey-client:[1.17,1.18)
[warn] 		  +- pl.newicom:resttest_2.11:0.3.0-SNAPSHOT (/home/ajay/activator/workspace/ddd-leaven-akka-v2/e2e-tests/build.sbt#L10)
[warn] 		  +- pl.newicom:e2e-tests_2.11:0.1-M2

Fixed: https://github.com/pawelkaczor/resttest/commit/e1d893e8fff420b12c8d9af7eda54cc40e025308

When I try to build it with typesafe activator, it cannot build; I get:
Read from stdout: (e2e-tests/:update) sbt.ResolveException: unresolved dependency: pl.newicom#resttest_2.11;0.3.0-SNAPSHOT: not found
(e2e-tests/:update) sbt.ResolveException: unresolved dependency: pl.newicom#resttest_2.11;0.3.0-SNAPSHOT: not found

Thanks @pistotniks for reporting the error. It is fixed now (https://github.com/pawelkaczor/ddd-leaven-akka-v2/commit/d1a7fc46e1b6a558462fb1e6f2e8b9a424d7e4b5)


Configuration within admin panel not clickable

Hey,
first of all thanks for your awesome project.
I'm running gogs Version: <IP_ADDRESS>2 Beta on an Ubuntu 14 server.
It is not possible for me to click any button within the admin panel
e.g. disable Registration, Disable Router Log,... (all of this

 DOM Elements)
I tested it on Chrome, FireFox and IE (Windows 8.1 and Windows 7).
Any idea what the problem is?
Tobias

Hmm.. thanks for your feedback.
This is not a bug, it's a unimplemented feature I should say.

I would like to help implement this. Before I do, Is this being worked on by anyone yet?


Subdomain support

Hi, cool project. Do you have plans to support subdomains? I'm working on a similar project and I am working on how to set up subdomain support. From what I have seen, I think it can be done with a middleware class on the Django side, some processing of the URL in Vue's router and editing nginx to catch the subdomains.

Hey, thank you :)
Subdomains
Yeah, your approach seems good for me.
You may also use Django Sites Framework.
Support
I don't know.
Subdomains support is not very basic functionality, so I'm not sure if it is should be in cookiecutter.
But if you want to contribute – it would be great 😄

Let's say it's out of scope


Compile Error in Xreg GraphGen using Docker

Hi all,
I cannot compile GraphGen inside Docker, due to an error: 'shared_ptr' is not a member of 'std'.
Here is the transcript of everything I did:
$ docker run -it therealcaoyudong/qtorch
root@1a60ed7013b4:/# cd root/qtorch/
root@1a60ed7013b4:~/qtorch# make all

 Compiling All Executables - Note that nlopt-2.4.2 must be installed successfully to compile.....

make[1]: Entering directory '/root/qtorch'

 Compiling qtorch .....

make[1]: Leaving directory '/root/qtorch'
make[1]: Entering directory '/root/qtorch'

 Compiling Test Executable .....
make[1]: Leaving directory '/root/qtorch'
make[1]: Entering directory '/root/qtorch'

 Compiling QAOA MaxCut - Note that nlopt-2.4.2 must be installed successfully to compile .....

cp: cannot create regular file '/root/usr/local/bin': No such file or directory
Makefile:62: recipe for target 'cut' failed
make[1]: *** [cut] Error 1
make[1]: Leaving directory '/root/qtorch'
Makefile:28: recipe for target 'all' failed
make: *** [all] Error 2
root@1a60ed7013b4:~/qtorch# mkdir -p /root/usr/local/bin    # Create directory to fix above error
root@1a60ed7013b4:~/qtorch# make all

 Compiling All Executables - Note that nlopt-2.4.2 must be installed successfully to compile.....

make[1]: Entering directory '/root/qtorch'

 Compiling qtorch .....

make[1]: Leaving directory '/root/qtorch'
make[1]: Entering directory '/root/qtorch'

 Compiling Test Executable .....
make[1]: Leaving directory '/root/qtorch'
make[1]: Entering directory '/root/qtorch'

 Compiling QAOA MaxCut - Note that nlopt-2.4.2 must be installed successfully to compile .....

make[1]: Leaving directory '/root/qtorch'
root@1a60ed7013b4:~/qtorch# cd Xreg\ GraphGen/
root@1a60ed7013b4:~/qtorch/Xreg GraphGen# make all
g++ -g -std=c++11 main.cpp -o main
In file included from main.cpp:2:0:
GraphNode.h:13:17: error: 'shared_ptr' is not a member of 'std'
     std::vector<std::shared_ptr<GraphNode>> mConnections;
                 ^
GraphNode.h:13:17: error: 'shared_ptr' is not a member of 'std'
GraphNode.h:13:33: error: template argument 1 is invalid
     std::vector<std::shared_ptr<GraphNode>> mConnections;
                                 ^
GraphNode.h:13:33: error: template argument 2 is invalid
GraphNode.h:13:42: error: expected unqualified-id before '>' token
     std::vector<std::shared_ptr<GraphNode>> mConnections;
                                          ^
main.cpp:10:23: error: 'shared_ptr' is not a member of 'std'
 bool alreadyConnected(std::shared_ptr<GraphNode> a, std::shared_ptr<GraphNode> b)
                       ^
main.cpp:10:48: error: expected primary-expression before '>' token
 bool alreadyConnected(std::shared_ptr<GraphNode> a, std::shared_ptr<GraphNode> b)
                                                ^
main.cpp:10:50: error: 'a' was not declared in this scope
 bool alreadyConnected(std::shared_ptr<GraphNode> a, std::shared_ptr<GraphNode> b)
                                                  ^
main.cpp:10:53: error: 'shared_ptr' is not a member of 'std'
 bool alreadyConnected(std::shared_ptr<GraphNode> a, std::shared_ptr<GraphNode> b)
                                                     ^
main.cpp:10:78: error: expected primary-expression before '>' token
 bool alreadyConnected(std::shared_ptr<GraphNode> a, std::shared_ptr<GraphNode> b)
                                                                              ^
main.cpp:10:80: error: 'b' was not declared in this scope
 bool alreadyConnected(std::shared_ptr<GraphNode> a, std::shared_ptr<GraphNode> b)
                                                                                ^
main.cpp:10:81: error: expression list treated as compound expression in initializer [-fpermissive]
 bool alreadyConnected(std::shared_ptr<GraphNode> a, std::shared_ptr<GraphNode> b)
                                                                                ^
main.cpp:11:1: error: expected ',' or ';' before '{' token
 {
 ^
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 1
root@1a60ed7013b4:~/qtorch/Xreg GraphGen#

Is there a quick fix for this?

Hello - unfortunately, I don't think that docker container is maintained. If you clone the git repo, go into the XregGraphGen folder, then run make all, it should compile to a binary called main, which you should be able to run with ./main <args>. I was able to do this just now


Fixed #31370 -- Added support for parallel tests with --buffer.

ticket

I've also added a commit to make the runtests.py script always use buffer mode.
Tbh I'm in favour of making buffer the default for all users. We could add an --unbuffer option to flip it off. This is the default behaviour of pytest and it can speed up tests quite a bit since writing output to screen can become a limiting factor.

Paging @bmispelon for review since you wrote the first buffer PR #12169.

Rebased. I also made a ticket to propose making buffering the default, with a --no-buffer option to disable it: https://code.djangoproject.com/ticket/31543#ticket .

@Valze you may also be interested to see or review this PR, since it's test runner related.

@Valze you may also be interested to see or review this PR, since it's test runner related.

I've been keeping an eye on it ever since you started solving it initially a month ago. I'll give it a more thorough read over this weekend and see if I can help in any way.

Code looks much cleaner after subclassing TextResult, and it really does improve a lot of other written methods.
I'm +1 on setting buffer as the default option. It removes unnecessary clutter

I'm +1 on setting buffer as the default option. It removes unnecessary clutter

Thanks. Can you repeat that on the ticket ?

@adamchainz Do you have time to check my comments and polish this patch?

I finally got back to this.

@adamchainz Thanks for updates :+1: I still believe that we should drop the last commit and keep the current (default) behavior for runtests.py, see comment.
@carltongibson Can I ask for your opinion?

I'm happy to drop the last commit if you think so, but I have not seen any pytest users complain about its automatic buffering. You can always do print() + assert 0 to see the output.

Okay I dropped the change to runtests.py

@adamchainz Also, it doesn't really work for me. I think you missed passing buffer to the RemoteTestResult. I pushed commit with a proposed fix.

I think you missed passing buffer to the RemoteTestResult. I pushed commit with a proposed fix.

Ah thanks. I think I accidentally dropped that in the rebase-and-split.

I noticed that signature are outdated, see #14145.

@adamchainz Thanks :+1: It's ready to go :star2:

🙌 🚀


Update exceptions to data residency commitments

According to the last communication with privacy team, is not needed to remove or decrease the retention period of object names from our telemetry. However, we would like to keep the warning to our customers to not place any sensitive data in these fields.

@angiesi you accidentally deleted the anchor for the next section ( -- can you restore that anchor before signing off?  thanks!

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@HeidiSteen - to get this into our review queue, please sign off when it's ready. thanks!


Rework Token type

This includes surprisingly few API changes. The main breaks come from the fact Token holds a (potentially non-static) lifetime now. I also remove several trait implementations and some methods, in favor of making the distinction between the encoded and decoded representations more explicit.

@chanced no urgency, but I think this is ready for a look when you have time.

@asmello, dude, you're awesome. This is so much cleaner than anything I would have produced.
I just realized I forgot to squash your last PR. Ah well.

I just realized I forgot to squash your last PR. Ah well.

There's always git rebase -i 😂

Ah, before I forget, one note since you mentioned you considered OnceCell — I assume that was so we could memoize the decoded value if it ever gets read. I don't think it's a bad idea, but I also think the Token type is a bit of an ephemeral type; people will typically produce it as part of iteration and either use it immediately or convert the decoded value to a String for keeping it around long-term.

It was. That logic is solid. I'm happy with out it.

The idea was to have something like`
pub struct Token(Internal);

enum Internal<'p> {
    Uncoded(Cow<&str>),
    Encoded { decoded: OnceCell<String>, encoded: Cow<&str> }
}


Ichimoku: Senkou/Leading Span Shifts

Great work on the library.
I've found I've needed to shift the Ichimoku spans to get accurate plotting with mplfinance/matplotlib
Here's my library call and senkou shifts

The resulting plot (right) as compared with TradingView:

The senkou span crossover at 8/6, 09:30, is a recognizable feature of the plot

But without the dataframe shift, the plots would be incorrect
Setting visual=True when making the library call will return the following for me:

+1

+1


Added base wrapper and wrapper like interface

linked #369

On the vueWrapper if it wasn't for the Omit 'exists' on the get method, then that could also be added to the WrapperLike interface.

I think that Omit was intentional, maybe related: https://github.com/vuejs/vue-test-utils-next/issues/176

Oh and another note: we usually have commit message convention inspired by the Angular one:

prefix by feat, fix, refactor, chore, docs
use lowercase
use imperative tense

These 2 commits could be just one with a message refactor: introduce base wrapper

Thanks for reverting the API change, left one comment + @cexbrayat and we should be good... you are on fire 👍

Ahhh one more tiny thing - all the files in this code-base are camel case - can we follow this convention?

This is conflicted. I cannot merge it and I don't know why 🤔


Makefile, Vagrantfile: use GOBIN properly as a complement to $GOROOT/bin, not a replacement.

@mapuri
This fixes $GOBIN support. $GOBIN is the target for go install -v and may differ from $GOROOT/bin which is the path to the go toolchain.
If you do this right now, you will notice that it can't find godep; this is because on my system GOBIN and GOROOT (both unified) and GOPATH (per-project) are all different.
Signed-off-by: Erik Hollensbe<EMAIL_ADDRESS>

I also added some additional makefile enhancements in the last two commits.

changes look good Erik other than few minor comments.

Removed that var. PTAL, merge if you're comfortable.

Ok, all should be good now, PTAL.

thanks Erik, LGTM
ok to merge once sanity passes.


Bump Dependencies #3243464323

Bumps dependencies for product-is. Link : https://github.com/wso2/product-is/actions/runs/3243464323

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.jenkins-is-staging seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


README

Says something about Software Carpentry - I think this is a mistake?

Indeed - just copy/pasted licence! Will fix asap.


Regarding Engineering Applications

Thank you for sharing such an excellent work. Do you consider the engineering work of this algorithm? Which chip of Horizon can well support the application of this algorithm? Looking forward to your reply.

Sparse4D was actually developed for practical engineering purposes.
We have already deployed Sparse4D on Horizon's J5 and J6 chips.
The main engineering deployment will be on the J6.

That's fantastic! To deploy applications on the J5 or J6, will there be a need for further engineering optimization of the algorithm? What is the current inference time on J5?

The algorithm itself doesn't need optimization, but we need to trim down the model size. The trimmed model can achieve real-time inference speed.

That's great！thank you for your response.


igt-gpu-tools: add the git version of the recipe

Based on meta-intel/recipes-graphics/igt-gpu-tools/igt-gpu-tools_1.23.bb
Remove the dependency of X11 in order to build with Weston.
Add a patch to add a test list path to scripts/run-tests.sh

@arthur-she @petegriffin Shouldn't we add igt-gpu-tools to the rpb-westonchromium-image now? For what machines/soc? Should it be added unconditionally or depending on something?


Unexpected token,  You may need an appropriate loader to handle this file type.

Just created an npm package, and when i use it on my project created by create-react-app
got error, any thoughts?
Module parse failed: Unexpected token (8:6)
You may need an appropriate loader to handle this file type.
|   render() {
|     return (
|

|         <Spin
|           delay={props.delay}

my npm package
class FullWidthLoading extends Component {
  render() {
   return (

      <Spin
        delay={props.delay}
        indicator={props.indicator}
        size={props.size}
        spinning={props.spinning}
        tip={props.tip}
        wrapperClassName={props.wrapperClassName}
      >
        {props.children}
      </Spin>

    )
  }
};

export default FullWidthLoading;

I've published React Native packages with JSX no problem. Guess this is just a React thing?

@threepointone  or @justinlazaro-ubidy
Please can you share file path where i can put my changes for this issue
thanks


Support Terraform 0.14

Describe the Feature
Would be nice to have this module support TF 0.14
Additional Context
Looks to me like it references https://github.com/cloudposse/terraform-null-label/ with too old versions.
According to https://github.com/cloudposse/terraform-null-label/pull/105 the dependency should work now.

Closed by #124


Issue with phone number validation?

Sorry, something went wrong when trying to figure out if you have to pay fees.
More details: Response Code: 400({‘name’: ‘plaintiffs[0].phone_number’, ‘description’: ‘Phone number’, ‘datatype’: ‘text’, ‘choices’: []})

Is this related to the note in January about mandatory regex validation?


p.SetConfig undefined (type *escpos.Escpos has no field or method SetConfig)

When I run it this way, it warns that there is no function here. Could you please check?

@simaybocu Why this issue was closed? Any idea how to solve it?


Set up gitignore

_site contents are currently being committed to repo

But you still need to remove this _site from the repo.


feat: add date fields to gql scheme for vaults

:tada: This PR is included in version 1.15.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.15.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Merge the new word library into master

The new word library is stable enough for use, and barring some breaking changes is mostly compatible with old code. All old code have been modified (slightly) to work with the new word library.

Related: https://github.com/sifive/StdLibKami/pull/43, https://github.com/sifive/ProcKami/pull/175, https://github.com/sifive/FpuKami/pull/4.


pull request for e2e test at 11/16/2016 04:26:10

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add support for batch queries

Example of it's usage:
  pub async fn insert(db, i) {
    ...
    let stmt_keys = [];
    let stmt_values = [];
    ...
    stmt_keys.push(some_prepared_statement_name);
    stmt_values.push([
      user_id, user_name, permissions,
    ]);
    ...
    db.batch_prepared(stmt_keys, stmt_values).await?
    ...
  }

To reuse the same gathered values in non-batch call do following:
  pub async fn insert(db, i) {
    ...
    db.execute_prepared(stmt_keys[0], stmt_values[0]).await?
    ...
  }

Closes: https://github.com/scylladb/latte/issues/12

It is tested here: scylla-staging/valerii/vp-longevity-gce-custom-d1-workload2-hybrid-raid#59


fix: compiler warning about different integer signedness

fix: compiler warning about different integer signedness

In this case it is better not to cast SIZE to an int, but to change i to an unsigned int, i is only ever used for indexing into a table so it can never be negative.
Casting an unsigned value to a signed one without any safety checks is a really bad idea, even if in this case there is no possible way for it to come even remotely close to the overflow boundary.


after adding packages in project, android is ok but ios crash during start

Steps to Reproduce

hi. im adding packages in my application.

Logs

  flutter:
    sdk: flutter
  http: ^0.12.0
  shared_preferences: ^0.5.2

successfully run on Android device.
then it run
flutter build ios
and successful building and installing in xcode.
but when running app in device error :

#import <Flutter/Flutter.h>

#import "AppDelegate.h"

int main(int argc, char * argv[]) {

  @autoreleasepool {

    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));  Thread 1: signal SIGABRT

  }

}

How to fixet in??

This should probably not be an issue, please collect the logs you have been given instead of just pasting the error after the source, and go over to StackOverflow

could you fix this ?

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of ' flutter doctor -v'  please.
All system setups can be slightly different so its always better to open new issues and reference related issues.


Design explorations for IBM.com cookie preferences - Intern exercise

Objective
Create additional design explorations for IBM.com cookie preferences, building upon the ongoing redesign by the Commons team. This is a learning exercise to familiarize DGC interns with the dotcom design system.
Tasks

Analyze (i.e. collect screenshots) how popular websites handle cookies
Create design explorations and share for review

Acceptance criteria

[ ] Sketch file of additional explorations (optional visual spec)

Additional Information
Design spec:
cookie_notes_from_shixie.txt
Existing designs:
component--cookies--visual-spec.sketch.zip
[Current experience on IBM.com] Screen 1 - Personalize preferences

[Current experience on IBM.com] Screen 2 - Personalize preferences (ft. advanced settings)

Feel free to join design reviews and huddles if you d like some eyes on any WIP!

Questions on the existing redesign
Playing devils advocate 😈
1. Initial banner

Why did legal request 3 buttons (accept all, proceed with required, manage settings)? Could we replace the "Proceed with required" secondary action with "Manage settings"? To visitors, the distinction between accepting all vs. required cookies is likely fuzzy.

"View and manage cookies" modal screens

Could the info fit in 1 screen? 2 screens for this seems redundant.
How appropriate is a modal? The tables to display the cookie details take up a lot of space (possible scroll issues). Perhaps a fullscreen page is appropriate for exploring the advanced details.

Great questions!

Why did legal request 3 buttons (accept all, proceed with required, manage settings)? Could we replace the "Proceed with required" secondary action with "Manage settings"? To visitors, the distinction between accepting all vs. required cookies is likely fuzzy.

IBM is trying to be ethical here. By having "Accept required" or "proceed with required", we expose the option of NOT tracking the visitor. Usually sites more concerned with selling you things will hide this button so people will just push "Accept all" and consent to being tracked, and become target for ads.

🔭 Exploration 1: two-panel modal
Considerations

Relationship between Screen 1 and Screen 2: If a user checks "Functional" and also goes to "Advanced settings", should the toggles for the functional cookies be on? What if they go back to Screen 1?
[WIP]

🔭 Exploration 2: Full-pager

[
cookies-explorations-june2020.zip
](url)
Sketch file of first two explorations and screenshots of cookie consent experiences on other sites.

🔭 Exploration 3: Single-panel modal


bugfix: prevent segfault if pwhash_str_verify is passed nil

this prevents an unpleasant ruby segfault if you happen to pass nil as the digest to PasswordHash.argon2_valid?(password, digest)

@elijh will give this a few more days then cut 4.0.0


Batch script : Invalid FROM vertex for edge

OrientDB Version: 3.0.x
Steps to reproduce

Create a new database
Execute this batch script from Studio

begin;
let $v1 = create vertex v set name = 'Foo';
let $v2 = create vertex v set name = 'Foo';
create edge from $v1 to $v2;
let $v3 = create vertex v set name = 'Foo';
create edge from $v1 to $v3;
commit;

Checking now

Fixed on develop branch
Closing, thanks
Luigi


OBJ Material File?

There's no .mtl file to go along with the .obj file? Need it for the colors.

I've got a fork where I've converted the maya file to a obj file and added a accompanying mtl file.
https://github.com/chran554/go-gopher-model