chore:re adding role creation

PR: Implement Endpoint for Creating Roles (OS-001)
This PR implements an endpoint for creating roles within an organization, addressing the requirements specified in OS-001.
Changes

Created a new RoleController with a CreateRole method
Implemented the POST /api/v1/roles endpoint
Updated database schema to support role creation
Added input validation and error handling
Implemented authentication and authorization checks

New Endpoint
POST /api/v1/roles
Request Body
json
{
"role_name": "String",
"organization_id": "String",
"permission_ids": ["String", "String", ...]
}
Success Response (201 Created)
json
{
"message": "Role created successfully",
"status_code": 201
}
Error Response (400 Bad Request, 401 Unauthorized, 403 Forbidden, 500 Internal Server Error)
json
{
"error": "Error message",
"status_code": 400
}
Implementation Details

Used GORM for database operations
Implemented transaction to ensure atomicity of role creation and permission assignment
Added middleware for authentication and authorization
Used UUID for generating unique role IDs

Testing

Added unit tests for the CreateRole method
Implemented integration tests for the role creation process
Tested various scenarios including successful creation, invalid input, and error conditions

Security Measures

Ensured only authenticated admins and super admins can access the endpoint
Implemented input validation to prevent injection attacks
Used HTTPS for secure data transmission (to be configured in deployment)

To-Do Before Merging

[ ] Review and update API documentation
[ ] Perform thorough testing in staging environment
[ ] Update relevant parts of the codebase to use the new role structure

How to Test

Ensure you have admin or super admin privileges
Send a POST request to /api/v1/roles with the required payload
Verify the response and check the database for the newly created role

Please review and do not let me know if any changes or additional information is needed.

These are not my tests failing


Move create_physical_expr to phy-expr-common #3

Which issue does this PR close?

Closes #10176
Closes #10074
Closes #10144
All in one in this PR.
Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Hi @jayzhan211  -- if we merge this one, does it close https://github.com/apache/datafusion/pull/10176  and https://github.com/apache/datafusion/pull/10144 ?

Hi @jayzhan211 -- if we merge this one, does it close #10176 and #10144 ?

Yes!

Sorry for being dense -- would you like me to review this PR? Or do you think we should review  (and merge) https://github.com/apache/datafusion/pull/10176 and https://github.com/apache/datafusion/pull/10144 first?

It depends on you and other reviewers, if this PR is too large, we can close #1 first, and move on to #2 and finally this one.

Here is another suggestion: https://github.com/apache/datafusion/issues/10074#issuecomment-2077439515

Once we have created a Arc I don't really understand how/why we would ever get an Expr that we need to convert back to Arc again.

I think we don't have any need to convert physical expr back to expr. But, we need to convert expr to physical-expr, because accumulator and reverse_expr are the functions that need ordering_req: Vec<PhysicalSortExpr>.

If we can move reverse_expr related logic all to logical layer.... 🤔


Closes #260 docker image

Closes #260

@gvych Thanks for taking the time to create this PR.
From the code changes, I can see that a Docker image is built and pushed to the Github container registry (ghcr.io)
Going to ask some questions, since I'm not familiar with the Github container registry:

Am I correct to observe that every new release, will result in a new container build and publish?
Are there storage costs attached to the Github container registry or is this free for OSS projects?
In the Github action, it mentions these 2 credentials, do we need to add anything, or do these get filled in automatically?

username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}

@thim81

Yes, each new release will rebuild and push <docker_image>:latest version. Only latest version will always be available. I'm ready to reconsider that.
No costs: "GitHub Packages is free for public repositories"
If I'm not confusing anything, this variables are get filled automatically. At least in my clone of repository this worked right away.

Thanks again @gvych for the contribution.


Fix : UI: Unnecessary scrollbar appears when cursor moved on to state…

… info icon #2179
Description of PR
Fixes the UI scroll issue when states at the bottom of the table have a tooltip, which pushes the content and hence the scrollbar.
changes brought

For states in the upper half of the table, the design is the same as that of the current site.
For states in the lower half, the popup base will be aligned to the top of the tooltip hence it won't push the content downwards

Relevant Issues
Fixes #2179
Checklist

[x] Compiles and passes lint tests
[x] Properly formatted
[x] Tested on desktop
[x] Tested on phone

Screenshots

Add relevant screenshots here

@shuklaayush

Fixed via #2493


Enable VM provisioning on e2e cluster wide test

@sebastienvas: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
6335e86bd433058b8e5f9b6d51a83fa22cc0b407
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
6335e86bd433058b8e5f9b6d51a83fa22cc0b407
link
/test e2e-bookInfo

prow/e2e-simpleTests.sh
6335e86bd433058b8e5f9b6d51a83fa22cc0b407
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-cluster_wide-auth

@sebastienvas: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-cluster_wide-auth.sh
666e4e5684579ede810fc84f198bd6b6e83bb4b4
link
/test e2e-cluster_wide-auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-cluster_wide-auth.sh
666e4e5684579ede810fc84f198bd6b6e83bb4b4
link
/test e2e-cluster_wide-auth

prow/istio-pilot-e2e.sh
666e4e5684579ede810fc84f198bd6b6e83bb4b4
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-cluster_wide-auth.sh
666e4e5684579ede810fc84f198bd6b6e83bb4b4
link
/test e2e-cluster_wide-auth

prow/istio-pilot-e2e.sh
d2985d9a450e3a23dcedb715e8c85bde3c1b292c
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-cluster_wide-auth

/test e2e-cluster_wide-auth

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
d2985d9a450e3a23dcedb715e8c85bde3c1b292c
link
/test istio-pilot-e2e

prow/e2e-cluster_wide-auth.sh
ff55751b649e98ee2ebbb456cc563904e7f5fb90
link
/test e2e-cluster_wide-auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

something off with this pr / prow ? 1h for presubmit ? also the link are not responsive or super slow

@ldemailly I don't see it. I keep rebasing so it triggers the presubmit again.

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-cluster_wide-auth.sh
ff55751b649e98ee2ebbb456cc563904e7f5fb90
link
/test e2e-cluster_wide-auth

prow/istio-pilot-e2e.sh
ff55751b649e98ee2ebbb456cc563904e7f5fb90
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-cluster_wide-auth

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-cluster_wide-auth.sh
ff55751b649e98ee2ebbb456cc563904e7f5fb90
link
/test e2e-cluster_wide-auth

