`depositAndAllocateForPartyB` is broken due to incorrect precision
Due to incorrect precision, any users or external protocols utilizing the `depositAndAllocateForPartyB` to allocate 1000 USDC will end up only having 0.000000001 USDC allocated to their account. This might potentially lead to unexpected loss of funds due to the broken functionality if they rely on the accuracy of the function outcome to perform certain actions that deal with funds/assets.\\nThe input `amount` of the `depositForPartyB` function must be in native precision (e.g. USDC should be 6 decimals) as the function will automatically scale the `amount` to 18 precision in Lines 114-115 below.\\n```\\nFile: AccountFacetImpl.sol\\n    function depositForPartyB(uint256 amount) internal {\\n        IERC20(GlobalAppStorage.layout().collateral).safeTransferFrom(\\n            msg.sender,\\n            address(this),\\n            amount\\n        );\\n        uint256 amountWith18Decimals = (amount * 1e18) /\\n        (10 ** IERC20Metadata(GlobalAppStorage.layout().collateral).decimals());\\n        AccountStorage.layout().balances[msg.sender] += amountWith18Decimals;\\n    }\\n```\\n\\nOn the other hand, the input `amount` of `allocateForPartyB` function must be in 18 decimals precision. Within the protocol, it uses 18 decimals for internal accounting.\\n```\\nFile: AccountFacetImpl.sol\\n    function allocateForPartyB(uint256 amount, address partyA, bool increaseNonce) internal {\\n        AccountStorage.Layout storage accountLayout = AccountStorage.layout();\\n\\n        require(accountLayout.balances[msg.sender] >= amount, "PartyBFacet: Insufficient balance");\\n        require(\\n            !MAStorage.layout().partyBLiquidationStatus[msg.sender][partyA],\\n            "PartyBFacet: PartyB isn't solvent"\\n        );\\n        if (increaseNonce) {\\n            accountLayout.partyBNonces[msg.sender][partyA] += 1;\\n        }\\n        accountLayout.balances[msg.sender] -= amount;\\n        accountLayout.partyBAllocatedBalances[msg.sender][partyA] += amount;\\n    }\\n```\\n\\nThe `depositAndAllocateForPartyB` function allows the users to deposit and allocate to their accounts within a single transaction. Within the function, it calls the `depositForPartyB` function followed by the `allocateForPartyB` function. The function passes the same `amount` into both the `depositForPartyB` and `allocateForPartyB` functions. However, the problem is that one accepts `amount` in native precision (e.g. 6 decimals) while the other accepts `amount` in scaled decimals (e.g. 18 decimals).\\nAssume that Alice calls the `depositAndAllocateForPartyB` function and intends to deposit and allocate 1000 USDC. Thus, she set the `amount` of the `depositAndAllocateForPartyB` function to `1000e6` as the precision of USDC is `6`.\\nThe `depositForPartyB` function at Line 78 will work as intended because it will automatically be scaled up to internal accounting precision (18 decimals) within the function, and 1000 USDC will be deposited to her account.\\nThe `allocateForPartyB` at Line 79 will not work as intended. The function expects the `amount` to be in internal accounting precision (18 decimals), but an `amount` in native precision (6 decimals for USDC) is passed in. As a result, only 0.000000001 USDC will be allocated to her account.\\n```\\nFile: AccountFacet.sol\\n    function depositAndAllocateForPartyB(\\n        uint256 amount,\\n        address partyA\\n    ) external whenNotPartyBActionsPaused onlyPartyB {\\n        AccountFacetImpl.depositForPartyB(amount);\\n        AccountFacetImpl.allocateForPartyB(amount, partyA, true);\\n        emit DepositForPartyB(msg.sender, amount);\\n        emit AllocateForPartyB(msg.sender, partyA, amount);\\n    }\\n```\\n
Scale the `amount` to internal accounting precision (18 decimals) before passing it to the `allocateForPartyB` function.\\n```\\nfunction depositAndAllocateForPartyB(\\n    uint256 amount,\\n    address partyA\\n) external whenNotPartyBActionsPaused onlyPartyB {\\n    AccountFacetImpl.depositForPartyB(amount);\\n// Add the line below\\n    uint256 amountWith18Decimals = (amount * 1e18) /\\n// Add the line below\\n    (10 ** IERC20Metadata(GlobalAppStorage.layout().collateral).decimals());\\n// Remove the line below\\n    AccountFacetImpl.allocateForPartyB(amount, partyA, true);\\n// Add the line below\\n    AccountFacetImpl.allocateForPartyB(amountWith18Decimals, partyA, true);\\n    emit DepositForPartyB(msg.sender, amount);\\n    emit AllocateForPartyB(msg.sender, partyA, amount);\\n}\\n```\\n
Any users or external protocols utilizing the `depositAndAllocateForPartyB` to allocate 1000 USDC will end up only having 0.000000001 USDC allocated to their account, which might potentially lead to unexpected loss of funds due to the broken functionality if they rely on the accuracy of the outcome to perform certain actions dealing with funds/assets.\\nFor instance, Bob's account is close to being liquidated. Thus, he might call the `depositAndAllocateForPartyB` function in an attempt to increase its allocated balance and improve its account health level to avoid being liquidated. However, the `depositAndAllocateForPartyB` is not working as expected, and its allocated balance only increased by a very small amount (e.g. 0.000000001 USDC in our example). Bob believed that his account was healthy, but in reality, his account was still in danger as it only increased by 0.000000001 USDC. In the next one or two blocks, the price swung, and Bob's account was liquidated.
```\\nFile: AccountFacetImpl.sol\\n    function depositForPartyB(uint256 amount) internal {\\n        IERC20(GlobalAppStorage.layout().collateral).safeTransferFrom(\\n            msg.sender,\\n            address(this),\\n            amount\\n        );\\n        uint256 amountWith18Decimals = (amount * 1e18) /\\n        (10 ** IERC20Metadata(GlobalAppStorage.layout().collateral).decimals());\\n        AccountStorage.layout().balances[msg.sender] += amountWith18Decimals;\\n    }\\n```\\n