Describe the bug Reported in 4624996-zen

The app icon has a badge with the number of orders with Processing status. This badge count doesn't update when changing an order's status (e.g. when fulfilling an order) within the app.

To Reproduce

1. Go to the Orders tab in the app.
2. Identify an order that needs processing.
3. Change the order’s status to something other than Processing.
4. Pull to refresh the Processing list. Notice that the badge count on the app icon doesn't change.

https://user-images.githubusercontent.com/35628116/146751474-bf66d443-8820-4204-a5f0-d5729525b1e2.mp4

Expected behavior I expect the badge count to update when the order status is changed.

Isolating the problem (mark completed items with an [x]):

• [ ] I have deactivated other plugins and confirmed this bug occurs when only WooCommerce plugin is active.
• [ ] This bug happens with a default WordPress theme active, or Storefront.
• [ ] I can reproduce this bug consistently using the steps above.

Mobile Environment I was able to reproduce this in SSP with:

• Device: iPhone SE
• iOS version: 15.2
• WooCommerce iOS version: 8.1

Sentry Issue: WOOCOMMERCE-IOS-8B

EXC_BREAKPOINT: Fatal error
  File "GridiconsGenerated.swift", line 418, in GridiconType.icon.getter
  File "Gridicons.swift", line 48, in Gridicon.generateIcon
  File "<compiler-generated>", in Gridicon.generateIcon
  File "<compiler-generated>", in @callee_guaranteed
  File "<compiler-generated>", in @callee_guaranteed
...
(93 additional frame(s) were not displayed)

Sentry issue: WOOCOMMERCE-IOS-8B

As of June 22, 2020:

• 57 events
• 11 users affected

First seen on 4.4.

Describe the bug Related to https://github.com/woocommerce/woocommerce-ios/issues/678

Basically if we log in and the sites are not accessible for some reason - it isn't possible to log out and log in as a different user which makes the troubleshooting workflow difficult (the only way is to re-install the app).

To Reproduce Steps to reproduce the behavior:

1. Log in as a user with connection issues (one of examples - 1924167-zen)
2. It isn't possible to log in as a different user and we're "trapped" on site choice screen

Expected behavior I'd hope to be able to log in as a different user if I'm unable to access a site as this particular user. Not sure if that's the best flow for regular users but this would definitely make troubleshooting easier as we wouldn't have to re-install the app to access a different account.

Isolating the problem (mark completed items with an [x]):

• [x] I have deactivated other plugins and confirmed this bug occurs when only WooCommerce plugin is active. Not applicable
• [x] This bug happens with a default WordPress theme active, or Storefront.
• [x] I can reproduce this bug consistently using the steps above.

Mobile Environment Please include:

• Device: iPhone SE
• iOS version: 12.1.2
• WooCommerce iOS version: 1.4

WordPress Environment

Ref: #250

This PR adds UI elements and logic to present Shipment Tracking in the OrderDetailsViewController.

At this moment, even though this PR includes the code to integrate with Yosemite to fetch tracking data, the data presented on screen is mocked until I figure out why that integration is not working (for me) as expected. ( p1551246523204900-slack-C6H8C3G23 )

Testing

As mentioned, at the moment the shipment data is mocked. Also, shipment data will be presented only for fulfilled orders, pending further discussion ( p1551231496200300-slack-C6H8C3G23 )

• Make sure you have a fulfilled order with one (or more) tracking numbers:

• Check out the branch
• Navigate to Orders > The order setup with tracking. Notice if mock tracking data is presented:

• Tap the "Track package" button for the HK Post entry. It should present a web view with http://automattic.com
• Tap the "Track package" button for the USPS Woo entry. It should present a web view with http://woocommerce.com

Mock data will be removed and testing instructions will be updated when this PR is ready for its final review

For Home Screen M1/M2 screenshots pdnsEh-6N-p2

Description

To prepare for the Home Screen M1/M2 release, we'd like to update our App Store screenshots. There has been bunch of changes that affect the screenshots test since the last update in October 2021, especially on new actions that the mock stores haven't implemented.

Major changes include:

