Add support for tree with slimmer block size

For example, Caupona added 2 trees which are fig tree and wolfberry. But, it's not using the size of a typical log block but a fence.
Perhaps add config or way for other mod to allow some log to start instead at N size of chopped blocks?

There should be a API that is able to set initial chops.

Yeah, I'm happy to add some (API) support for slimmer trees. I'll try to get this done sometime next week.
Do either of you know of other mods that add slim/non-standard sized trees?

I don't know about other mods but, some kind of notice about added compatibility like this one on TC curseforge page would be nice. End users will notify other mod developers to add integration.

I don't know about other mods but, some kind of notice about added compatibility like this one on TC curseforge page would be nice. End users will notify other mod developers to add integration.

@strdsk Agreed! I'll be sure to add better compatibility info on the curseforge page, for both users and devs

There should be a API that is able to set initial chops.

@khjxiaogu It's not released yet, but I've added an interface for this. In the simplest case, all that's needed is to override getUnchoppedRadius to return the radius of the log. Here's an example:
https://github.com/hammertater/treechop/blob/109050bf8c6fc1816465be226550573577c9cc45/tests/fabric-tests/src/main/java/ht/treechoptests/block/SkinnyLog.java#L9-L18
By default, skinnier logs can't be chopped as many times as full-size logs, so I've also made them require fewer chops to fell. This behavior can be overridden. If interested, see
https://github.com/hammertater/treechop/blob/main/shared/src/main/java/ht/treechop/api/IChoppableBlock.java
https://github.com/hammertater/treechop/blob/main/shared/src/main/java/ht/treechop/api/ISimpleChoppableBlock.java
Also, for now, chopping slim logs that are horizontally adjacent is wonky (treechop thinks they're connected). Fixing this shouldn't affect the API though.
Note that the API is split across the "fabric" and "shared" modules. Most of the stuff is in "shared". I'll be sure to add documentation for all this when it's released.

It's not released yet, but I've added an interface for this. In the simplest case, all that's needed is to override getUnchoppedRadius to return the radius of the log. Here's an example:

Making mod blocks from other mod to implement your interface would cause a mess, as they may have to put your mod into dependency or use hacks. Why not make a map or recipe or datapack. This have a much higher compatibility and easier to add support by other mods.

Making mod blocks from other mod to implement your interface would cause a mess

Oh yikes, I had assumed implementing an interface would not create a required dependency (you're not using any of my code, just defining functions that match my definitions), but you're totally right. That was embarrassing...
Still, a super simple mixin removes the runtime dependency:
https://github.com/hammertater/treechop/blob/main/tests/fabric-tests/src/main/java/ht/treechoptests/mixin/HugeMushroomBlockMixin.java
With a super simple mixin plugin to check if treechop is loaded:
https://github.com/hammertater/treechop/blob/main/tests/fabric-tests/src/main/java/ht/treechoptests/TestsMixinPlugin.java#L13-L20

Why not make a map or recipe or datapack. This have a much higher compatibility and easier to add support by other mods.

Just trying to minimize how much stuff I have to support. I already use the interfaces internally, so making them part of the API is sort of a freebie. They're also much more performant and don't require any extra complexity/bookkeeping on my part, so less chance of breaking.
I can't imagine any other code-based approach would be simpler than the mixin example. Thanks for the map example though, I'll be happy to give it a shot if you think there are issues with the mixin approach. I'll admit, I haven't been in the minecraft modding circle for very long, so I appreciate the pointers. If I have the time, I'll look into the recipe/datapack approaches too, I'm sure they'll help folks who use things like MCreator or are limited to making datapacks.

@khjxiaogu Sorry for the wait. I've added methods for registering block handlers, as you suggested. See examples here for retrieving a TreeChopAPI instance, and here for registering a handler to specify the radius of a block

@khjxiaogu Sorry for the wait. In 0.17.0 (only for 1.19.2 at the moment) I've added methods for registering block handlers, as you suggested. See examples here for retrieving a TreeChopAPI instance, and here for registering a handler to specify the radius of a block

Well done, I would try that later.

Another mod that adds a slimmer tree is the bamboo tree from Regions Unexplored

Tested, It didn't work well.
There are some problems:

The texture problem still exists when chopping, however I can use other vanilla texture and fix that.
Seems that getRadius is some sort of setting minimum radius instead of maximum radius.
getRadius returns 1 would cause the log unbreakable, as 1 is inclusive in documentation, and caupona trees actually only 1 radius.
getNumChops does not work.
Here is my code, did I make anything wrong?
@hammertater

The texture problem still exists when chopping, however I can use other vanilla texture and fix that.

Yeah, right now it assumes the UVs are (0,0) to (1,1) (screenshots in #155). This should be fixed in the next TreeChop update.

Here is my code, did I make anything wrong?

Thanks for sharing, I'll look at it later tonight

Seems that getRadius is some sort of setting minimum radius instead of maximum radius.

Weird, it should set the maximum radius. I'll try to test this in the next couple days.

getRadius returns 1 would cause the log unbreakable, as 1 is inclusive in documentation

Oh yeah, the lower limit should probably be 2. Each chop reduces the radius by 1, so it doesn't make sense to try to chop a block with radius 1, as it can't get any smaller. So, if getRadius returns 2, the block can be chopped one time down to the minimum radius of 1.

and caupona trees actually only 1 radius.

I'd expect getRadius to return half the width of the block's voxel shape. From this line:
https://github.com/TeamMoegMC/Caupona/blob/f56f6708dfb7d0fe51d757aba020199e5e184353/src/main/java/com/teammoeg/caupona/blocks/plants/BushLogBlock.java#L40
Looks like your blocks are 12 - 4 = 8 units across, so getRadius should return 4

getNumChops does not work.

Just have it return 0 for now, it's very unlikely you'll need to change that. It's only useful if you want to use a custom block instead of the default treechop:chopped_log for chopping. I'll add this to the documentation.
So, a basic handler for a slim log of radius 4 would just be this:
public class SlimTreeHandler implements ISimpleChoppableBlock {
    @Override
    public int getRadius(BlockGetter level, BlockPos blockPos, BlockState blockState) {
        return 4;
    }
}

and the other methods can use the default implementations for ISimpleChoppableBlock.
Thanks for trying this stuff out!

So, a basic handler for a slim log of radius 4 would just be this:
I've tried to set from 1 to 8, neither take effect, but as I set higher the value, I find it take more time to chop, while initial radius unchanged. To conclude, minimum radius goes smaller as radius increases, but inital (or maximum) radius is not affected. So it is not the maximum radius, but the maximum chopping time.
Just have it return 0 for now, it's very unlikely you'll need to change that. It's only useful if you want to use a custom block instead of the default treechop:chopped_log for chopping. I'll add this to the documentation.
I guess if this returns the value from getRadius while getMaxChops returns constant 8, would fix this issue.

You're totally right, getRadius isn't working correctly. It seems to work on Fabric but not on Forge. I'll get it fixed asap

I guess if this returns the value from getRadius while getMaxChops returns constant 8, would fix this issue.

The problem with changing getNumChops from 0 is that it could really mess up the way chops are counted. Trees would always get felled with one chop, among other issues. So that method is only for really special use cases... it definitely needs some more documentation

Ok, I getRadius should be fixed in 0.17.3. So, just overriding getRadius to return 4 should work for you. The texture issue (#155) should be fixed too, but that won't matter much if you're setting the chopped texture manually using the IStrippableBlock interface. If you do decide to add stripped variants of your logs in the future, TreeChop should automatically detect them and use their textures for chopped logs.

Tested all good.

Glad to hear! Closing


Add onRedirectNavigate callback to stop navigatation and get redirect url

This adds a new callback for loginRedirect and acquireTokenRedirect to allow applications to get the URL that would be navigated to, and to stop navigation. This is to support scenarios where applications want to perform the redirect themselves, instead of relying on MSAL.
Usage:
msal.loginRedirect({
  onRedirectNavigate: url => {
    // url that would be navigated to
    console.log(url);

     // Applications must explicitly return false to stop navigation
     return false;
  }
})

Coverage increased (+0.05%) to 78.575% when pulling 5f9340ad5de0167d9a5cabcf68432eef775b47fe on onRedirectNavigate into e65a909267a727d78894eba3f54e48591dea8918 on dev.


Non-used URLs open bugged new page

Any URL that is not defined in our router by default opens a /new page. However after the custom themes update (v3.14.0), this opens with errors in saving and no snippet menus:

With the next error in console:
Error: Not Found
    at Request.<anonymous> (https://homebrewery.naturalcrit.com/homebrew/bundle.js:78344:21)
    at Emitter.emit (https://homebrewery.naturalcrit.com/homebrew/bundle.js:1954:20)
    at XMLHttpRequest.<anonymous> (https://homebrewery.naturalcrit.com/homebrew/bundle.js:78638:10)
{
  "status": 404,
  "method": "GET",
  "url": "/api/theme/undefined/undefined"
}

This should be fixed.

Hmm, yeah, alright then.


Missing info which HMD's support built in Bluetooth radio

Various parts of the enthousiast guide such as in controllers-in-wmr.md mention HMD's with integrated bluetooth, but there is no list for consumers to know if their HMD is supported.

Hello! Thanks for your feedback. For your HMD, it would be best to search to see if it has integrated bluetooth then search to see if your motion controllers are compatible with your HMD or another PC/computer.
If you need help setting up your motion controllers with your HMD, this is a good article to start with: https://docs.microsoft.com/en-us/windows/mixed-reality/design/motion-controllers .
As for a list of all controllers and what HMDs they are compatible with, we aren't in a position to cover all options. It's best to search for compatibility for your specific device(s).

If the before you buy FAQ has technical specifications, why can't it include bluetooth support info as well? mixed-reality/enthusiast-guide/before-you-buy-faqs.md


Vertical position when position is 'right' or 'left'?

Hi, I'm trying to achieve a placement for the popover to the left or right of an element that is rather tall. It's actually taller than the viewport.
Right now, bootstrap-tour is placing the popover vertically centered over the height of the element, and then scrolling the view to the top of the element. This causes the popover to be positioned offscreen, outside the viewport.
What I'd like to do is ensure that the vertical position is centered to an area no taller than the height of the viewport. Or, better yet, enable a position of 'right top' or 'left top', where the vertical position of the top of the popover would be aligned with the top of the target element.
Is there a way to do this that I'm missing? Thanks.

Hi, any solution?


Add k8s_apiserver to ovn-config configmap

As of PR 605 - k8s_apiserver is required in the ovn-config configmap
PR 605 didn't set the k8s_apiserver in the config map. This change
fixes that and allows ovn to again work on openshift.
Signed-off-by: Phil Cameron<EMAIL_ADDRESS>

@dcbw @squeed @girishmg PTAL
@squeed, we need to figure how to fix this in 4.0 on aws :-(

@pecameron How does that value get populated in ovn-setup.yaml for non-openshift deployment?

@girishmg I don't know how k8s_apiserver gets populated in Kubernetes, I don't use Kubernetes. How do you get it populated in your testing?
PR 605 did not deal with getting the k8s_apiserver key into the config map. That alone breaks yaml files that reference it in the K8S_APISERVER environment variable. So ovn on openshift no longer works. I assumed that you created the needed configmap as part of your install. Clearly the existing ansible created Openshift configmap is not going to work for you since it does not have the k8s_apiserver key.
This PR gets Openshift working again.
From the first kubernetes based openshift we have relied on /etc/origin/node/node.kubeconfig for everything it takes for every node to deal with the API server. Anyone that needs to talk to the apiserver can get whats needed there. I am not familiar with how Kubernetes handles this.
The approach of placing k8s_apiserver into the configmap and using Environment variables is problematic for the latest Openshift install because of how Openshift 4.0 gets installed. Unless I find another way, I am going to have to mount /etc/node and rely on the file.  For better or worse much of this will be in a different repo (https://github.com/openshift/cluster-network-operator/), however ovnkube.sh will need some changes since it is common for all of us.

@squeed we need to discuss how to fix this in 4.0. I can change ovnkube.sh to use a missing/empty K8S_APISERVER to grab the /etc/origin/node/node.kubeconfig file. What would you like to do?

@dcbw @shettyg @squeed @girishmg Is this ready to merge? Are further changes needed?

For Girish mostly, OpenShift 4.0 has a different install path that doesn't use Ansible and will directly sub the apiserver into the K8S_APISERVER environment variable.

@dcbw and @pecameron Thanks for the explanation.


What is dask.quote?

I get that this has an SO flavor to it, but instead what I'm getting at is this doesn't appear to be documented. 😕 In fact, the first time I heard of it was in issue ( https://github.com/dask/dask/issues/2299 ).

Does the docstring suffice?
def quote(x):
    """ Ensure that this value remains this value in a dask graph

    Some values in dask graph take on special meaning. Sometimes we want to
    ensure that our data is not interpreted but remains literal.

    >>> quote((add, 1, 2))  # doctest: +SKIP
    (literal<type=tuple>,)
    """
    if istask(x) or type(x) is list:
        return (literal(x),)
    return x

Given that this is an internal function (not exposed through the public API) this meets my personal criteria for documentation.  Is confusion about this function restricting productivity somehow?

Ah by not documented I meant not in RTD (API or otherwise). If it is meant to be internal, then that seems unnecessary. So feel free to close.


refactor!: Rework package

Hi @jeffrey0606 I reworked your package, so it can be used in another command line application, without the need to create any of the files by the user.
Changes:

Optional path for executable out dir
Read properties from pubspec.yaml
flutter_to_debian create now becomes flutter_to_debian build
flutter_to_debian create only creates the debian folder and files
option --build-version for flutter_to_debian create and flutter_to_debian build
refactor command line arguments to use ArgParser
adapt common folder structure and naming conventions

Thanks for merging :)


Graph #3 Development

Graph 1 with edges and nodes is done.Static Picker is done.Need to add logic to validate the graph.


Update all dependencies and github actions to latest versions

This commit bumps up go version from 1.19 to 1.22 for go.mod and dockerfile
This commit also bumps up several dependencies to the latest version as of
March 2024.
k8s.io/api v0.29.2
k8s.io/apiextensions-apiserver v0.29.2
k8s.io/apimachinery v0.29.2
k8s.io/client-go v0.29.2
k8s.io/klog/v2 v2.120.1
openshift/api -> v0.0.0-20240124164020-e2ce40831f2e
openshift/library-go -> v0.0.0-20240124134907-4dfbf6bc7b11
ramendr/ramen/api -> v0.0.0-20240117171503-e11c56eac24d
red-hat-storage/ocs-operator -> v0.4.13
rook/rook/pkg/apis -> v0.0.0-20231204200402-5287527732f7 (New module for rook)
open-cluster-management.io/addon-framework -> v0.9.0
open-cluster-management.io/api -> v0.13.0
sigs.k8s.io/controller-runtime -> v0.15.3 (Replaces 0.17.2 currently due to several changes)

/hold cancel

/test integration-test

/retest

/retest


Load JWK Definitions Improvement

https://github.com/spring-projects/spring-security-oauth/blob/cc4c0a52086309a6eed3fd8a2304b31055e7c9d7/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/token/store/jwk/JwkDefinitionSource.java#L89
JwkDefinitionSource.getDefinitionLoadIfNecessary should check if the definition has been loaded in the synchronized before clearing and loading definitions. The current implementation has the side effect of a second thread waiting for the lock will attempt to also reload the definitions.
The following code should prevent this duplicate work.
JwkDefinitionHolder getDefinitionLoadIfNecessary(String keyId) {
	JwkDefinitionHolder result = this.getDefinition(keyId);
	if (result != null) {
		return result;
	}
	synchronized (this.jwkDefinitions) {
		result = this.getDefinition(keyId);
		if(result != null) {
			return result;
		}
		this.jwkDefinitions.clear();
		for (URL jwkSetUrl : jwkSetUrls) {
			this.jwkDefinitions.putAll(loadJwkDefinitions(jwkSetUrl));
		}
		return this.getDefinition(keyId);
	}
}

I faced the problem with performance tests :
When a bulk of users are requesting the API (on a fresh instance started from auto-scaling strategy), they all come with a token and the given jwk definitions are cleared for each user waiting in this synchronized section...
Here is the quick fix suggested by @cgaskill  : #1443


NIFI-5640: Improved efficiency of Avro Reader and some methods of Avr…

…oTypeUtil. Also switched ServiceStateTransition to using read/write locks instead of synchronized blocks because profiling showed that significant time was spent in determining state of a Controller Service when attempting to use it. Switching to a ReadLock should provide better performance there.
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically master)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Reviewing...

+1 LGTM, ran full build and tried various Avro conversions, reading/writing. Thanks for the improvement! Merging to master


:bug: Invalid configs with v2.0.0-rc*

Kairos version:
v2.0.0-rc*
CPU architecture, OS, and Version:

Describe the bug
Seems installation with webui are broken (maybe not only affecting webui).
The collector seems to not write down correctly the config supplied by the user.
Input config for installation:
#cloud-config
hostname: nuc-{{ trunc 4 .MachineID }}
k3s:
    enabled: true
users:
    - name: kairos
      ssh_authorized_keys:
        - github:mudler

The config file after install was the following (in /oem):
#cloud-config

BOOT_IMAGE: (hd0)/boot/kernel
cdroot: true
console: ttyS0
net:
  ifnames: "1"
nodepair:
  enable: true
nomodeset: true
rd:
  cos:
    disable: true
  live:
    dir: /
    squashimg: rootfs.squashfs
root: live:CDLABEL=COS_LIVE
selinux: "0"
vga: "795"

few things to note here:

the previous code (before the collector was introduced) was saving only what was mapped to the config structure from the cmdline, so you don't end up mixing bootargs in the cloud config file that are not in any structure (we can't set there k3s settings for instance, but it is enough specifying a remote config_url to fetch)
there are ONLY cmdline configs in there now - the user config is completely discarded
there are mixtures of extra cmdlines which are not pertinent to the installation

To Reproduce
Get an ISO (I've tested with  kairos-opensuse-leap-v2.0.0-rc4-k3sv1.23.17+k3s1.iso ) and try to install from the WebUI
Expected behavior
To have
#cloud-config
hostname: nuc-{{ trunc 4 .MachineID }}
k3s:
    enabled: true
users:
    - name: kairos
      ssh_authorized_keys:
        - github:mudler

In the /oem files
Logs

Additional context
This is high prio, as currently blocks https://github.com/kairos-io/kairos/issues/754

It's worth noting that the installation via the UI as mentioned looses the specified cloud-config, but installing via registration or manual installation does include it. This means we probably have 2 bugs there, one for the cmdline and one for the WebUI
#cloud-config
BOOT_IMAGE: (cd)/boot/kernel
cdroot: true
console: ttyS0
hostname: nuc-{{ trunc 4 .MachineID }}
net:
  ifnames: "1"
nodepair:
  enable: true
nomodeset: true
rd:
  cos:
    disable: true
  live:
    dir: /
    squashimg: rootfs.squashfs
root: live:CDLABEL=COS_LIVE
selinux: "0"
users:
- name: kairos
  passwd: kairos
  ssh_authorized_keys:
  - github:mauromorales
vga: "795"

It's worth noting that the installation via the UI as mentioned looses the specified cloud-config, but installing via registration or manual installation does include it. This means we probably have 2 bugs there, one for the cmdline and one for the WebUI
#cloud-config
BOOT_IMAGE: (cd)/boot/kernel
cdroot: true
console: ttyS0
hostname: nuc-{{ trunc 4 .MachineID }}
net:
  ifnames: "1"
nodepair:
  enable: true
nomodeset: true
rd:
  cos:
    disable: true
  live:
    dir: /
    squashimg: rootfs.squashfs
root: live:CDLABEL=COS_LIVE
selinux: "0"
users:
- name: kairos
  passwd: kairos
  ssh_authorized_keys:
  - github:mauromorales
vga: "795"

this also explains why CI was green

we can close this now, it's been fixed!


Fuzzy dates

I think I have found a way to decouple generic date parsing logic from data source specific logic. That allows us to add more data sources, or even create parsers for specific fields. I will push that. Let me know if you think that's better

The NPE problem here seems still valid to me: https://github.com/Sp2000/colplus-backend/commit/cc1846c3f2000fcdc1ce3643bf91dbf7e876b5d7#r28266928
Otherwise good to be merged back!


--wait option would be useful for ssh

Instead of typing
tugboat wait rethink; tugboat ssh rethink

it would be convenient to simply type
tugboat ssh -w rethink

(with -w of course being the short form of --wait).

@brandondrew Long time coming, but implemented! :+1:


add StackOverflow to support channels

Since we are now redirecting users to StackOverflow for support
questions, it makes sense to add it to the official support channels.

Congratulations you won a Furby for being the PR number 1000!!!
Here is your prize:

/>


dropdown-menu / handle no header

hello team,
This PR brings a different way to use the the dropdown menu
In order to apply the design below, I made the dropdown to whether or no accept a "header" slot
So from now on, when the dropdown is called without header, the menu will be displayed straightaway
I also added a method that align children menu dynamically to it parent

Can you update the website to be able to play with the new props?

the way I display the :menuItems props in the doc could be optimised, feedbacks are welcome

:tada: This PR is included in version 1.4.0-rc.49 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update Library Model Loader to mark fields Nullable

Followup on an update in NullAway recent change #878 which enables NullAway to mark fields as @Nullable. This PR updates our LibraryModelsLoader to enable communication of Annotator and NullAway to mark fields @Nullable while analyzing downstream dependencies. This is required to prepare the code for the upcoming change which enables Annotator to be informed of impacts of making fields @Nullable on downstream dependencies.

Please note that CI will fail as it requires release of NullAway version 0.10.19.

Overall looks good! I have a few comments. Also, why is nullable-methods.tsv checked in as an empty file?

@msridhar Thank you very much for the review, this is ready for another round.
Regarding

Also, why is nullable-methods.tsv checked in as an empty file?

We weren't creating / deleting files in resource directory (which we are now 6dd203e). We used to assume the file exists and clear contents instead of deleting. With the new approach, we no longer need the file.

@msridhar I don't see the nullable-methods.tsv file on my branch.  Isn't this PR actually deleting the existing nullable-methods.tsv on master branch ? Please let me know if I am missing something.

@msridhar I don't see the nullable-methods.tsv file on my branch. Isn't this PR actually deleting the existing nullable-methods.tsv on master branch ? Please let me know if I am missing something.

Yes, you're right.  For some reason GitHub shows the change strangely.  Locally git shows the file as removed.  Sorry for the confusion.

@msridhar Ok great, will land this one now and update #221.


knctl deploy --env parameter can't contain comma-separated value

We are trying to deploy a Java application like this:
knctl deploy ... --env JAVA_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

It seems that the env value is truncated after the first comma:
ERROR: JDWP invalid option: -agentlib:jdwp=transport=dt_socket

We've tried different quoting variations (single quotes around value, double quotes etc.), but without success. Can you please check?
Thanks a lot for your support!

I believe we have a similar/same issue - the error message isn't helpful in our case
Error: Expected environment variable to be in format 'ENV_KEY=value'
Deployment:
knctl deploy ... --env MONGO_DB_URI="mongodb://<USERNAME>:<PASSWORD>@shard-00-00-qpzhp.gcp.mongodb.net:27017,shard-00-01-qpzhp.gcp.mongodb.net:27017,shard-00-02-qpzhp.gcp.mongodb.net:27017/test?ssl=true&replicaSet=shard-0&authSource=admin&retryWrites=true"
If we remove the env MONGO_DB_URI we don't get this error message
knctl is great; really appreciate all the work that's gone into it!

@jochenehret @matthew1534 fix is in this commit: https://github.com/cppforlife/knctl/commit/1a23540a97ad719e633aa0a00b9535f360e21660. it's going through CI now; once it goes green i'll cut a new release.
thanks for reporting!

fixed in https://github.com/cppforlife/knctl/releases/tag/v0.2.0

knctl is great; really appreciate all the work that's gone into it!

glad you find it useful!


feat: allow chatReportSelector to return the object for IOU reports

Details

This PR updates the chatReportSelector function in the SidebarLinks component such that it returns the report object for IOU reports.
Fixed Issues

$ https://github.com/Expensify/App/issues/19570
PROPOSAL: https://github.com/Expensify/App/issues/19570#issuecomment-1562158086
Tests

Open ND and create a IOU request.
Click the IOU request in the page that opens such that you land onto the IOU chat page
Write anything and verify that the draft icon appears for that chat in the LHN

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

Offline tests

N/A
QA Steps

Open ND and create a IOU request.
Click the IOU request in the page that opens such that you land onto the IOU chat page
Write anything and verify that the draft icon appears for that chat in the LHN

[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 / 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 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 correct English and 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] 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(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 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 author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/30054992/50e4f5a6-fb40-431f-a5bd-b7dcae35542f

Mobile Web - Chrome

https://github.com/Expensify/App/assets/30054992/9fb529f6-0e3d-49bb-9623-0e50aa7aff7a

Mobile Web - Safari

https://github.com/Expensify/App/assets/30054992/83a67325-018b-4521-bc09-facceab12fc4

Desktop

https://github.com/Expensify/App/assets/30054992/b8edaf6f-7133-4ac3-ae4d-a037de2af528

iOS

https://github.com/Expensify/App/assets/30054992/3b83967b-150b-4de9-8be9-1746c4b82496

Android

https://github.com/Expensify/App/assets/30054992/d6daaa0a-ab7a-43b0-b1c9-ca6bba2c56bf

Thanks!

: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/yuwenmemon in version: 1.3.20-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Julesssss in version: 1.3.20-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