prow/istio-pilot-e2e.sh
ff55751b649e98ee2ebbb456cc563904e7f5fb90
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
c838c15a7d797eddc8e90fafd515b09de7d4f6c7
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
ff55751b649e98ee2ebbb456cc563904e7f5fb90
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
c838c15a7d797eddc8e90fafd515b09de7d4f6c7
link
/test e2e-simple

prow/e2e-cluster_wide-auth.sh
c838c15a7d797eddc8e90fafd515b09de7d4f6c7
link
/test e2e-cluster_wide-auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-cluster_wide-auth

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c838c15a7d797eddc8e90fafd515b09de7d4f6c7
link
/test e2e-simple

prow/istio-pilot-e2e.sh
c838c15a7d797eddc8e90fafd515b09de7d4f6c7
link
/test istio-pilot-e2e

prow/e2e-cluster_wide-auth.sh
c838c15a7d797eddc8e90fafd515b09de7d4f6c7
link
/test e2e-cluster_wide-auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/test e2e-cluster_wide-auth

@sebastienvas: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-cluster_wide-auth.sh
c838c15a7d797eddc8e90fafd515b09de7d4f6c7
link
/test e2e-cluster_wide-auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-cluster_wide-auth

/test e2e-cluster_wide-auth

/test e2e-cluster_wide-auth

/test e2e-cluster_wide-auth

/test e2e-cluster_wide-auth

@sebastienvas: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
2cb70a30fcb765b416350cce1c5b84b182db6909
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

did we run out of quota again ?
I0222 19:15:27.593] 2018-02-22T19:15:27.592639Z	error	Failed to complete Init. Error unable to find ingress ip, state:
I0222 19:15:27.605] svc/istio-ingress   LoadBalancer   <IP_ADDRESS>         80:32202/TCP,443:31827/TCP                                         6m        istio=ingress

/test e2e-cluster_wide-auth

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
2cb70a30fcb765b416350cce1c5b84b182db6909
link
/test e2e-bookInfo

prow/e2e-simpleTests.sh
17e3586d9daff9e16a15592c675a7615ff442026
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sebastienvas: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
17e3586d9daff9e16a15592c675a7615ff442026
link
/test e2e-simple

prow/istio-pilot-e2e.sh
17e3586d9daff9e16a15592c675a7615ff442026
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@chxchx Finally working correclty. Please review.

/test e2e-simple

/test istio-pilot-e2e

@sebastienvas: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
a35081df62b50d5de2e8ae629a6a60e1c7dfe85a
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-bookInfo

/approve


yapf 0.27 breaks lint

Issue Type

Bug report

Detail any linters or test runners used:
tox -e lint -e format-check
Desired Behavior
When using the latest yapf (currently 0.27), both the lint and format-check testenvs will succeed.
Actual Behaviour
When using the latest yapf on the current master, lint will succeed, but format-check will fail. If yapf if run with -i to modify files in-place (via tox -e format), format-check will succeed, but lint will fail.
This issue is being created as a central place to discuss how to proceed.

PR #1911 demonstrates the lint failures after the yapf's changes are applied.

/me still doesn't like autoformatters

I also don't like autoformatters. I think flake8 gets to have the final say on linting, and any personal style preferences can be hashed out in reviews.
This particular "yapf-ism" is probably my favorite, though I admit that I'm cherry-picking here:
https://github.com/ansible/molecule/blob/50688a810a77feaea4925d04e6d810b928adc39a/molecule/config.py#L404-L405

Ah, woops. I forgot to ref #1915, which pins yapf to 0.26 so CI has a better shot of working while this discussion happens.

any personal style preferences can be hashed out in reviews.

This is exactly the thing I like to avoid. And not even for myself but for contributors that might get exposed to some cranky "don't do it like this" comment and then think that this is not a welcoming place. There are big possibilities for that to happen ... overall, I think we need these tools because they are part of a equalising process for both new and old participants in this project. As as aside, I did like Knuth's comment (from the back of my head, no link right now ...) that we shouldn't restrict people based on what they find satisfying style ... but again, an overriding concern is contributor experience ...
Personally, I use black on all my projects (following projects like pytest and tox!) and it has been "set it and forget it" ... but I won't advocate for switching tools just yet. Especially since it is beta and experimental right now.
Let's just fix yapf for now ... I might take a stab at it ...

I use black

Oh, I can't even decide which one I dislike more :) I think black, because I have read its source code. They are probably fine for newbies but is poisonous for experienced folks.
The problem is that if I write code which is compliant with PEP 8 tools shouldn't break it but they do.
It's okay to format some parts which are not compliant, though, I'd be satisfied if they didn't touch well-written chunks and didn't break those. That's why I'm having "no-black" policy on my projects.
The other thing is that linter errors hint code author about possible places for improvement where the best way to solve them would be not blindly reformatting the chunk but redesigning it. This would save more resources of maintainers who still need to point out such places for refactoring but without any help from linters now...

They are probably fine for newbies but is poisonous for experienced folks.
That's why I'm having "no-black" policy on my projects.

I think you should re-evaluate your position if you're trying to make community projects more accessible.

you're trying to make community projects more accessible.

Nope, my goal is to keep them maintainable.

I don't have much to add beyond my initial experience as a relative newcomer to molecule. yapf itself resulted in a less-welcoming experience for me, as I initially did my work to flake8's satisfaction only to find that yapf disagreed with some of my style choices, and I in turn disagreed with yapf's choices. The experience was admittedly trivially annoying, but it was annoying nonetheless.
While taking the style friction out of PRs is laudable, it never really goes away. Using yapf moves the friction into a contributor's workspace, making it slightly more difficult to begin reasoned discussions about the merits of different approaches or the rationale behind specific style choices. Sometimes those discussions are frustrating, but more often (in my experience, at least) those discussions are rewarding and help me to become a more thoughtful developer.

yapf itself resulted in a less-welcoming experience for me, as I initially did my work to flake8's satisfaction only to find that yapf disagreed with some of my style choices, and I in turn disagreed with yapf's choices. The experience was admittedly trivially annoying

Yes, I think this is what I was trying to say... There's two sides of contributor experience (pros vs. newbies). And what makes one side happy just kills any joy and is frustrating others.

those discussions are rewarding and help me to become a more thoughtful developer.

Yeah, I like that too!