• Implemented necessary actions in MockAppSettingsActionHandler and MockStoresManager with updated indentation on switch cases. load* actions are often needed for UI to work properly
• Previously, the stats only work for one month like in the first screenshot in the last update. This PR updated how we generate visitor and order stats mock data in ScreenshotObjectGraph so that the chart shows data for all 12 months of the current year
• A recent change on the Reviews tab shows the navigation bar button conditionally (https://github.com/woocommerce/woocommerce-ios/issues/4295), while ReviewsScreen expects the button to show. This PR updated to add an accessibility identifier to the reviews table view and expects the table view to show instead
• After running the screenshots test a few times, I ran into an error where the reviews table keeps changing data and show many duplicate reviews (you can also see this duplication issue in the 5-dark-review-list screenshot in the last update). This PR fixed the issue by deleting all reviews before saving mock reviews

Testing instructions

• In Xcode, switch to WooCommerceScreenshots target
• Run all tests in this target --> the screenshots UI test should run (going to the screens in the example screenshots) and pass in the end

Screenshots

1-dark-order-dashboard | 2-dark-order-list | 3-dark-order-detail | 4-dark-order-search -- | -- | -- | -- | | |

5-dark-review-list | 6-dark-review-details | 7-dark-product-list | 8-dark-product-details -- | -- | -- | -- | | |

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Fixes #2643 Fixes #2654

• [x] Make sure WordPressAuthenticator PR is merged: https://github.com/wordpress-mobile/WordPressAuthenticator-iOS/pull/373

There are design changes in this PR now that we're also using the prologue screen from WPAuthenticator. We're updating the design of the empty store screen per p91TBi-38l-p2#comment-1534, so the design changes in this PR are likely just for release 4.9. We originally wanted to target this for 4.8, but there are two new strings and we've passed the translation window for 4.8 so Aaron thought it'd be nicer to just target develop for 4.9.

Changes

• Enabled SIWA in project's "Signing & Capabilities" tab
• Updated WordPressAuthenticator pod to include the changes to enable customizations of the prologue screens in this PR
• In AppDelegate, in case the app presents the empty stores screen when it remembers the last login, added storePickerCoordinator?.onDismiss to display the authenticator login flow when the user taps to try with another account
• Added a new semantic color authPrologueBottomBackgroundColor, and updated the styles in AuthenticationManager for the prologue screens now that we're reusing the screens in the authenticator library. Our current design has the same colors for the bottom buttons container UI in both light and dark mode so we're passing the colors in light mode (previously, we forced the bottom buttons container UI to be light mode only). https://github.com/woocommerce/woocommerce-ios/blob/74d9f5b92b55fc9fa51336e4d72e1d3c0831bcf7/WooCommerce/Classes/Authentication/Prologue/LoginPrologueViewController.swift#L120-L123
• In AuthenticationManager, also passed in our LoginPrologueViewController to be the child view controller of the prologue top container view. Some more options are updated/added to support the prologue screens without sign up UX and with SIWA enabled. The code to display authentication was updated to show the sign in flow from WPAuthenticator library.
  • Sign up is a special case for SIWA, since the backend creates a WP.com account for the user if there's no WP.com account linked to the Apple ID yet. In this case, we sync the credentials and present the store picker screen (likely empty).
• Removed the Log In CTA at the bottom from LoginPrologueViewController, and updated the colors to use the new semantic color authPrologueBottomBackgroundColor
• Updated EmptyStoresTableViewCell - however, this cell will be removed when we implement the updated design soon (p91TBi-38l-p2#comment-1534) since it doesn't work in the new design anymore.
• Added func restartAuthentication() to StorePickerViewControllerDelegate when the user taps to try signing in with another account from the store picker screen (restarting the auth process). Implemented this in StorePickerCoordinator to dismiss the controller based on how it's presented in the first place in showStorePicker.
• Removed unused outlets/views in StorePickerViewController and its xib, and presented the Jetpack setup webview when the user taps on the "Connect the store with Jetpack" CTA
• Updated unit tests

Testing

• Log out from the store
• Tap on the Log In button --> should see a sheet with 3 sign in methods: WP.com, Google, and Apple. There is also a link below to enter site address first. Make sure the event login_prologue_jetpack_login_button_tapped is fired in the console as well.
• Make sure each login method works, especially the Apple one

Example screenshots

Prologue screen

\ | light | dark -- | -- | -- develop | | PR branch | | PR branch - sign in sheet | |

Empty stores screen

light | dark -- | -- |

Update release notes:

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Describe the bug Text from one of the crashes:

Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (8) must be equal to the number of rows contained in that section before the update (7), plus or minus the number of rows inserted or deleted from that section (1 inserted, 7 deleted) and plus or minus the number of rows moved into or out of that section (0 moved in, 0 moved out).

Crash report: https://sentry.io/share/issue/63aa8ffcc1634d5da1c7c2c0f8155ac8/

To Reproduce Unsure of how to reproduce.

Expected behavior No crashes when orders list is updated.

Fixes #4544

Description

When editing a draft product we want to show a “Draft” label below the product image for consistency with the Android app:

Changes

| Draft products status | Other product status | |---------------------|-----------------| | | |

| Landscape View | |---------------------| | |

| Example of LTR screen & Localized strings | |---------------------| | |

I've added a new UILabel to ProductImagesHeaderTableViewCell.xib via the Interface Builder . Then within the ProductFormTableViewDataSource I'm performing a check to see if the product status is a draft, so this label will only be displayed if the product status is set to draft, no label will be shown otherwise.

I used existing styles that we use elsewhere in order to apply some sort of design, in this case using the same style as completed orders via applyStyle(for: .completed) seemed appropriate as fits the the style shown in the Android version of the app.

Work in progress:

• [x] In order to fit as close as possible the Android one, I need to style it further by adding inner padding and changing the text colour.
• [x] Move the new label cell configuration outside the Data Source.
• [x] Fix UI constraints
• [x] Test for localized strings
• [x] Test for dark mode
• [x] Move the .cell appearance-only config to be called from awakeFromNib() instead, as these do not depend on data updates.

Testing steps

• Create a new product, or edit any existing product.
• If the product is currently a draft , the draft label will appear below the image cell.
• In the top right corner, tap on "..." > Product Settings > Status
• Switching between different status will make the label appear only when draft is selected, and disappear on other statuses.

Update release notes:

• [ ] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Fixes #4579

Description

Currently the Order View, Order Details View, and Refund View show a positive price number when a negative price is set for the product.

As per this open issue we want to allow negative numbers, mainly due to plugins that rely on this in order to function properly, meaning that showing a positive or a zero price in the UI when this is actually negative is incorrect.

Changes

The problem comes from the Order initializer in ProductDetailsCellViewModel.swift, where we're setting positiveTotal, and positivePrice parameters to be absolute-numbers-only via the abs() method:

• Removed the abs() method from these parameters.
• Renamed the parameters from positiveTotal to total, and from positivePrice to price

The price shows as expected now:

Testing steps

1. A negative-priced product can be created via the website, the app currently does not allow to create negative-priced products.
2. Fill an order with negative-priced product/s
3. From the app: Tap on Orders > Order > See Order details

Work in progress / Questions:

• [x] At the moment is not possible to add a product with a negative price via the app, only the web. Created new bug report here: https://github.com/woocommerce/woocommerce-ios/issues/4692

Update release notes:

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Fixes: #3926 ⚠️ Includes changes from #4180, to be merged first. The actual changes are in f9b1ef5

This is the last cancellable to get rid of for #3926, and possibly the most controversial 😬

Yosemite, Core Data, and Combine

The existing implementation had an observeConnectedReaders action that the store hooked into the service, calling its completion block each time the connectedReaders publisher sent a new value.

All the other cancellables so far were created by actual actions (connect, discover,...) that would eventually complete, but in this case, the view models want to observe just the connected reader, detached from the connect and disconnect actions. Because of this, the responsibility to cancel that subscription would fall on these view models which want to be notified. When the user navigates away from settings, they would get deallocated and stop listening for changes.

One way to shoehorn this requirement into the existing architecture would be to have the action's callback return the publisher instead, but that feels like we're bending the architectures too much.

When I look at our documentation, it has this to say about actions:

Lightweight entities expected to contain anything required to perform a specific task. Usually implemented by means of Swift enums, but can be literally any type that conforms to the Action protocol.

Allowed to have a Closure Callback to indicate Success / Failure scenarios.

NOTE: Success callbacks can return data, but the "preferred" mechanism is via the EntityListener or ResultsController tools.

I would argue that "observing the connected readers" is not an action: it doesn't perform any task, so there's no result to send back to the caller.

However, any of the suggested alternatives (ResultsController or EntityListener) won't work, since they're both based on Core Data objects. Our architecture was clearly designed to leverage Core Data for all reads, and it doesn't accommodate any model that's not a managed object. Now we have a new Hardware target, where there is data that needs to flow upwards but not necessarily go through Core Data, and there's a gap in our architecture.

I believe the simplest solution for now, since there's a single use case, is for the view models to use the ServiceLocator to access the publishers on the CardReaderService directly. There is no perfect solution here, but without more than a single use case, adding extra layers of abstraction seems a bit much. If we start needing this more, maybe we can evaluate a better solution.

Sharing mocks for testing

I was stuck for a good while trying to figure out how to share MockCardReaderService from the YosemiteTests to the WooCommerceTests. I didn't find any good solutions but then I saw that MockCardReader was already present in both targets with slightly different implementations. I'm not proud of this, but I just did the same and copied that file to the WooCommerceTests target. I'd love to find a better solution for sharing mocks across targets/projects, but I don't have one yet.

To test

I used the V2 card settings with a simulated reader, and tried to hit many different configurations:

• Go to settings (should not be connected) > Connect to a reader > Disconnect > Go back
• Go to settings (should not be connected) > Connect to a reader > Go back
• Go to settings (should be connected) > Disconnect > Go back
• Go to settings (should not be connected) > Connect to a reader > Disconnect > Go back

Update release notes:

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Add product details bottom sheet for #2053

• [x] ⚠️ Update PR base to develop after https://github.com/woocommerce/woocommerce-ios/pull/2210 is merged ⚠️

This PR presents the more details bottom sheet with product categories that aren't set yet with the following logic so that each product category is either shown in the product form or the bottom sheet except for the price (always visible in the product form).

product category | when it's set (shown in the list view, not in the more details bottom sheet) -- | -- inventory | at least one the following is set: sku, stock quantity shipping | at least one the following is set: weight, length, width, height categories | product has at least one category short description | product's short description is not empty

Changes

• Added an extension helper to Optional where the type is String to determine whether the string is nil or empty
• Created ProductFormBottomSheetAction for each action that could be in the product form bottom sheet, along with the title and subtitle displayed in the bottom sheet row
  • Added an extension to determine whether the action is visible based on the product
  • Similarly, added an extension to determine whether a ProductFormSection.SettingsRow is visible based on the product
• Created ProductFormBottomSheetListSelectorCommand for rendering the bottom sheet list selector
• In ProductFormViewController, handled each bottom sheet selection by navigating to the edit screen based on the action; updated the more details CTA visibility when the product is updated
• Added a Product extension to determine whether shipping is enabled, and updated another existing use case in DefaultProductFormTableViewModel where we determine whether to show the shipping settings row
• Added unit tests

Testing

• Go to the Products tab
• Tap on a simple Product --> should see a "+ Add more details" CTA at the bottom; should only see rows that have non-empty data (as at the top of the PR description)
• Tap on the "+ Add more details" CTA at the bottom --> should see a list selector with actions to add more details that are missing
  • If the product is virtual or downloadable, the shipping row shouldn't be visible
• Tap on a row --> it should navigate to the corresponding edit screen
• Navigate back to the product form and repeat the above for each row

Example screencast/screenshots

Update release notes:

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Describe the bug A clear and concise description of what the bug is. Please be as descriptive as possible; issues lacking detail, or for any other reason than to report a bug, may be closed without action.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Screenshots If applicable, add screenshots to help explain your problem.

Expected behavior A clear and concise description of what you expected to happen.

Isolating the problem (mark completed items with an [x]):

• [ ] I have deactivated other plugins and confirmed this bug occurs when only WooCommerce plugin is active.
• [ ] This bug happens with a default WordPress theme active, or Storefront.
• [ ] I can reproduce this bug consistently using the steps above.

Mobile Environment Please include:

• Device:
• iOS version:
• WooCommerce iOS version:

WordPress Environment

Closes: #8574

Why

This PR takes care of showing notices when the generate variation process finishes. The variation process can finish with variations generated or without variations generated

Demo

https://user-images.githubusercontent.com/562080/211104839-6ae8263d-c398-4919-8643-c14bb5fb0f24.mov

https://user-images.githubusercontent.com/562080/211104855-88d68056-4d99-433f-acfa-2d9d1dd1bdc1.mov

Testing Steps

• Open a product that has variations left to generate
• Start the "Generate all variations" process
• After generation see that a notice indicating that variations were generated appears.
• Start the "Generate all variations" process again
• See that a notice indicating that there are no variations to generate appear.

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Closes: #8491

Why

This PRs shows a blocking loading indicator while variations are being fetched and created so the merchant is informed about what is going on.

How

• Update InProgressViewController to allow for a runtime update.
• Update ProductVariationsViewController to show and hide the "Fetching..." and "Creating..." blocking indicators.

Demo

https://user-images.githubusercontent.com/562080/211050999-90f5d38e-2623-4869-9165-d7dfcfe22b77.mov

Testing Steps

• Navigate to a variable product
• Make sure there are some variations to be created
• Start the "Generate All Variations" process
• See that proper loading indicators are being shown.

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Part of: #8566

Description

Testing instructions

Screenshots

• [ ] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.