Some notes about this from today's working group meeting:
As I mentioned before, I'm only trivially frustrated with yapf. I don't deeply care how code ends up looking as long as it's still readable. With yapf currently pinned at 0.26, the lint and format-check testenvs get along with each other and work well together, so there's no urgency to make a decision now that CI is green again. It's possible that yapf will get updated in the meantime and resolve the flake8 incompatibility issue while this discussion continues.

Interesting data point on the code formatting debate: https://github.com/django/deps/pull/55/files

I read that. Nothing new for me. I still hate when the computer tells me that my 100% compliant code should look not as I want it too (I wouldn't write it that way if I thought otherwise). That document just declares the subset of arguments the author doesn't like unimportant which is a very personal assessment.

:running_man: :bomb:


Handle Password Protected PDFs

Password protected PDF files should be treated with something like QPDF (to get rid of the password requirement) before letting it go through the extractor.

I think we're handling this now.

I think we're handling this now.

Correct. Thanks!


Add escape to "_" in no_grad_guard documentation

The underscore was not being rendered in the rustdoc documentation due to markdown semantics.

Closing this one as the doc got rewritten and now seems to render properly docs.rs.


DONT MERGE!!!

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-js

Automation for azure-sdk-for-java

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-go

Hi, @daschult. The PR has be closed for a long time and it's related branch still exist. If no further used for over 14 days, I will delete this related branch. Please tell me if you still need this branch.

Hi, @daschult. The PR has be closed for a long time and it's related branch still exist. Please tell me if you still need this branch or i will delete it in 14 days.

Hi, @daschult. The PR has be closed for a long time and it's related branch still exist. Please tell me if you still need this branch or i will delete it in 14 days.

Hi, @daschult. The PR has be closed for a long time and it's related branch still exist. Please tell me if you still need this branch or i will delete it in 14 days.


Multiple projects - file resolution caching is shared though seperate resolvers can be specified

🐛 Bug Report
When using projects, the resolver caches between those projects even if different resolver's are specified.
To Reproduce
Steps to reproduce the behavior:

have 2 projects
have the resolvers in each project resolve to different files e.g. test.a.js and test.b.js
have a test file in each project that requires the same file e.g. 'test.js' which you want resolved to .a and .b
run the projects together - the first resolution gets cached
run the projects seperately - each project gets a different resolution

Expected behavior
I would expect that since projects can specify resolvers per project, that jest would not cache between them
I will try working on a PR since this is a feature I need.
In our codebase we compile multiple variants of our app and we use a string in the import statements to differentiate between the apps. I want to make it so that spec.a.js and spec.b.js resolve with preference to .a. and .b. respectively.. and apart from this hurdle it seems to work..

Duplicate of #5741

no problem. Now I've started to try and fix it I am not convinced jest is wrong any more!

Cool, thanks for following up!

From what I can tell, it seems like when runInBand is off, jest can confuse resolvers between projects.. ? But I'm pretty convinced its a jest problem, its just intermittant.

resolvers are cached by config.name here: https://github.com/facebook/jest/blob/master/packages/jest-runner/src/test_worker.js#L61
but config.name doesn't change for different projects...

setting name on the project is a work-around - it overrides the GUID it gets from somewhere so it cache breaks correctly.
It should calculate the "name" guid based on each project, not one for all projects. If I work out where in jest it does this I will make a PR

We have a WIP PR on something similar already, but we didn't settle on implementation yet. Feel free to check out and find some inspiration: https://github.com/facebook/jest/pull/5862


fix: deleted report preview link in thread is incorrect

Details

Not here page displayed for deleted IOU link copied from 2nd level thread because it used the wrong reportID. This PR retrieves the originalReportID instead.
Fixed Issues

$ https://github.com/Expensify/App/issues/41091
PROPOSAL: https://github.com/Expensify/App/issues/41091#issuecomment-2079701685
Tests

Submit an expense to an user
Send a message in transaction report
Reply that message in thread
Delete the expense
Right press the report preview >> Copy link
Navigate to that link
Verify app navigates to the DM report in step 1 and highlight the corresponding report preview

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

Offline tests

NA
QA Steps

Submit an expense to an user
Send a message in transaction report
Reply that message in thread
Delete the expense
Right press the report preview >> Copy link
Navigate to that link
Verify app navigates to the DM report in step 1 and highlight the corresponding report preview

[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).

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

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb 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 either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[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 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(theme.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 the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[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.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/153004152/9c62ed57-fb66-425c-a372-b9a8637d32ec

Android: mWeb Chrome

https://github.com/Expensify/App/assets/153004152/60ccdf16-d69c-4d4b-9677-f4a4f33f3c5f

iOS: Native

https://github.com/Expensify/App/assets/153004152/e8cde880-27c9-4f9c-b325-e193905e7e0a

iOS: mWeb Safari

https://github.com/Expensify/App/assets/153004152/c96bdd4c-56aa-4d50-854a-cb1694db3caa

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/153004152/afabf684-d439-40c6-b878-88d49f7514fc

MacOS: Desktop

https://github.com/Expensify/App/assets/153004152/b7ce66d1-9362-4db5-aab8-f6fd462b10de

@gijoe0295 I got this bug while recording the video for mSafari? Can you reproduce it?
https://github.com/Expensify/App/assets/16502320/2dce67a5-725e-4891-8c2d-e4387447c995

mWeb safari is so broken for me, I'll try again in a while.

Ok, I can confirm it's not related to this PR.

Reviewer Checklist

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

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] 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)
[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 checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

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

[x] 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
[x] I verified proper code patterns were followed (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] 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 either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[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 verified that this PR follows the guidelines as stated in the Review Guidelines
[x] 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)
[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] 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] 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)
[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(theme.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 the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[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.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/16502320/a214c6b2-8c70-4e2c-b5c7-3f2be56ed3b4

Android: mWeb Chrome

iOS: Native
https://github.com/Expensify/App/assets/16502320/7e934e94-8268-4a90-91cb-7c78d7cff278

iOS: mWeb Safari

https://github.com/Expensify/App/assets/16502320/6158572f-85cd-49ce-bb70-6e69a75457ac

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/16502320/edf971d1-6fe0-4d3b-9ead-8ca765cd2724

MacOS: Desktop

https://github.com/Expensify/App/assets/16502320/ccf0d9f7-115c-4cac-94b8-eaedc5ef8f86

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/techievivek in version: 1.4.72-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.4.72-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Summary of UG Problems from PE-D

Issue #310:
Messy formatting of quick start

Issue #302:
In help, swap format and description. more intuitive

Issue #290
Unexpected divider in between table of contents. I tried to print UG again and there is no divider. Unsure what caused this.

Issue #274
UG does not have find by tag feature

Tester D UG issues:
Cosmetic

#303
#301
#295
#255

Others

#298

This is marked as feature flaw. I think we just need to make it clear that we do not consider a prof to be a TA

#289

This is marked as documentation bug. The issue raised is that + is used as both a actual character in the user command, and also to denote 1 or more (in regex sense), so it could be confusing

Issue #253
Typo of "square" in UG

Issue #250
Slightly discrepancy in screenshots in UG

Issue #248
Mentioning of AB3 in the UG

Issue #264
To prevent such issues, mention that undo and redo are not persistent across sessions by design.

issue #296

Issus #252
We can mention emails without a dot is allowed.

#261
#286

Summarising @MAOXIONGKAI 's issues:

#274
UG does not have find by tag feature
#253
Typo of "square" in UG
#250
Slightly discrepancy in screenshots in UG
#248
Mentioning of AB3 in the UG


Add IPlugin3 with RegisterPlugin

This PR adds IPlugin3 witch gives plugins the possibility to register plugins themselves.
This functionality can be used to create runtime-plugins for different languages.
I created an experimantal .NET 5 runtime plugin based on it.
Since you mentioned in your Blog Post you plan to extend the plugin api anyway, i thought it would be a great opportunity to propose this addition as well.
The major changes

Addition of the type IPlugin3
Move a lot of the plugin initialisation from PluginManager::Init to the new method PluginManager::RegisterPlugin and wrap it for IPlugin3::RegisterPlugin
Call the IPlugin3::PluginManager_RegisterPlugins method of a plugin after it's initialisation
Destroy plugins in reverse order

Hey! Thank you so much for the PR, I've tested and merged it.
This is pretty exciting stuff as it opens doors to new possibilities. Sometimes it's way easier to build stuff in C#.
The experimental .NET 5 runtime plugin looks nice!


Issue while working on multiple endpoint in camel-k.

Hi Team,
I have been facing an issue with endpoints as shown below.

in this i'm trying to fetch data from multiple data sources(abc & def) and I have created a secret from application.property file, this property contains endpoint details for both abc and def as i shown below.

I ran the code by using the command as shown here, it was working fine when I ran individual routes, but it is failing when i run as a whole(two route).
kamel run Test.java --dev --build-property quarkus.datasource**.abc**.db-kind=oracle -p  quarkus.datasource.def.db-kind=mssql --config secret:abcdef-datasource -d mvn:io.quarkus:quarkus-jdbc-oracle:2.16.0.Final -d mvn:io.quarkus:quarkus-jdbc-mssql:3.1.1.Final
and the error i'm getting like
"ERROR [org.apa.cam.qua.mai.CamelMainRuntime] (main) Failed to start application: org.apache.camel.FailedToCreateRouteException: Failed to create route route1 at: >>> To[jdbc:def] <<< in route: Route(route1)[From[timer://sql-insert?period=30000] -> [SetB... because of Failed to resolve endpoint: jdbc://gdw due to: No bean could be found in the registry for: gdw of type: javax.sql.DataSource"
Please help me to resolve.

I see something strange. Your exception complains about jdbc://gdw which does not really exist. Also, I wonder if both Quarkus SQL extensions can coexist without problems.

sorry. jdbc://gdw I renamed as jdbc://def

Okey, it seems you're not providing both as build-property. I think you need to run --build-property quarkus.datasource.abc.db-kind=oracle --build-property quarkus.datasource.def.db-kind=mssql as both properties are required at build time for Quarkus build.

Thank you @squakez , the java code started working properly after adding "--build-property" for both data sources, Now I am able to fetch data from both tables from different data sources. 👍 :)


Finish BookMark feature

What I did?

make api endpoint for GET and POST bookmark
Write the BookMarkQuery for query
Write the BookMarkPost to post new data
Write tests for both GET and POST
Change date field to DateTime field for both Review and Note

Oh no tests don't pass because I just add new field : (


Pick only params from route before passing them to screen

Details

The bug was caused by screen in FullScreenNavigator being unmounted and mounted when RHP modal was opened. It happened because in some cases RHP route accepted more params then route in FullScreenNavigator. When RHP was opened those additional params where pushed back to FullScreenNavigator which caused it to re-render.
Fixed Issues

$ https://github.com/Expensify/App/issues/44192
PROPOSAL: N/A
Tests

Go to Settings > Workspace > Members
Click on member row
Verify that members list doesn't blink

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

Offline tests

Same as in Tests
QA Steps

Same as in Tests

[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).

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

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb 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 either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[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 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(theme.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 the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[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.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/56261019/6d48fb2f-2228-47fd-8954-f4628f79063f

Android: mWeb Chrome

https://github.com/Expensify/App/assets/56261019/a6ecd38b-b981-4c4e-b4bc-d7c79c29c5c7

iOS: Native

https://github.com/Expensify/App/assets/56261019/b4e0bb73-7e9a-480f-a61b-22e29fadd3c1

iOS: mWeb Safari

https://github.com/Expensify/App/assets/56261019/639f6d8f-5b10-4a2e-aaa8-0d91f27b2557

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/56261019/95a435a8-23f4-4452-9250-1ccbabdf157f

MacOS: Desktop

https://github.com/Expensify/App/assets/56261019/da7b3cb2-e1d2-413d-b21d-2b18033ec117

LGTM! 🎸

@mountiny it's ready for review 🎉

Automation seems to have failed in requesting a review from me; I am starting to review the PR.

@jnowakow Workspace Name page is still blinks for me.
https://github.com/Expensify/App/assets/35371050/a26eeb06-d8b6-40a3-81b2-444fa2832329

Workspace Name page is still blinks for me.

Hey @jnowakow If the issue is not happening for you, then we can test it on adhoc builds, as the issue is happening for me every time.

@jayeshmangwani can we trigger adhoc builds? It works fine for me:
https://github.com/Expensify/App/assets/56261019/555b84b8-3791-4f61-bd9a-80f38d85f8da

@mountiny can we please run adhoc builds here?

Although it is not reproducing for you, let me add a video of all the steps with console logs of ProfilePage re-rendering. This might help in reproducing the issue.
https://github.com/Expensify/App/assets/35371050/8ae5232a-e3a3-46ec-9787-b08db6dbdeab

On adhoc too, I am still seeing a blink on the Workspace Name page.
https://github.com/Expensify/App/assets/35371050/65bdf3a7-ba40-4b33-ba65-f1c28a2dbb23

I tested it on another device as well, and I can easily see the blink the first time I go to the Workspace profile -> Name.

@jayeshmangwani I'm able to reproduce 🤔 I'll take a look at this

@jnowakow have you had a chance to fix this?

@mountiny I'm working on it

@mountiny @jayeshmangwani I've found the root cause. The problem is in getTopmostFullScreenRoute returning bad route either because it badly calculates the route because params doesn't match state or by params being object of correct shape but with all values being undefined.
Tomorrow I'll consult the problem with @adamgrzybowski and hopefully he will help me find out the best solution

@jayeshmangwani what is your ETA for the checklist please?

@mountiny will start review this PR in an hour

@jnowakow @adamgrzybowski This issue is resolved for me on the web, I can confirm that. However, I am now encountering a different issue on iOS. The Workspaces page blinks when we go to any workspace and navigate back to the Workspaces page from the workspace.
https://github.com/Expensify/App/assets/35371050/cad306cb-e035-4dc3-8cb6-56cf7e342e8c

@jnowakow Please let me know if it does not reproduce for you

@jayeshmangwani I'm able to reproduce both on main and on my branch. I'll try to debug it today, however tomorrow is my last day at work before longer break so if I don't manage to fix it today what about merging this PR and opening another issue for this particular one?
cc @mountiny

if I don't manage to fix it today what about merging this PR and opening another issue for this particular one?

@mountiny what's your suggestion on this? If Jan doesn't manage to fix the issue for iOS by the end of today, should we merge this PR that fixes the issue for web and open another issue for iOS?

Ok, I found the place that is breaking. It's fault of withPrepareCentralPaneScreen. Simply removing it for WorkspacesListPage fixes the issue but I'll try to figure it out why exactly it causes the screen to remount as it may also happen in other places too.

Ok, I found the place that is breaking

Thanks for the update! 🎉

@jayeshmangwani I just removed withPrepareCentralPaneScreen for this screen and issue seems to be fixed. I haven't found the solution to fix it with this function, maybe @WojtekBoman will know but I think it's good as it is now.
If there will be any other problems with this PR someone from SWM will take over on Monday. cc @staszekscp

Maybe this will help with the reload https://github.com/Expensify/App/pull/45335

Maybe this will help with the rerender issue #45335

Yes, this PR will solve the re-render issue. I have added the changes and tested them locally.
@jnowakow  Please add back the withPrepareCentralPaneScreen to the WorkspacesListPage.

@mountiny, you're right - it seems to fix the issue

I'm reverting last commit then

Reviewer Checklist

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

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] 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)
[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 checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

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

[x] 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
[x] I verified proper code patterns were followed (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 />.
[ ] 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.
[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] 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 either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[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 verified that this PR follows the guidelines as stated in the Review Guidelines
[x] 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)
[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] 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] 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)
[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

[ ] 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

[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(theme.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.
[ ] 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 the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[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 reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/user-attachments/assets/cc00d33c-ad5e-4e09-a32b-ee535b41d640

Android: mWeb Chrome
https://github.com/user-attachments/assets/f31b4a79-460d-4ed4-b085-6066dcc8f996

iOS: Native
https://github.com/user-attachments/assets/ea8b4baa-d1d8-49f4-83fd-c3f612f9f671

iOS: mWeb Safari
https://github.com/user-attachments/assets/b3badffc-0339-4992-affd-591c53c19162

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/5c7836d8-0312-4928-ad7a-6c6dd3bb5ed0

MacOS: Desktop
https://github.com/user-attachments/assets/4bdee278-7f34-42b8-8550-b7ddd30f7d33

Not sure why tests are failing here. They are working fine for me locally. Maybe we need to merge the main branch and push the code here, as Jan is on break from work. @staszekscp  Please help merge the main branch here.

I will take a look at this later today, I also work with SWM and with @staszekscp

hey @jayeshmangwani I merged newest main and all the checks are passing 🚀

Merged newest main, solved conflicts, tested the flow on web only and I see no screen blinking as expected.

@mountiny All yours. Would you take a look at the PR?

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/mountiny in version: 9.0.10-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Cherry-picked to staging by https://github.com/mountiny in version: 9.0.10-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by https://github.com/mountiny in version: 9.0.10-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/francoisl in version: 9.0.11-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


No results from intelx

Hey there, I hope all is good.
While we already discussed this, I will create an issue for it to keep things on track.
The tool does indeed issue a request to intelx /phonebook/search path, however, it doesn't return any results in return.

Reviewed, was an issue with the IntelX API at the time


Should be "KEKs"

https://github.com/commoncriteria/fileencryption/blob/4dde142afe4327a157a32f8e454f7de703a95add/input/fileencryption.xml#L878
It seems odd to say "key encrypting keys" and then KEKs immediately in the same sentence. Given that KEK is a defined acronym it should be used here.

Changed references to KEKs.


The background color (green and blue) is not appearing on the conflicted code

The merge conflict is not working properly i assume. Check the attached image

Ah, this is related to #99: merge-conflicts doesn't work with the shadow DOM, yet. I'm having a look presently. In the meantime, I'll close this as a duplicate :point_right:


Return error when trying to use prediction resistance

I do remember that discussion, but the link doesn't seem to work and I can't find it #4402.
It might be that some of the entropy sources do qualify as a NRGB, but in my opinion none of default sources, like a parent DRBG, /dev/urandom, getentropy() qualify in my understanding. Something like RDSEED might qualify, while RDRAND not.
Anyway, since we don't seem to agree on this, maybe we should ask others? Maybe people from NIST?

I've moved to check to just before we get the system entropy.

I do remember that discussion, but the link doesn't seem to work and I can't find it #4402.

The link did not work on Chrome (but it worked with Internet Explorer) because it's inside a review for an outdated commit.  You'll see it if you press 'Show outdated' on your second review from  22 Oct 2017.

Both the current and previous patch actually allow you to use prediction resistance, just not with the default methods to get entropy.

The use of the prediction resistance parameter is that you can say: „reseed immediately,  before generating the random output, because I need extra security!“ And your proposal is that the random generator should cowardly fail because it is afraid that its entropy source is not good enough. That does not make sense to me.

I'm not seeing the point of this either.

The DRBG is the determinstic part of a hybrid random generator and as such, the quality of its output depends on the quality of its random source. But it is not the task of the building block to decide whether the random source is good enough or not. The choice of the proper entropy source could be mandated by a future FIPS certification. But for now, it is consensus that the os random generator is not that bad after all. And requesting prediction resistance should be possible regardless of the choice of random source. So we should leave this question for a future FIPS evaluation.

So my understanding is that you're saying the kernel generated data is (currently) good enough. But that seems to mean to me that we need to either call the parent with the prediction_resistance parameter, or ask the kernel ourselves. So should I just remove that if that returns an error?

Sorry Kurt, I did not have much time this weekend to answer your question. You will receive an answer by tomorrow or the day after.

@mspncp: Ping

First of all, I would like to repost a minimally redacted version of my post from 22 Oct 2017, since the original is not easily available due to a bug in the GitHub webinterface (the link only works with IE, not with Chrome).
mspncp on 25 Oct 2017
Currently the prediction_resistance request is not propagated to the parent. So a generate request to the private DRBG with prediction_resistance=1 only reseeds the private DRBG, not the master DRBG.
It is my understanding that the NIST standard does not mandate the prediction request to be propagated to the parent DRBG: The NIST standard only considers a single DRBG. An adversary might have gained knowledge about its internal state, but not about its parent, which is considered a black box. Here are some citations from NIST SP 800-90Ar1:
Definition of Prediction Resistance (page 6)

An RBG provides prediction resistance relative to time T if it provides assurance that an adversary with knowledge of the state of the RBG at some time(s) prior to T (but incapable of performing work that matches the claimed security strength of the RBG) would be unable to distinguish between observations of ideal random bitstrings and (previously unseen) bitstrings output by the RBG at or subsequent to time T. In particular, an RBG whose design allows the adversary to step forward from the initially compromised RBG state(s) to obtain knowledge of subsequent RBG states and the corresponding outputs (including the RBG state and output at time T) would not provide prediction resistance relative to time T.

On page 25, it says

The prediction_resistance_request parameter indicates whether or not prediction resistance is to be provided during the request (i.e., whether fresh entropy is required[4]).

Chaining of DRBGs is justified by footnote[4] of page 25:

[4] 4 Entropy input may be obtained from an entropy source or an NRBG, both of which provide fresh entropy. Entropy input could also be obtained from a DRBG that has access to an entropy source or NRBG. The request for prediction resistance rules out the use of a DRBG that does not have access to either an entropy source or NRBG.

and in further detail by footnote [5], page 30:

A DRBG may be reseeded by an entropy source or an NRBG, both of which provide fresh entropy. A DRBG could also be reseeded by a DRBG that has access to an entropy source or NRBG. The request for prediction resistance during reseeding rules out the use of a DRBG that does not have access to either an entropy source or NRBG. See [SP 800-90C] for further discussion.

In our case one might argue differently, because the master DRBG resides in the same address space as public and private DRBG. An adversary that gains knowledge about the private DRBG could indeed also have knowledge about its parent. I tried to mitigate this possility by lowering the reseed intervals to keep the total "os reseed interval" at 2^24. But I would understand if someone insisted on forwarding the prediction_resistance request to the parent. In this case one would indeed get the Domino effect you mentioned. It's the usual security vs. performance tradeoff. As such, it's a political question and should probably be decided the OMC members. I am a little in favor of my choice, but would also follow a majority vote.
kroeckx on 22 Oct 2017
I have no idea how you can interpret that text differently. There needs to be a way to get fresh entropy from somewhere. A DRBG does not provide fresh entropy, you need something that directly talks to the entropy source to get such fresh entropy and that's the master DRBG.
mspncp on 25 Oct 2017
I disagree, and it is not a matter of interpretation, it is written down in the standard:

Requesting prediction resistance simply means requesting a reseeding of the DRBG before generating random output. There is no difference between a "normal" reseeding and a reseeding triggered by a prediction resistance request.
The NIST standard explicitely allows reseeding from a DRBG which is connected to an approved entropy source. There is no word about a need to reseed the parent immediately before obtaining its random output.

If you are questioning the fact that a DRBG can safely be reseeded from the master DRBG, then you question the entire construction of chaining the DRBGs to improve the security of the DRBGs in the first place.
But before going deeper into this, I would like to dispel your concerns about prediction resistance:
I agree that a kernel mode CSPRNG is more secured than a user space CSPRNG. So I completely understand if someone prefers to pull randomness from the former instead of the latter. But this is already possible to do: If the applications needs "strong" prediction resistance for the public or the private DRBG, all it has to do is to call RAND_poll() before calling RAND_bytes() resp. RAND_priv_bytes(). This will reseed the master DRBG from the os entropy sources, and the reseeding will then be propagated to the public resp. private DRBG. Alternatively, it could obtain a pointer to the master DRBG (drbg = RAND_DRBG_get0_master()) and call its generate method requesting prediction resistance.
The facts
I was not trying to interpret the standard, I was stating the facts from the document and verifying them by giving quotations. So please tell me, where exactly I misinterpreted something in my reasoning below. And please point out the reference where it is stated that the parent DRBG's generate method SHALL be called demanding prediction resistance.
The DRBG construction is an approved method of 'stretching' the sparse resource of randomness into a longer pseudo random output. This means that the DRBG's output is computationally indistinguishable from a true random coin toss for an adversary whose computational capabilities lie within the limits assumed for the given security level (not more and not less). This holds under the assumptions that

the DRBG was reseeded from an approved entropy source or nondeterministic RNG
the internal state of the DRBG is unknown to the adversary

If the previous statement holds then not only the first block of 128 bits generated by the parent DRBG is computationally indistinguishable from true random output, but also the second and the third block, etc. So why should the first 128 bit block contain "more entropy" than the second? Neither of them contains any entropy because the output is a deterministic function of the internal state. All the randomness lies in the random choice of this internal state, and the fact that the internal state remains secret.
Nothing else happens when you reseed from the kernel's RNG: You will get some block of pseudo random output from a deterministic RNG and you can't even be certain that enough bits of "fresh" entropy have been added to the kernel's random pool since your last request (more on this subject below).
Calling RAND_DRBG_generate() with prediction_resistance=1 is the request to "reseed before generating output", in order to handle the case that the internal state of the DRBG might have been (partially) compromised. It triggers a "normal" reseed, without any additional constraints on the "quality" of the random input pulled from the entropy source.
The NIST standard explicitely states that instead of an approved nondeterministic RNG or entropy source it is allowed to use a DRBG which is seeded by an approved nondeterministic RNG or entropy source. Indeed, unless the state of the parent DRBG is compromised, too, or the randomness input fed into the child DRBG is intercepted by the adversary, this reseeding will immediately restore the integrity of the child DRBG.
The myth
What is "fresh" entropy in the first place? Is it filled into the DRBG and used up by generate requests like the gasoline of an electricity generator (pun intended)? No, this is just an analogy for humans and taking this analogy too literal is the cause for the misbelief that a DRBG which has been seeded with, say, 128 bits of entropy gets drained after generating 128 bits of random output. This superstition caused generations of programmers to block on /dev/random waiting for "fresh" entropy. I don't know the author of the linked article, but I agree with his arguments, in particular with the quote of Daniel Bernstein, which was taken from this email).
Theory vs. practice
In the context of the NIST document the case is clear: it is not necessary to propagate the prediction resistance request to the master. In our case the situation is a little more complicated, because both DRBGs are located in the address space of the same process, so it is not clear whether the master DRBG's internal state can be considered secure after the child DRBG's internal state was compromised.
Whether or not the master DRBG can be considered secure depends on the threat model. If the adversary can only intercept network traffic and learn about the state of the child DRBG, but does not get to see any of the master DRBG's output, then the answer is clearly yes. (Apropos: it's probably better not to reseed the ssl DRBGs from the public DRBG, because we have no control how much output of the public DRBG will be used for other purposes and become publicly known.)
If the adversary obtained knowledge of the child DRBG's internal state by reading some portion of the process memory, then it is arguable that he might know about the internal state of the master, too. One mitigation for this threat would be to not use static variables to hold the internal state of the three DRBGs, but allocate it from the secure heap.
Anyway, as stated above: It is easy to trigger a full reseed from the os entropy sources either by calling RAND_poll() or by using a DRBG which is not chained and requesting prediction resistance.

TL;DR: Propagating prediction resistance requests is not mandated by the standard, it's a new feature

From the NIST standard's point of view, a prediction resistance request is equivalent to a request to reseed immediately before generating the bytes. Not more, not less.
Your proposal to propagate the prediction resistance request to the parent is a deviation from the NIST standard, let's call it an additional feature.

Now it is legitimate to ask the question whether this additional feature increases security? My answer is
This feature does not add any new security that could not be achieved using the existing features.
For example, if I were paranoid, I could set the reseed_interval of <master> and <private> to 1. Then every call to RAND_priv_bytes() would trigger a full reseed of both shared DRBGs. But note that there is one more side effect: A reseeding of <master> will trigger a reseeding of <public>, because we also implemented downward propagation from <master> to its children. This is also an additional feature that deviates from the NIST standard, but it was necessary to do it in order to fix the RAND_add()/RAND_bytes() pattern. Your upward propagation of prediction resistance requests only adds additional complexity without adding security.
If I were even more paranoid and wouldn't trust DRBG chaining, then I could use my private unchained DRBG instance and either set the reseed_interval to 1, or specify prediction_resistance=1 on every generate request.
That said, one final remark: The RAND API does not support requesting prediction resistance. Nowhere in libcrypto is it used currently. So this pull request adds additional complexity for the empty set.
Summary
-1 from me: This pull request should be closed.

I think the main point of the prediction_resistance_request parameter is to try to recover from the a possible compromise, and you do that by reseeding. If says that you need "fresh entropy" for that.
But then when I actually try to write down how you would implement fresh entropy, I can only come up with 2 definitions:

All the bits collected by the source need to be collected after the last generate call
It can have been collected before the last generate call, we just didn't use it yet. And this mostly depends on the next topic.

In the end it's about which of the DRBGs in the chain have been compromised, and I guess there are several separation levels:

The DRBG itself
The process
The kernel
The hardware

I guess that if the process itself is compromised, there is little point in trying to recover.

(edited previous reply slightly)

Since you don't know which DRBGs all have been compromised, it seems to me that NIST standard have resolved this by requiring all DRBGs in the chain to reseed. This is based on that the get_entropy and reseed functions have a prediction_resistance_request parameter indicating that it's not a normal one, it needs to get fresh entropy. But I think what it really wants is non-compromised entropy, not fresh entropy.

I've been reading SP 800-90C again, and in 10.1.1 it says that if get_entropy was called with prediction resistance that the generate call should be called with prediction resistance.

I skimmed over SP 800-90C this evening, too. I still need some time to read the document more thoroughly, but it seems now that you are probably right and that I was too much focused on SP 8000-90A and did not consider the changed requirements in SP 800-90C. If my last post sounded too harsh, then I apologize for it.
In view of the approaching deadline for the beta freeze we should probably change the signature of the get_entropy callback before publishing the API, but otherwise postpone the discussions about prediction resistance until after the freeze, because it will only become relevant for the upcoming FIPS evaluation. I need to concentrate on finishing the documentation now, otherwise it is possible that we will end up with no public RAND_DRBG API at all for 1.1.1.

New commit pushed


Add monitoring for jenkins agents

We've had occasions where Jenkins agents have lost their connection to the Jenkins master, even when the processes and server seems to be OK. This hopefully allows us to monitor the agent status from the perspective of the master.

I think this approach is cool, I don't have a better one!


Lord protector's retainer breaks the game

Whenever conditions are satisfied to trigger lord protectors retainer, the game crashes.

seems like a problem with GameActions.cancelEffects(context => ({ event: context.event })). this game action is only used in 2 other cards and those are from the bin pack, so probably wasn't tested much.
Implementation is also missing cost and message.

@Duckbringer I think the issue is that the following event.targets.hasSingleTarget() and event.targets.anySelection needs to be event.ability.targets:
https://github.com/throneteki-playtesting/throneteki/blob/fcad4054dc80f53f1baf15a332f7c5f70df31eb2/server/game/cards/23-AHaH/LordProtectorsRetainer.js#L10-L16

High Septon is implemented in similar way and has event.targets.hasSingleTarget() as well. I believe the problem was with the event.ability.targets.some(target => target.type === 'choose') as in ResolvedTargets.js targetingType is used, not just type
hasSingleTarget() {         return this.selections.length === 1 && this.selections[0].targetingType === 'choose' && !Array.isArray(this.selections[0].value);     }


Payload size flag is added for GRPC.

Using payload size flag, payload field will be generated randomly as a string for grpc ping message.
Random payload generator method is moved to network from http_server for reusing.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
Assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @olimpias. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

also let's increase/keep coverage

Thank you for your comments :)


update quickstart

@davixcky, I don't see an quickstart-v3-fix image, don't we need it? How are going to be the instructions here?

@daniel-de-vera quickstart-v3-fix added
https://hub.docker.com/repository/docker/signadot/hotrod/tags?page=&page_size=&ordering=&name=quickstart-v3-fix

We'd probably want to update the quickstart doc to use v3 as well.


send a message to #general when complex team conversion happens.

We consume the new return value from Gregor letting us know that we created a complex team, and then send a message into #general to let users know about the change.

cc @malgorithms @chrisnojima

The commits 217c6d4680a0...99303930560d introduce visual changes on linux. :mag_right: 1 changed

Changed: Markdown-emoji (before) (after)


simulate midnight apache restart

Last night we succeeded in running an ingest through the apache restart. The ingest finished at 12:18AM.


--color_blocks off adds an extra new line in the output

Description
passing --color_blocks off as an argument, color blocks get removed, but an extra new line is added at the end of output, making neofetch not fit completely in my terminal.
It worked fine in 2.0.2 version, and I got this issue after an AUR update today.
Neofetch version
3.0
Screenshot
With --color_blocks off. There are 4 new lines as highlighted. Notice the top row with my username missing.

Without --color_blocks off. There are 3 new lines as highlighted.

 But I have no config file anyway, just an alias in my .bashrc.
$ type neofetch
neofetch is aliased to `neofetch --colors 203 fg 203 203 203 fg --ascii_colors 203 --color_blocks off '

Try out the latest master, the issue should be fixed now.

Weirdly, the extra newline is fixed only if neofetch is called directly.  Perhaps this issue should be re-opened.


Python 3

Hi @jerabaul29,
I would like to take a look at the IMU data we sampled in Svalbard, but I am not quite sure how to. I have cloned this repository and as I understand it, I first need to parse the data. I tried to run the test_process_folder.py under /LoggerWavesInIce/Logger_GPS_SD_VN_Binary_output_Parser, but I got the following error: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfa in position 53: invalid start byte. Has this got something to do with the fact that I run Python v 3? I already corrected the print syntax in parser_logger.py to Python 3.
Maybe you can give me a clue on how to proceed here?
Trygve

Ok. This code should work - I and other people used it several times - , but I am afraid that the different encoding used by python3 breaks things. You can either fix the encoding stuff yourself in the code (for this, see how I fixed it when doing the bow measurements analysis), or (maybe simpler) use python 2 by just using the python command instead of the python3 command (note: you will need to sudo pip install all necessary packages, even if they had been sudo pip3 installed for python3 before).

Ok, I'm trying to convert the encoding to python3. I have been able to parse the data, but it is a bit unclear how I should organize the directory tree. I have used only one instrument a couple of hours per day over five days. This gives me typically 15 F0XXXX files per day, in total 67 files. When they are parsed, each file generates 11 new files (F0XXXX_B, etc.). How would you suggest I organize the files with split_data_between_folders.py so that I can best proceed with the further analysis? In process_IMU_data_structure.py, the following tree is suggested (which I find a bit confusing)

Excellent, great to hear parsing worked!
So basically then you have a single IMU folder, and in this folder you have all your FXXXX files. The files with extensions are the parsed data that you can use for your analysis. Once the parsing has been done, you can have a try at the processing scripts here:
https://github.com/jerabaul29/LoggerWavesInIce/tree/master/processing_scripts
Note that:

these scripts were developed for looking at much larger amounts of data from more instruments than you have, so you can probably ignore quite a lot of them

as a consequence, you should only take the scripts as some inspiration / suggestions of how to do your processing.

Note also that the different files are quickly explained in the readme here:
https://github.com/jerabaul29/LoggerWavesInIce/tree/master/Logger_GPS_SD_VN_Binary_output_Parser
If anything is unclear, looking at the code is the documentation in the present case:
https://github.com/jerabaul29/LoggerWavesInIce/blob/0d08f0d129482b25e651786e4eda92d95e46b9a8/Logger_GPS_SD_VN_Binary_output_Parser/parser_logger.py#L229-L401

Thanks for the help and for the comments. I'm not sure if the parsing worked properly, because the only files with extensions containing any data are FXXXXX_B (196 B) and FXXXXX_P (approx 3.7 MB), all the other extensions for each file seems to be empty. Is this how it is suppose to be?
From the readme you refer to, I understand it as one need to run the scripts in processing_scrips in a certain order. After the parsing is done one need to run prepare_data_damping.py. This complains a bit about the file extensions being empty and then stops with the following error:

Ok, we can discuss this at the meeting in a few minutes :)

Python 2 works, thank you for the advice!

Perfect, great to hear! :)

Working now so closing, feel free to open new issues if you have other problems / questions.


Invalid monitors.xml format

My monitors.xml, which is generated by gnome, doesn't seem to match the XML tree expected by the code.
My monitors.xml is the following :
<monitors version="2">
  <configuration>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>DP-1</connector>
          <vendor>AOC</vendor>
          <product>2460G5</product>
          <serial>0x00000a03</serial>
        </monitorspec>
        <mode>
          <width>1920</width>
          <height>1080</height>
          <rate>60.000495910644531</rate>
        </mode>
      </monitor>
    </logicalmonitor>
    <logicalmonitor>
      <x>0</x>
      <y>1080</y>
      <scale>1</scale>
      <monitor>
        <monitorspec>
          <connector>eDP-1</connector>
          <vendor>CMN</vendor>
          <product>0x14c0</product>
          <serial>0x00000000</serial>
        </monitorspec>
        <mode>
          <width>1920</width>
          <height>1080</height>
          <rate>60.008350372314453</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
</monitors>

The GnomeStore expect to find some elements named output inside a configuration, but as we can see, there is none.

GNOME have updated their monitors.xml to use a new schema some time ago.

Ok. Do you know if a documentation exist for this file by Gnome ? I don't find one.

There was some wiki page iirc, but it's probably outdated now.

Can I freely implement the last version, or must I care about backward compatibility ?

TBH I'm not a fan of supporting GNOME's private config file anymore. What would be your use-case?
Also a complete rewrite of this project is planned...

My use case is that I use both GNOME and Sway. So having a common configuration is nice for me. But I understand the fact that it is not desirable to support GNOME's config file. I can do without.