App metafields undefined in customer account UI extension

Please list the package(s) involved in the issue, and include the version you are using
@shopify/app: 3.57.1
@shopify/cli: 3.57.1
@shopify/ui-extensions: 2024.1.1
@shopify/ui-extensions-react: 2024.1.1
Describe the bug
I've built a customer account extension for the customer-account.profile.block.render target and am testing it via the CLI's dev command. The extension renders fine but if I try accessing useApi().appMetafields it returns undefined. If I try using useAppMetafields() directly, an exception gets thrown within Shopify's code due to the metafields being undefined. I know the metafield is populated because I'm able to access it from a checkout UI extension.
Steps to reproduce the behavior:

Scaffold a customer account following the steps from the docs. I then edited mine to 1) remove the full-page extension (it was causing a TypeScript error) and 2) target a block on the profile page. I also added access to the metafield I need in the extension's TOML file. I then tried using both useApi().appMetafields and useAppMetafields() in the extension and logging the results.
Run yarn dev and navigate to the test page for the customer account extension.
See that the app metafields value is undefined when using useApi().appMetafields, and that an exception is thrown when using useAppMetafields().

Expected behavior
App metafields are successfully retrieved without error when using either useApi().appMetafields or useAppMetafields().
Screenshots
N/A
Additional context
This is my sample extension where I found this issue:
import {
  Banner,
  reactExtension,
  useApi,
} from '@shopify/ui-extensions-react/customer-account';
import { RenderExtensionTarget } from '@shopify/ui-extensions/customer-account';

const target = 'customer-account.profile.block.render' as RenderExtensionTarget;

export default reactExtension(target, () => <ProfileExtension />);

function ProfileExtension() {
  const { i18n, extension, appMetafields } = useApi();

  console.log(appMetafields);

  return (
    <Banner
      title={i18n.translate('welcome', { target: extension.target })}
    >
      {`Metafields ${appMetafields ? '' : 'not'} available`}
    </Banner>
  );
}

Adding to this: I recently discovered that it's possible to make GraphQL queries to the storefront API from within a customer account UI extension. I've verified that this works to retrieve store data (e.g. the store URL, since both useShop() nor useApi().shop return undefined in my profile extension). I figured to try including the metafield I need in the query as well; this works perfectly when making the request via Postman and returns the store URL and my metafield; however, in my profile extension, the metafield comes back as null. So, it seems pretty concrete now that metafields cannot be accessed within customer account profile blocks, but it's not clear if this is by design or is a bug – it'd be great to know which, because if it's by design we'll need to look for an alternative way to make data available to our extension.
Also adding a note that I have the metafield I'm attempting to access listed in the extension's shopify.extension.toml file like this:
[[extensions.metafields]]
namespace = "my-namespace"
key = "my-key"

so the issue shouldn't be caused by a permissions problem as far as I can tell.

Hi @andrewpye
Thank you for your ticket.
Sorry for the late response.

So, it seems pretty concrete now that metafields cannot be accessed within customer account profile blocks, but it's not clear if this is by design or is a bug

Yes, it is by design. In customer account ui extension, appMetafields and useAppMetafields standard APIs are only available on customer-account.order-status targets, not be available on other targets, like customer-account.profile. You can reference to the targets for their corresponding available standard api.

we'll need to look for an alternative way to make data available to our extension.

As you said, you can use customer account api to retrieve metafields, which is also the way we encourage developers to query metafields.

It also means taking an inconsistent approach between different extensions to achieve the same simple goal, making common code impossible to share between extensions that target different surfaces.

We acknowledge this is not a good experience for developers. We'll revisit our decision to prefer customer account API calls before the release of customer account ui extension to the general public

We're trying to develop an extension to be ready for customer account extension launch so if the API is going to change that's going to be inconvenient.

API is an ambiguous term. You can use two kinds of APIs to get metafields.

Standard js API, like appMetafields hook. Only exists on customer-account.order-status target now. Whether it will be available on other targets has not been decided yet, unfortunately.
Customer account graphql API. Reference. It is available on all targets, and Metafields query will always be supported on customer account graphql API in the future

In your case, I would suggest to use customer account graphql API, which could always supports metafields query. The code in the query could be wrapped and shared by different components.
Does this make sense to you?

It also helps simplify code reuse by having a consistent JS API across different extension surfaces 🙏

I see. We will revisit the decision before launching it to general accessibility.
@andrewpye  Thank you for your info. I will close this one. If you have other questions, feel free to open a new one. 🙇

@lihaokx sorry to reopen this, but I'm having difficulties with the GraphQL API. I was able to grab a shop metafield using the sample above. I now need to grab an app metafield. When I use the GraphiQL interface (run yarn dev then press g once it's running), I'm able to make a query like this:
query {
  shop {
    metafield(namespace: "my-namespace", key: "my-key") {
      value
    }
  },
  currentAppInstallation {
    metafields(namespace: "my-namespace", first: 10) {
      nodes {
        key,
        value
      }
    }
  }
}

and get a result back that includes both the shop and app metafields. However, when I use the same query in the customer-account.profile.block.render extension, I get a Field 'currentAppInstallation' doesn't exist on type 'QueryRoot' error. Is there some difference between the GraphQL schema available through GraphiQL and within the customer account UI extensions? Is it documented anywhere? Without being able to access the current app installation within the extension, is there any other way that I can retrieve an app metafield?

I am wondering how did you create your app metafield definition?

Our app has been using them for some time now, we create them from our back end via the GraphQL API:
mutation($metafieldsSetInput: [MetafieldsSetInput!]!) {
  metafieldsSet(metafields: $metafieldsSetInput) {
    metafields {
      id
      namespace
      key
    }
    userErrors {
      field
      message
    }
  }
}

These metafields are exactly what is needed to make app blocks conditionally visible (ref). We're using them for this purpose, and need the same condition available from our customer profile UI extension so that we can provide the same experience for stores using new customer accounts as we currently provide for stores using classic customer accounts. It seems likely that many app developers will have the same idea, so it seems strange to limit the data available to a customer profile UI extension so severely.
Is there any other way at all that I can retrieve an app-data metafield in a customer profile extension?

Thanks for the explanation @lihaokx, and apologies for misunderstanding your original question 🙈 As far as I know we've never explicitly created any metafield definitions – is that something that's new?

I am not sure what OwnerType of your metafields. On customer account API, we only support this 5 kinds of ownertype., (shop, customer, order, and company and companyLocation)

I'm unfortunately no expert on metafields in the Shopify ecosystem – all I can tell you is that we created the metafields we need following the Shopify documentation for app-data metafields (ref). That seems to suggest that the owner of the metafields is our app installation (we're passing the app installation ID as the ownerId on the metafields we're using) – but "app installation" doesn't even seem to appear in the OwnerType enum you've linked to here 😅 I'm sure you can appreciate that this is a confusing developer experience since something that's required for functionality to work in one part of an app, doesn't seem to even exist in another closely-related part of the app 😬

Oh. After checking with our team, unfortunately, the app-data metafield is not what is supported on customer account API. And the metafields supported on customer account api are listed here.
I am seeing there are some discussion here. Hopefully, it may be helpful.
AFAIK, app-data metafield is used to know how merchant install your app, like app plan. Would you like to specific more context about your use case of app-data metafield on customer account UI extension? So that I can bring back your idea to our team to see how can we support it in the future. Thank you so much. @andrewpye

app-data metafield is used to know how merchant install your app, like app plan. Would you like to specify more context about your use case of app-data metafield on customer account UI extension?

This is exactly what we're using it for. We currently have an app block which is built for the classic customer account page. It's restricted to merchants that are on a specific plan. We sync that availability to an app-data metafield as a boolean value, and the app block schema allows specifying an app-data metafield that defines whether the block should be available to the merchant. Now that customer account UI extensions are available, we're creating an extension to make this same feature available to merchants using new customer accounts, and as with the app block, the extension should only be available to merchants that are on a specific plan. Unless we're missing something, it isn't possible to make any kind of UI extension (checkout, customer account etc.) available conditionally to merchants – all merchants can see all extensions offered by an app. As a result, we're left to implement the "feature gating" ourselves. Since the feature availability is the same as our existing app block, it made sense to reuse the same flag for our new customer profile UI extension, which is what led to my earlier question. We can retrieve the feature availability from our own API when the extension initialises so we're not blocked here, but it was just a surprise that an app is unable to access its own metafields from within its UI extensions 🤷 Of course, it wouldn't even have been an issue if there were some mechanism available to app developers that allowed them to make UI extensions conditionally visible to merchants like we can do with app blocks...
Out of curiosity, is there a specific reason for app-data metafields not being available in customer account UI extensions?

Thanks for your reply. @andrewpye
Our team has been aware of this issue. We will revisit the decision to support app-data metafield.

Out of curiosity, is there a specific reason for app-data metafields not being available in customer account UI extensions?

Because customer account API only support these kinds of metafields, which do not include app-data metafields. I am wondering if you can achieve the same functionality of app-data.metafields by using shop.metafields on customer account API. Here is the idea, creating  a metafield definition when a store is installing your app by admin API, set it access customer_account read. Then, in customer account api, retrieve the metafields. You can reference to this link

I am wondering if you can achieve the same functionality of app-data.metafields by using shop.metafields on customer account API. Here is the idea, creating a metafield definition when a store is installing your app by admin API

Thanks for the suggestion @lihaokx! However, we've found syncing data from our system to metafields to occasionally cause problems (data getting out of sync when a metafield create/update operation fails or an operation before we create/update the metafield errors out). Since we already sync this value to one metafield, we don't really want to start syncing it to a second metafield just to workaround a limitation of the platform. Retrieving the value directly from our API via an HTTP request on initialisation works well enough for now.

Hi guys!
I need to fetch some app data metafields too (metafields with ownerId set to the app id). Will this be added on the customer account API in the future or should I migrate to shop metafields?
Thanks!

Thanks! @lihaokx
I give you a little bit of context.
I'm the developer behind Amplius, an app that let the merchants collect additional data that will be saved into metafields.
We also provide a form to put on the account page so the users can update their own additional data (using a theme extension block)
The fields that a user can update are decided by the merchant and saved inside an app-data metafield.
On the theme extension I can get the app metafields just by using {{ app.metafields.namespace.key.value }} but on the new customer account page I cannot
Migrating to shop metafields is not a problem for me, I also think it is more correct 👍🏻


Better handle cases where entire modules are conditionalized in chap/assembly files

Current behavior
Some modules/sections are conditioned, such as to apply for community but not enterprise, or vice versa.
For example, the following two modules in this DMN chap file apply to Kogito community docs but not to Kogito enterprise docs, and thus the two module sections in the chapter file are conditionalized accordingly with an ifdef before the first and an endif after the second:
ifdef::KOGITO-COMM[]

[id="ref-dmn-feel-enhancements_{context}"]
=== FEEL enhancements in {PRODUCT}

{PRODUCT} includes ...
...

[id="ref-dmn-model-enhancements_{context}"]
=== DMN model enhancements in {PRODUCT}

{PRODUCT} also includes ...
...

endif::[]

The expectation is that the above condition tags will be left in place in the converted assembly file surrounding the two converted module includes, as follows:
ifdef::KOGITO-COMM[]

include::ref-dmn-feel-enhancements.adoc[]

include::modules/dmn/ref-dmn-model-enhancements.adoc[]

endif::[]

Instead, what happens today is the following:

The starting ifdef is ignored entirely.
Both includes are included in the new assembly without the condition tags, so they are rendered in enterprise when they should be conditioned to not display in the rendering for enterprise. See lines 51 and 53 of the generated assembly, which should be surrounded by the Kogito community conditions but are not: https://gitlab.cee.redhat.com/red-hat-jboss-bxms-documentation/kie-docs-translator/-/blob/master-kogito/assemblies/assembly-kogito-using-dmn-models.adoc
The closing endif is retained at the end of the second file, the one that immediately precedes the closing tag. As a result, that stray endif breaks the build. See the stray endif on the last line of the second file: https://gitlab.cee.redhat.com/red-hat-jboss-bxms-documentation/kie-docs-translator/-/blob/master-kogito/modules/dmn/ref-dmn-model-enhancements.adoc

Target behavior
Retain all ifdef/endif conditions as they are, including condition tags that should surround a module include in the assembly file not just content in the module file.
This might be tricky because, how can the splitter know if an endif at the end of a module is the close of a condition that encapsulates the entire module and should thus be conditioned in the assembly file VS. just the close of conditioned content within that module and thus be conditioned within the module file? The answer to that determines whether to retain the conditions in the assembly (surrounding the includes) or within the module file.
Example, this is a condition to enclose the includes in the assembly:
ifdef::KOGITO-COMM[]

[id="ref-dmn-feel-enhancements_{context}"]
=== FEEL enhancements in {PRODUCT}

{PRODUCT} includes ...
...

[id="ref-dmn-model-enhancements_{context}"]
=== DMN model enhancements in {PRODUCT}

{PRODUCT} also includes ...
...

endif::[]

Whereas this is a condition to enclose just a portion within the module file:
[id="ref-dmn-model-enhancements_{context}"]
=== DMN model enhancements in {PRODUCT}

{PRODUCT} also includes ...

ifdef::KOGITO-COMM[]
And also does some community stuff.
...

endif::[]

Note how in both cases the second file ends with an endif exactly the same way. Asciidoc doesn't have any trouble because it tracks back to the start ifdef tag wherever it is and removes it out regardless.
So is there a way for the splitter to detect whether to condition out entire modules and retain the ifdefs in the assembly vs. condition out module content and retain the ifdefs only in the module file? It seems to struggle with that today.
Resources

Source repo and branch used: https://github.com/kiegroup/kie-docs/tree/master-kogito
Target repo and branch used: https://gitlab.cee.redhat.com/red-hat-jboss-bxms-documentation/kie-docs-translator/-/tree/master-kogito/
Splitter command used:

target/asciidoc-splitter-1.0-SNAPSHOT-bin/bin/asciidoc-splitter.sh -sr git@github.com:kiegroup/kie-docs.git -sb master-kogito -or git@gitlab.cee.redhat.com:red-hat-jboss-bxms-documentation/kie-docs-translator.git -ob master-kogito -i index.adoc

Please provide test case. I thought I had conditionals figured out.

As discussed in chat, you should have all the info and links that you need above to create a branch or download the zip for a test case.

 Have to think on this a lot more. The way things are done both within asciidoctor and what I've done in the splitter don't make this easy.


Navigate back to the most recent report if parent report doesn't exist when deleting task

Details

When we delete a task but the parent report doesn't exist, we navigate to a not found page. This PR fix it.
Fixed Issues

$ https://github.com/Expensify/App/issues/45474
PROPOSAL: https://github.com/Expensify/App/issues/45474#issuecomment-2230990214
Tests

Same as QA Steps

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

Offline tests

Same as QA Steps
QA Steps

As user A, create a group chat without user B
Create a task in the group and assign it to user B
As user B, open the user A chat and open the task details
Click on header and delete the task
Verify you are navigated back to the user A chat

[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/user-attachments/assets/bee55d68-f5a6-4e0b-95b3-d3d4d28deb8e

Android: mWeb Chrome

https://github.com/user-attachments/assets/7597e702-82c9-491d-9a35-a179868599d2

iOS: Native

https://github.com/user-attachments/assets/8074d17d-b2ff-46fd-8af4-e15161fc1741

iOS: mWeb Safari

https://github.com/user-attachments/assets/628fe871-c407-4d72-a123-6073592bbfd2

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/f6f3d6cc-e44e-41b8-95f0-d0d85bb16f1c

MacOS: Desktop

https://github.com/user-attachments/assets/0c6cd857-07ca-4e6b-b3e9-fb3fcc0a6d9a

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/user-attachments/assets/ab685b10-1d30-4a25-831a-8ac5334d3cd2

Android: mWeb Chrome

https://github.com/user-attachments/assets/cf55af87-e7aa-4777-97e7-72298a2a7a3f

iOS: Native

https://github.com/user-attachments/assets/1786b8aa-d7b6-4ec1-abef-5d29b273a919

iOS: mWeb Safari

https://github.com/user-attachments/assets/8e008620-5577-4e3e-bfc0-e680cbfa48b4

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/3e20376b-f98c-41ce-987e-69c90377d09a

MacOS: Desktop

https://github.com/user-attachments/assets/6e6714bb-81fc-4624-b1ba-157fa15e7087

Anywhere like?

: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/MonilBhavsar in version: 9.0.19-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
failure ❌

🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 9.0.19-4 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
failure ❌

🕸 web 🕸
failure ❌

🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 9.0.19-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 9.0.20-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

FYI I believe this was deployed to prod yesterday, from this checklist - #47356


Amplify 10.6.1 breaks schema.graphql comment syntax

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
14
Amplify CLI Version
10.6.1
What operating system are you using?
Linux
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
Nope
Describe the bug
Prior to Amplify 10.6.x, schema.graphql comments were allowed to be inline
e.g., this was valid:
  idField: ID! # @index(name: "someIndexName", queryField: "queryFieldName")

... obviously, the comment was ignored/no index was created.
In Amplify 10.6.x, this now causes failures when you run any of the following:
amplify api gql-compile
amplfiy mock api
amplify push
The error is
🛑 Syntax Error: mismatched brackets found in the schema. Unexpected ) at line <number> in the schema.
Expected behavior
Comment semantics are not changed.
Reproduction steps
Create a toy schema
Add in the field I have provided above
Note that gql-compile fails.
Project Identifier
No response
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

+1


Urgent question

Hello, who or where did you get the Ryanair 737-700 livery from?
I am the creator of that livery, and I DID NOT give anyone permission to use it.
Thanks

Thanks, I fixed your China Eastern and Ethiopian textures for this addon.

Yw! feel free to reach out with any questions you may have.

Thanks for your kind help. There might be some around the new aircrafts yet to come. Its good to see what a big project, and great community grew out in the last weeks. And it only started with my blurry imagination to put every liveries together and about twenty lines of code that played in the first round.

This is false. I am the author of the 737-700 Ryanair livery in my livery changer addon. It was the first livery feature. There is a 737 max ryanair livery in multiliveries that I did not make, though. If you are using IUH's modification, i am not sure how many original files are still intact so just be aware.
Also, You're absolutely free to use my code and textures, they're open-source for a reason lol.

Sorry for not being clear, I was talking about a different Ryanair livery that I made. It is shown in this video: https://youtu.be/3i5sZOgSG8U
I do believe it was in IUH’s liverychanger for some time

This is false. I am the author of the 737-700 Ryanair livery in my livery changer addon. It was the first livery feature. There is a 737 max ryanair livery in multiliveries that I did not make, though. If you are using IUH's modification, i am not sure how many original files are still intact so just be aware.
Also, You're absolutely free to use my code and textures, they're open-source for a reason lol.

Sorry for not being clear, I was talking about a different Ryanair livery that I made. It is shown in this video: https://youtu.be/3i5sZOgSG8U
I do believe it was in IUH’s liverychanger for some time

Nevermind, i made a new one yesterday, so i think now it's ok fot everybody

This is false. I am the author of the 737-700 Ryanair livery in my livery changer addon. It was the first livery feature. There is a 737 max ryanair livery in multiliveries that I did not make, though. If you are using IUH's modification, i am not sure how many original files are still intact so just be aware.
Also, You're absolutely free to use my code and textures, they're open-source for a reason lol.

Sorry for not being clear, I was talking about a different Ryanair livery that I made. It is shown in this video: https://youtu.be/3i5sZOgSG8U
I do believe it was in IUH’s liverychanger for some time

Ah i see, yeah i didn't make that one. thx for clarifying


Data controls

Merging data controls into the sort-of-main branch.
Data controls: Let's say we have a Tableau viz that shows data for a given academic peroid (Fall 2014, Spring 2015, Summer 2015, etc.). We want to provide a drop-down menu so the user can select a period to view. Doing this within Tableau is possible, but has a number of problems if you want the list to be dynamic (when a new academic period is added to the DB, it pops up in the list without anything having to be manually changed).
Data controls are a solution to this. We pull a list of values from the database and show them as a drop-down menu or a set of buttons. When the user makes a selection, it gets passed in to the viz as a parameter value.
Each data control contains a SQL query which pulls the list of options. Options will be displayed in the order they are returned. The name of each column must match the parameter name in the viz - if your column is named "Academic Period", then the viz should have an "Academic Period" parameter. If you have multiple columns, you will get dependent drop-downs. For instance, if your first column is "College" and your second is "Department," making a selection from "College" will update the options in "Department," and the control will pass in both "College" and "Department" to the viz whenever you change either one.
(You can use buttons for multi-parameter data controls, but I don't recommend it. It'll be a mess.)
If you want to have labels on columns that are different from the values - e.g., you want "Fall 2015" in the drop-down to send the value "201510" to the viz - you can do it with a label column. This is a column with "_label" at the end of the name:
[Academic Period] --> 201510
[Academic Period_label] --> Fall 2015
Finally, you can include an [is_default] column, which should contain 1 or 0. The first row with is_default = 1 will be the default option; when the data control first loads, that option will be preselected.
You can use the :user_name parameter in your data control SQL, and the portal will pass in the NetID of the current user. If you include <SOURCE_VIEW>, it will be replaced by the source_view property of the report it's attached to. This is useful if you have a data control that's going to be used on multiple reports, each one pulling from a different table in the DB.
In future, we will probably want to be able to use data controls on datasets as well. However, this functionality is not implemented as of this pull request.

Rejecting due to colossal Git mess. See https://github.com/ndoit/fenrir/pull/68/files?w=1 instead.


creating-teams.md to creating-teams.rst

Convert to RST
Updates based on style guide
Clarify methods to create a team

+1

+1


Support additional load paths

Hi there,
This is a proposal implementation for #28

Rebased to get the fix for FunctionalTest

This looks good to me, but I'm not sure how we can rebuild it to see if tests pass.

Hi! Is there something I can do here to help?


Error on Internet Explorer 11

I am getting the following error on Internet Explorer 11
My app runs fine on all other browsers ...
What could be the problem?
SCRIPT 438: Object doesn't support property or method 'assign'
152 (359,2)

Leading to the file: vuex-i18n.es.js
// merge default options with user supplied options
              var mergedConfig = Object.assign({
                           moduleName: 'i18n',
                           identifiers: ['{', '}'],
                           preserveState: false,
                           onTranslationNotFound: function onTranslationNotFound() {}
              }, config);

Hi @Zambiorix
Object.assign is an es6 method that is not directly supported by IE 11. It is usually converted or polyfilled with babel when the code is compiled in webpack. You probably need to update your configuration for babel to specify which browsers to target.

I added this simple test:
const object1 = {
  a: 1,
  b: 2,
  c: 3
};

const object2 = Object.assign({c: 4, d: 5}, object1);

console.log(object2.c, object2.d);
// expected output: 3 5

import Vue from 'vue'
import Vuex from 'vuex'
import VuexI18n from 'vuex-i18n'
Vue.use(Vuex)
Vue.use(VuexI18n.plugin, new Vuex.Store())

And indeed the assign seems to work, but still I get an error in vuex-i18n that assign is missing
I also installed:
npm install --save-dev babel-plugin-transform-object-assign
And this is my babelrc
{
  "presets": [["es2015", {"modules": false}], "stage-2"],
  "plugins": ["transform-runtime", "transform-object-assign"],
  "comments": false
}

I have no idea what else I can do :-(

Could you please post your webpack config file. It could be possible that the vuex-i18n module is not compiled with babel, since it is in the node_modules folder.
Alternatively you could try to use the import VuexI18n from 'vuex-i18n/dist/vuex-i18n.umd.js'; which contains a pre-transformed version.

import VuexI18n from 'vuex-i18n/dist/vuex-i18n.umd.js'
Didn't change anything...
This is the babel-loader part of my webpack config (I am using Quasar framework 0.14):
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: ['/node_modules/vuex-i18n/',projectRoot],
        exclude: /node_modules/
      },

Originally the '/node_modules/vuex-i18n/' include part was not there, but I tried to add it to see if it works. It doesn't :-(
I must exclude node_modules or the project does not build. Any other way to solve this?
(I really appreciate your help, btw ;-)

Ok .. I solved this temporarily by moving the vuex-i18n.es.js file to my own project until I find a better solution..
(I have a deadline tomorrow 8am to have my project running :-)
Thanks for helping out!

I hope you can make your deadline tomorrow. I get the feeling. The last thing that you need then is to worry about some package in your pipeline that acts up.
So, I take it that moving the vuex-i18n.es.js file directly into your project solved the problem. To me, this would really point towards a problem in the configuration of the compilation pipeline.
I would suggest to try to use path.resolve to match the directory name of vuex-i18n. Additionally it might be better not to use exclude together with the include directive. However, this would require the node_modules folder to be not in the same directory as your main application code.
We usually structure our frontend directory like this
+ app (DIR)
+ node_modules (DIR)
- .babelrc
- .eslintrc
- package.json
- webpack.config.js
- yarn.lock

// in webpack.config.js
var appDirectory = path.resolve(__dirname, 'app');
var vuexI18nDirectory = path.resolve(__dirname, 'node_modules/vuex-i18n');
// ...
{
  test: /\.js$/,
  loader: 'babel-loader',
  include: [appDirectory, vuexI18nDirectory]
},

Without touching the rest of the build configuration, I just added 1 extra webpack rule.
It all works now...
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: projectRoot,
        exclude: /node_modules/
      },
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: path.resolve(__dirname, '../node_modules/vuex-i18n/')
      },

Thank you for following up on this.

In vue-cli you have to add 'vuex-18n' to transpileDependencies in vue.config.js
module.exports = { 	transpileDependencies: ['vuex-i18n'] }

why not use object-assign to adapter ES5?
As a library,it should not need user hack to much.
BTW, are you using vux, I have same problem with like you.But this problem appear in Android WebView  @Zambiorix


MongoError: server instance pool was destroyed

Hey,
I am running the bot over kraken however when the bot is going to buy/sell. I am getting this error and no effective trades.   Do you feel your issue is resolved?  Please consider closing it.

Closing, it's cheap to re-open.

the having the same issue, can be reopened? here my error:
2018-05-03 23:45:03 - error saving session
{ MongoError: server instance pool was destroyed
at basicWriteValidations (zenbot/node_modules/mongodb-core/lib/topologies/server.js:641:41)
at Server.update (zenbot/node_modules/mongodb-core/lib/topologies/server.js:781:16)
at Server.update (zenbot/node_modules/mongodb/lib/topologies/topology_base.js:326:25)
at updateDocuments (zenbot/node_modules/mongodb/lib/collection.js:1023:19)
at save (zenbot/node_modules/mongodb/lib/collection.js:1273:12)
at executeOperation (zenbot/node_modules/mongodb/lib/utils.js:420:24)
at Collection.save (zenbot/node_modules/mongodb/lib/collection.js:1260:10)
at /home/cryptowisebot/zenbot/commands/trade.js:611:22
at /home/cryptowisebot/zenbot/lib/engine.js:240:9
at /home/cryptowisebot/zenbot/lib/engine.js:309:7
name: 'MongoError',
message: 'server instance pool was destroyed' }


Add 'isAnimated' property on Modal

Does this fix a particular issue or is it in support of something else?

Not Something special. Tiding up same checks, that are written in different ways


Fix TravisCI failures

closes https://github.com/masutaka/compare_linker/pull/35
I fixed the problem that spec failured on only TravisCI. See also https://github.com/masutaka/compare_linker/pull/35

It seems that the TravisCI result is correct, the macOS one is wrong. :cyclone:

Gem::Version#initialize https://github.com/ruby/ruby/blob/v2_5_1/lib/rubygems/version.rb#L202-L216

Gem::Version#correct? https://github.com/ruby/ruby/blob/v2_5_1/lib/rubygems/version.rb#L169-L174


Create CODEOWNERS

according to the "files changed tab" there is an error

oh sorry I saw you fixed it already


Dynamic Params breaks with Strings

The dynamic params has support for strings but this doesn't function properly. Looking at the code, it appears to reference strings as bools (most likely a copy paste error).

Fixed in #553.


Improve accessibility for the example question page

This PR includes the recommendations from Léonie to create an association between the form hint and the form fields and use a more realistic field range for year of birth
Hints.
The hints provided for some fields are not programmatically associated with
their form fields. This means that as a screen reader user tabs through the
form, the hint information is not automatically announced. For example:

For example, 31 3 1980

...
Day
<input class="form-control" type="number" max="31" min="0" pattern="[0-9]*" name="dob-day"
id="dob-day">

Recommend using aria-describedby to create the association. This will cause
screen readers to announce the hint (after they announce the legend and/or
form label for the field).
For example:

For example, 31 3 1980

...
Day
<input type="number" max="31" min="0" pattern="[0-9]*" name="dob-day"
id="dob-day" class="form-control" aria-describedby="dobHint">

Field range.
The range for the DOB year is 0 to 2014. For someone using a keyboard to
spin through the range this equates to a lot of key presses. It is possible
to type a number directly into the field, but even so the extent of this
range seems too much.
Recommend using a more realistic range (especially for a DOB), perhaps 1910
to 2014.

Closing for now, until the issues raised on the corresponding PR for govuk elements have been resolved.


Register SharePoint add-ins with ACS. How long will this stay supported?

According to the new note on this page registrering a new ACS account is now being put behind a new security option.
We are still using ACS for some remote event receivers we build on SharePoint online. Webhooks don't offer the sync events. Will ACS continue to be a supported way of creating an ad-in or will this be deprecated in the near future?
Site collection admin is not able to register add-in with Azure ACS in AppRegNew.aspx by default unless explicitly allowed by the SharePoint tenant admin. For more information, see [Set-SPOTenant](https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/set-spotenant#-siteownermanagelegacyserviceprincipalenabled).

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 2be8c8d6-7ed2-1907-3038-49d8e1c92e8a
Version Independent ID: a2adbe13-e625-3995-fded-fce6c4a701ac
Content: Register SharePoint Add-ins
Content Source: docs/sp-add-ins/register-sharepoint-add-ins.md
Service: sharepoint
GitHub Login: @VesaJuvonen
Microsoft Alias: vesaj

ACS will be indeed deprecated in near future as the Azure AD should be used for the app registrations. Deprecation means that we will openly communicate that we are no longer investing on the ACS and we will provide a reasonable end of life for the ACS, so that there's enough time to transition. What's reasonable? >18 months minimum.
We have been delaying the deprecation announcement now for a while, but it's expected to happen by end of 2023 calendar year.

There are issues when adding RER's to SharePoint online that connect with an Enterprise Application.
https://github.com/pnp/powershell/issues/3169
Ading them requires a user account or an App created via AppRegNew. Thats why we still use ACS.
Does this mean RER will be unsupported to? Webhooks can do some but no sync events

@VesaJuvonen, do you have any feedback about remote event receivers support for SharePoint online? Will this also be deprecated? If so we need to rethink our migration strategy.

Does someone else, beside @VesaJuvonen have any idea if remote event receivers will continue to work in the future? I can't find any guidance on this. I my discussion on SharePoint stack exchange (https://sharepoint.stackexchange.com/questions/309639/what-is-the-future-for-remote-event-receivers-for-sharepoint-online/) I learned that when using Webhooks or Power Automate remote event receivers registrations are used to connect to the SharePoint list. So is this tech still being supported or should I step away from the remote event receivers?

MC693865 · Provider Hosted Apps Retirement
Will impact al the RER that were registered using the app...
Since the release of SharePoint Add-Ins in 2013, Microsoft has evolved SharePoint extensibility using SharePoint Framework (SPFx) enabling you to write applications that can be used in Microsoft SharePoint, Viva Connections and Microsoft Teams. With our continued investment in SharePoint Framework, Microsoft is retiring SharePoint Add-Ins.
Key Points:
Major: Retirement
Timeline:
Starting July 1st, 2024, SharePoint Add-Ins cannot be installed from the public marketplace, also referred to as store by existing tenants. Installation from a private tenant catalog stays possible.
Starting November 1st, 2024, new tenants will not be able use SharePoint Add-Ins, regardless of their origin (public marketplace, private tenant catalog).
Starting April 2nd, 2026, Microsoft will remove the ability use SharePoint Add-Ins for existing tenants.
There will not be an option to extend SharePoint Add-Ins beyond April 2nd 2026.
 We recommend customers to port their customizations to SharePoint Framework (SPFx) and ask their solution vendors for updated solutions.

@imorrish Your reply, while useful, does not answer the question. Has there still not been a concrete announcement regarding RER ?

I am able to create a RER that uses an Azure App Registration and authenticates using a certificate. This works without ACS. I only want to know if event firing for remote event receivers will stay in place

This will work in a user context.
When you add the event receiver to eg. a list using access tokens from an Azure app it will not fire, until you've added the app to SharePoint using /appinv.aspx. This is because the event receiver needs to be run in the context of an ACS user(as far as I understand). See here for more info: https://github.com/pnp/powershell/issues/464
(Adding the RER as a user is also problematic because if the user is disabled they will stop working, and only that user is able to edit/remove the RER)
RER is also connected to ACS in that if you register it as an app using AppRegNew, then upon triggering it will pass you a Context token that you can consume in ACS to generate an on behalf of token(delegated), for the user that effected the change.
Looking at the migration guide (https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins-modernize/sp-add-in-modernize) for the ACS retirement post there is also a point about RER to webhooks.
Based upon this i believe that RERs are getting removed, but looking for a definitive answer. I'll register a support ticked with MS and keep you informed

Take it we out of luck if we need synchronous event handling beyond April 2026? this is widely used and webhooks are not an alternative.

This will work in a user context. When you add the event receiver to eg. a list using access tokens from an Azure app it will not fire, until you've added the app to SharePoint using /appinv.aspx. This is because the event receiver needs to be run in the context of an ACS user(as far as I understand). See here for more info: pnp/powershell#464 (Adding the RER as a user is also problematic because if the user is disabled they will stop working, and only that user is able to edit/remove the RER)
RER is also connected to ACS in that if you register it as an app using AppRegNew, then upon triggering it will pass you a Context token that you can consume in ACS to generate an on behalf of token(delegated), for the user that effected the change.
Looking at the migration guide (https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins-modernize/sp-add-in-modernize) for the ACS retirement post there is also a point about RER to webhooks.
Based upon this i believe that RERs are getting removed, but looking for a definitive answer. I'll register a support ticked with MS and keep you informed

I have tested on my tenant and what I see is that using an Azure AD app with sites.Selected permissions enables us to create a RER which fires without ACS.
We took these steps:

Create an Azure AD app with sites.selected permissions on SharePoint api
Create a certificate and add to the app
Add fullcontrol permissions for the app with Grant-PnPAzureADAppSitePermission on my site collection
Log in with PnP.PowerShell using Connect-PnpOnline [tenant.sharepoint.com] -ClientId [clientid] -CertificatePath c:\temp\certs\test.pfx -CertificatePassword $password -Tenant '[mytenant].onmicrosoft.com'
Add a RER to my list using Add-PnPEventReceiver
Host the RER locally using devtunnel or Ngrok

We see the RER firing after this. I can manipulate the item, execute other logic and return a SPRemoteEventResult
The only thing I am worried about is a error message in the request headers:
"The app i:0i.t|ms.sp.ext|[clientid]@[TenantID] does not have an endpoint or its endpoint is not valid"
It seems to me this is not running in a user context. So will this work?

@waaromikniet I've also noticed this. I believe the New-MgSitePermission/Grant-PnPAzureADAppSitePermission creates an ACS user for your SharePoint app.
The error message in the header is because this is not an ACS app registered through /_layouts/15/appregnew.aspx. In There you can setup AppDomain, and if you add an event receiver in the context of this app, where the url to the RER matches the Appdomain, you will get a Token you can use to work on behalf you the triggering user(bit unstable, not always working)
I don't know if it will work after ACS retirement, but I have a hunch that this will probably stop working.
I'm still in the process of getting an answer from Microsoft support, so far every support ticket I've registered has been answered with I need to register a new ticket in another place. Hopefully I can an answer soon

@waaromikniet I've heard back from Microsoft Support. RER events are getting retired. See response below:
Hello xxxx,
Hope you are doing well.
Thank you for your response. we have checked on the backend and found the below details for reference. you can refer the below details. I hope this will help you regarding your query.
Yes, remote event receivers are expected to be retired in April 2026 alongside the deprecation of Azure Access Control Service (ACS). As remote event receivers rely on ACS for authentication, they will no longer function once ACS is turned off.
Here's what you need to know:
Timeline:
•	November 27, 2023: SharePoint Add-in model is retired. This means no new investments will be made in the model, but existing add-ins will continue to be supported.
•	April 2026: Azure ACS is retired, leading to the retirement of remote event receivers.
Impact:
•	Apps relying on remote event receivers will no longer receive notifications about events in SharePoint.
•	Synchronous events, which allow apps to block or cancel SharePoint actions, will no longer be possible.
Alternatives:
•	Microsoft Graph Change Notifications: These notifications provide a modern alternative to remote event receivers. They offer asynchronous notifications and support for various SharePoint entities.
•	SharePoint Online Webhooks: These webhooks are another alternative to remote event receivers. They offer a REST-based approach for subscribing to SharePoint events and receiving notifications.
Recommendations:
•	Migrate existing remote event receivers to Microsoft Graph Change Notifications or SharePoint Online Webhooks as soon as possible.
•	Plan your migration carefully to minimize disruptions.
•	Consider using the SharePoint Framework for new development instead of the retired Add-in model.
Here are some resources to help you with the migration:
•	Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks: https://learn.microsoft.com/en-us/sharepoint/dev/apis/webhooks/get-started-webhooks
•	SharePoint REST API for Webhooks: https://learn.microsoft.com/en-us/kaizala/connectors/webhooks
•	Microsoft Graph Change Notifications: https://learn.microsoft.com/en-us/graph/api/resources/webhooks?view=graph-rest-1.0

@waaromikniet I've heard back from Microsoft Support. RER events are getting retired. See response below:
Hello xxxx,
Hope you are doing well.
Thank you for your response. we have checked on the backend and found the below details for reference. you can refer the below details. I hope this will help you regarding your query.
Yes, remote event receivers are expected to be retired in April 2026 alongside the deprecation of Azure Access Control Service (ACS). As remote event receivers rely on ACS for authentication, they will no longer function once ACS is turned off. Here's what you need to know:
Timeline: • November 27, 2023: SharePoint Add-in model is retired. This means no new investments will be made in the model, but existing add-ins will continue to be supported. • April 2026: Azure ACS is retired, leading to the retirement of remote event receivers. Impact: • Apps relying on remote event receivers will no longer receive notifications about events in SharePoint. • Synchronous events, which allow apps to block or cancel SharePoint actions, will no longer be possible. Alternatives: • Microsoft Graph Change Notifications: These notifications provide a modern alternative to remote event receivers. They offer asynchronous notifications and support for various SharePoint entities. • SharePoint Online Webhooks: These webhooks are another alternative to remote event receivers. They offer a REST-based approach for subscribing to SharePoint events and receiving notifications. Recommendations: • Migrate existing remote event receivers to Microsoft Graph Change Notifications or SharePoint Online Webhooks as soon as possible. • Plan your migration carefully to minimize disruptions. • Consider using the SharePoint Framework for new development instead of the retired Add-in model. Here are some resources to help you with the migration: • Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks: https://learn.microsoft.com/en-us/sharepoint/dev/apis/webhooks/get-started-webhooks • SharePoint REST API for Webhooks: https://learn.microsoft.com/en-us/kaizala/connectors/webhooks • Microsoft Graph Change Notifications: https://learn.microsoft.com/en-us/graph/api/resources/webhooks?view=graph-rest-1.0

@chrisflem Thanks for the update.
It was my understanding that webhooks and also Power Automate Flows are built on the same remote events that are also used for remote event receivers, See my SharePoint Stack Exchange question about this: https://sharepoint.stackexchange.com/questions/309639/what-is-the-future-for-remote-event-receivers-for-sharepoint-online
I was hoping that the events would still fire after ACS retirement.
I also am fallowing the discussion on a post created by @jansenbe https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/sharepoint-add-in-retirement-in-microsoft-365/bc-p/4008028#M6814
As you can read there many SharePoint developers would like an alternative for RER and especially sync RER's.

Hi everybody,
Thank you for your explanation.
I want to know the context of your call to RER when using Azure App having App permissions ? When user makes an update for a listItem, it fires the event which has application permissions. In this case, what will se in Auhtor/Editor field ?
When user has less permissions than App, which permission will be applied ?
Can we use Azure App with delegated permissions ?

The context depends upon how the code that listens to the RER performs the auth.
If using ACS, and an app then the rer will contain a context token, else it will not.
If you have context token, then you can in the listener code use the same app id, and a secret plus the context token to work on behalf of the triggering user, with the same permissions as the user. In the modified field it will read "Modified by {AppName} on behalf of {Triggering user}" (or something close to this)
If you do not have/use the token you can authenticate using either ACS or Azure AD clientId + secret/certificate(client credentials flow). Here you will have the permissions specified by the app. In the modified field it will read changed by sharepoint app.
You can not use Azure Ad app reg with delegated permissions, this is only supported by ACS(You only get the context token needed for delegated access when using an ACS app to register the RER)

You cannot directly verify the user, since you're not getting the ContextToken.
What you can do is check who modified he item in SharePoint, to get who triggered the call.
If it's more general authentication, you can add a query parameter to the RER url, and verify it. ex Rer-urlHere?ApiKey=key, and verify that the key is trusted(This will work because a regular user cannot read RER data on lists etc)


Add support for Lightline

Is there some plan to support lightline?
Thanks for the colorscheme.

@lourenci I use vim-one with lightline's built in one theme and it works perfectly for me

Probably, they have added support for it. I'll close this issue since I'm not using Lightline anymore and this seems to be an issue just for me.
Thanks.


Question on react-router docs about redux "deep integration"

The docs https://reacttraining.com/react-router/web/guides/redux-integration state:

I have my app which uses redux, and the store has an array ok books indexed by id.
On BookDetails ( a connected component) i had the selected book id on the state, so i could get the full book instance, and render its title; ie:
<AppBar>
  <BookTitle />
</AppBar>
<BookDetails />

class BookDetails ...

const mapStateToProps = (state) => {
  const id = state.ui.selected_id;
  return {
    bookDetails: state.books.find(b => b.id == id)
  };
};

I have other component on the hierarchy  which was also connected in a similar way, and shows the title inside the global
class BookTitle ...

const mapStateToProps = (state) => {
  const id = state.ui.selected_id;
  return {
    title: state.books.find(b => b.id == id).title
  };
};

Now trying to integrate react-router (migrating away from having the selected book id on the store, to having now the router/match, etc) to point to the selected book.  So, i would have some like:
<AppBar>
  <BookTitle />
</AppBar>
<Route path='/book/:id' component={BookDetails} />

class BookDetails ...

const mapStateToProps = (state, ownProps) => {
  const id = ownProps.match.params.id;
  return {
    bookDetails: state.books.find(b => b.id == id)
  };
};

And also:
class BookTitle ...

const mapStateToProps = (state, ownProps) => {
  const id = ownProps.match.params.id;   // WRONG! there is no match... so...
  return {
    title: state.books.find(b => b.id == id).title
  };
};

In this case, as <BookTitle /> is not part of any <Route path= ... /> then i cannot access ownProps.match.params.id  ... and then cannot know which is the selected id.... etc
if i want to avoid using connected-react-router as the docs try to convince me, how would be The Way to access the book instance on , given the current location from react-router?

import {withRouter} from 'react-router';

// ....

export default withRouter(connect(...)(BookTitle));

https://reacttraining.com/react-router/web/api/withRouter

@marekciupak that is useless...

@jacargentina
Why? As I understand it, you want to pass match as a prop to your component. You can achieve this by wrapping it in a withRouter.

withRouter will pass updated match, location, and history props to the wrapped component whenever it renders.

https://github.com/ReactTraining/react-router/blob/master/packages/react-router/docs/api/withRouter.md#withrouter
Alternatively, you could render your component using Route:
<AppBar>
  <Route path="/" component={BookTitle} />
</AppBar>

Because match is passed only when there is a match on the current component is it is wrapped in a route
That second option you give will not match  anything (it doesn't contain any Params) so.... 🤔

Ah, ok, I see. But you could add the params, right?
<AppBar>
  <Route path='/book/:id' component={BookTitle} />
</AppBar>
<Route path='/book/:id' component={BookDetails} />

I'm just guessing here, because I don't know the context of your app, but perhaps this route should be higher in the hierarchy:
<Route path='/book/:id' component={BookPageContainer} />

BookPageContainer could get the book from the redux state and pass it as a prop to nested dummy components (BookTitle, BookDetails). Alternatively, BookPageContainer could pass bookId as a prop to the nested containers.

Yeah! You have me the key to solve it: I should get the bookid in some top level component, then pass it to child who need it to fetch the book instance, etc
Thanks!


feat: enable support to mode network testnet to networks

Description
I have been reviewing the benefits of using the current project on different networks, and I have conducted tests to validate compatibility with Mode Network (https://www.mode.network/); therefore, to facilitate the adoption of the tool for Mode Network developers, I would like to add their chain."
Contract deployed:
https://sepolia.explorer.mode.network/address/0xE81673a40B621A2d900Ba5cEC5d5eF3eB514D404?tab=txs
Personal project deployed successfully to validate that everything is running as expected.

Mode Network documentation
https://docs.mode.network/build-on-mode/tutorials/deploying-a-smart-contract/using-hardhat
Additional Information

[x] I have read the contributing docs (if this is your first contribution)
[x] This is not a duplicate of any existing pull request

Thanks for this @wolfcito
But we are trying to keep the list small with the main ones. People can always add the chains they want in their builds.


#758: Implementing the first stage of module split

I think we need some kind of a commit freeze in order to commit this -- too many changes.

I have worked a little on site output.
Please check by:
mvn site site:stage

and investigate output in target/staging/versions

I have worked a little on site output.
Please check by:
mvn site site:stage

and investigate output in target/staging/versions

Maven site won't build anymore.

By the way, why did you remove the XSD schemas of the reports from the XSD section? I can re-add those unless you explicitly wanted those removed...

I moved it to place where is generated ... for old versions of XSD we will need place a copy in root site to preserver old path.
We will change repo name ... 😄

Looks like maven site requires the artifacts to be present in the local repo. So we need to do install -P run-its instead of verify in maven-verify.yml?

I see - we use under site build current version of plugin ... it is tricky and sometime works, but with more dependencies for another module can stop working ...
To be clear we should used previous version of plugin for site build.

Looks like maven site requires the artifacts to be present in the local repo. So we need to do install -P run-its instead of verify in maven-verify.yml?

I see - we use under site build current version of plugin ... it is tricky and sometime works, but with more dependencies for another module can stop working ...
To be clear we should used previous version of plugin for site build

But that won't work - the previous version doesn't have modules 😏
Instead, why don't we do something like an extra Github Ci job before running site - Install with no tests, no enforcer, no chesktyle etc. Or compose that as an extra goal in the Site job?

I changed to instal for first step build ... I'm waiting for build ...

I'm want to go with this PR ... even more I can update site with snapshot version before release, so we can quickly resolve all site issues.
Next PR like enforcer rule can be put in separate module - What do you think?

I'm want to go with this PR ... even more I can update site with snapshot version before release, so we can quickly resolve all site issues.
Next PR like enforcer rule can be put in separate module - What do you think?

Definitely!

Can we merge?

So, merged ... next release will be very interesting 😄

eeeh I forgot to squash 😠


Add Debugging subheading to Install CLI page

Lets make this env var really easy to find for new users.

Release note:

Good idea to document this. I think it might make more sense at the bottom of this page https://pinniped.dev/docs/howto/login/ which is where we show how to use the pinniped CLI.

I'd even consider an additional "Debugging" page where we document this env var as well as the YAML changes to enable debugging for server side components.

I'd even consider an additional "Debugging" page where we document this env var as well as the YAML changes to enable debugging for server side components.

That sounds reasonable to me.


ocamlPackages.piqi: 0.6.14 → 0.6.15

Motivation for this change
Compatibility with OCaml ≥ 4.09
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build ocamlPackages.piqi ocaml-ng.ocamlPackages_4_08.piqi-ocaml


Catch missing '$' and other bad PHP

In theory the integration tests should have caught this typo; in practice everything passed and then promptly crashed in production. We need to

[ ] Figure out what happened
[ ] If it's something we can test for using the current rig, do so
[ ] If not, figure out what is needed for adequate testing, and build out the infrastructure to support it

Looks like function send_csv is not called in any integration tests.
Recommend adding integration tests for send_csv, and also send_json, which appears to be related.

what about:
https://github.com/cmu-delphi/delphi-epidata/blob/801f2729ea80b42891aa282c858c489a47049082/integrations/server/test_covidcast.py#L83-L150

oh you're right, i totally missed that, thanks for pointing it out.

when the $ is missing, the integration test passes, but the server logs the following:
[Thu Oct 08 10:12:51.386119 2020] [php7:warn] [pid 18] [client <IP_ADDRESS>:39892] PHP Warning:  Use of undefined constant data - assumed 'data' (this will throw an Error in a future version of PHP) in /var/www/html/epidata/api_helpers.php on line 393
[Thu Oct 08 10:12:51.386140 2020] [php7:warn] [pid 18] [client <IP_ADDRESS>:39892] PHP Warning:  Illegal string offset 'result' in /var/www/html/epidata/api_helpers.php on line 393

it would be nice to somehow tell php to treat this particular warning (or maybe all warnings) as an error. unfortunately i don't see a good way of doing that. the recommended approach seems to be to overriding the global error handler, which is less than ideal imo.

isn't there some linting tool that catches those kind of errors during a static analysis?

can we close this since we switched to Flask + Python?

Yep!


Its not finding the path ... see in settings.py my tortoise-conf is present but it saying module not found

Error: Error while importing configuration module: No module named 'settings'
root@4288e7c9f646:/app# tortoise-cli -c settings.TORTOISE_ORM shell
Error: Error while importing configuration module: No module named 'settings'
root@4288e7c9f646:/app# ls
DockerProdFile	init.py  aerich.ini    docker-compose.yaml	main.py     pip		      settings.py  static
Dockerfile	pycache  commands.txt  env			migrations  requirements.txt  src	   tortoise-cli

You can reference examples, maybe settings should in a python package which contains __init__.py

i have added init.py in all the folders but its not finding the path
https://github.com/sakthiRathinam/fastapicore
do u please check this project link mention above the tortoise_orm is present in src/config/tortoise_conf
root@4288e7c9f646:/app# tortoise-cli -c src.config.tortoise_conf.TORTOISE_ORM shell
Error: Error while importing configuration module: No module named 'src

I update, you can try latest source code, if right I will release a new version

its working fine now.....update the version


batch .tga to mipmap .DDS

I'm trying to batch convert about 900 or so images in batches of about 101 with mipmaps.
This conversion works fine in the compressonator gui. (Edit: Version 2.4.3214.0)
example:
ProgressBarBattery_SC_000.tga
mipmap level set to 5
Converting to DXT5
Quality set to 0.5000
Adaptive is unchecked
Name: ProgressBarBattery_SC_000 | Dropdown is on DDS
Source is D:/ Drive | Destination is D:/ Drive  In an alternate Folder
Settings saved | Process | ===Compress: 1 succeeded, 0 failed===
I check the file and.... Perfection
Then I export the settings to batch file. I made multiple batch files for image sets in groups of 101. Double checked my batch files and saved. Placed the bat files in the compressonator install folder(C:/Program Files/Compressonator and ran first batch file. Bat file ran and closed so I checked my processed file folder and... its empty?
Okay so need a small test to see whats going on. Back to original test image.
I delete the test result from the gui from earlier. Open the original batch and it lines up with what is shown in Output window of gui. I run the bat file and.... processed folder is empty. HUH?
so I add a cmd command I remembered of the top of my head to the test bat file.
pause
Ran the bat file again and yay it paused. This is what I see.
CompressonatorCLI.exe "D:/...(EDITED).../ProgressBarBattery_SC_000.tga" "D:/...(EDITED).../ProgressBarBattery_SC_000.DDS"  -fd DXT5  -miplevels 5  -Quality 0.5000
Source Texture size = 1048576 Bytes, width = 512 px  height = 512 px
Destination Texture size = 262144 Bytes    Resulting compression ratio = 4.00:1
Compression progress = 94Source Texture size = 262144 Bytes, width
= 256 px  height = 256 px
Destination Texture size = 65536 Bytes    Resulting compression ratio = 4.00:1
Compression progress = 88   MipLevel =  2Source Texture size = 65536 Bytes, width
= 128 px  height = 128 px
Destination Texture size = 16384 Bytes    Resulting compression ratio = 4.00:1
Compression progress = 75   MipLevel =  3Source Texture size = 16384 Bytes, width
= 64 px  height = 64 px
Destination Texture size = 4096 Bytes    Resulting compression ratio = 4.00:1
Compression progress = 50   MipLevel =  4Source Texture size = 4096 Bytes, width
= 32 px  height = 32 px
Destination Texture size = 1024 Bytes    Resulting compression ratio = 4.00:1
Compression progress = 0     MipLevel =  5Source Texture size = 1024 Bytes, width
= 16 px  height = 16 px
Destination Texture size = 256 Bytes    Resulting compression ratio = 4.00:1
Compression progress = 100 MipLevel =  6Error: saving image or format is unsupp
orted
Is it a bug in the batch converter code or
Do I Need to convert from tga to something else then to .dds?
If I need to double convert then what should I convert to before moving to .dds conversion?
Edit
Okay... ran another test. Moved the target file from D drive to the compressonator image folder.
Source C:\Program Files\Compressonator\images\ProgressBarBattery_SC
Desti.... C:\Program Files\Compressonator\images\ProgressBarBattery_SC2
Converted properly from bat. I can work with this. Seems to have issue with heavily nested folder paths or folder paths with long names.
C:/Program Files/Compressonator/images/ProgressBarBattery_SC/ProgressBarBattery_SC_000.tga
Worked
D:/ProgressBarBattery_SC/ProgressBarBattery_SC_000.tga
Worked
D:/Modding Files/ProgressBarBattery_SC/ProgressBarBattery_SC_000.tga
Worked
D:/Modding Files/Space Engineers/ProgressBarBattery_SC/ProgressBarBattery_SC_000.tga
Worked
D:/Modding Files/Space Engineers/Test Mod Textures/ProgressBarBattery_SC/ProgressBarBattery_SC_000.tga
Failure
I was working from deeper folders than that. I do love my folders... ugh. well i can work with this by moving my files then doing batch convert then moving them to where I want them. Still easier than the alternative.
Yes I have admin rights. I'm the only one that uses this personally built pc. Even if I didn't, I know how to give myself permissions. I didn't do the admin cmd bit i've just been running the bat directly by double clicking on it.
But seriously check that out and see if you could do something about that path length issue. would be greatly appreciated. Keep up the great work. XD Thanks

hi @ryutoshirazen , my guess is you are not the admin, so can't make any change (write access) to the C:/Program Files/  path in your system, but i am not sure. Can you try open your cmd window by "run as administrator" and navigate to the compressonator install path (C:/Program Files/Compressonator) then run your batch file through the cmd window?
Thanks

Hi
I tried to duplicate your issue and was unsuccessful in reproducing!
Here are the steps I used.
Created a batch file NewProject.bat with the content as shown below using the GUI
CompressonatorCLI.exe  "E:/Test/ruby.tga"   "E:/Test/ruby_TGA_DXT5_1.DDS"   -fd DXT5  -miplevels 5  -Quality 0.5000
64 bit Compressonator is installed by default on C:\Program Files\Compressonator, Going into command prompt with administrator permission, I copied the batch file to that folder and ran it.
Maybe its an issue with admin settings!
No need to convert TGA file, compressing directly to DDS is ok.

Main post edited if you didn't see.
Funny enough tried running it from admin cmd for shits and giggles at path
D:/Modding Files/Space Engineers/Test Mod Textures/ProgressBarBattery_SC/ProgressBarBattery_SC_000.tga
and where it failed before it succeeded.
though implementing batch processing into the GUI would be much nicer.
something as simple adding a bunch of files then using just a master destination with master settings to be applied to all files in the gui list. Or using a master destination and settings that could accompany individual settings or be overridden by individual settings.
I like batch processing guis. I use gimp and it has through plugins batch layer processing and batch file processing with guis.
anyways thanks for your help. since i found a way to make it work without having to go into the admin cmd this issue can be closed.


modules in testdata/go make IntelliJ go nuts with trying to request github login information

Describe the bug
Modules in testdata/go seem to be corrupt by design but since the git repo under the specified dependencies are not existing or private, IntelliJ tries to request login information for those repositories.
To Reproduce
Checkout jfrog-cli repo with intellij with go plugin installed.
Expected behavior
Not have corrupted projects in testdata or fix with replace statements in go.mod files
Screenshots

Versions

JFrog CLI version: project source code
JFrog CLI operating system: Windows

Hi @7DataBits ,
Thanks for reporting this issue.
This was resolved with the merge of #916.
Would appreciate your feedback, thanks.


IW creation telemetry

for https://github.com/microsoft/vscode-jupyter-internal/issues/378

@lramos15 - you were just requesting to fill out the comment field, right? Does that look good now?


Tweak OIDC configuration in API and dashboard

Allow to skip API auth. email verified check (API).
Allow OIDC scopes configuration (dashboard).
Add OIDC ABAC roles mapping type guard (dashboard).

Refs #1037.

@djjuhasz it's probably better that you review this PR commit by commit.


onSuccess is not callingf after successfull signin response

<div className="flex justify-center">
            <AppleSignin
              className="apple-auth-btn"
              authOptions={{
                clientId: 'com.example.www',
                scope: 'email name',
                redirectURI:
                  'https://www.example.com/auth/apple-authentication/callback',
                state: 'state',
                nonce: 'nonce',
                usePopup: true,
              }}
              buttonExtraChildren={'Sign in with Apple'}
              onSuccess={(response) => {
                console.log(response);
                alert('Okay');
              }}
              onError={handleAppleLoginFailure}
            />
          </div>

I am Facing Same error

onSuccess only gets called in case of using popups usePopup true
I can see you're using redirects, so you need to handled your on success logic via parsing the route URL instead OR use popup

if I use popup ONLY then the popup is not opening


Add Colorful timeline

Demo gif:

Screenshot in light mode:

Screenshot in dark mode:

Note that the text color in the timeline itself will adapt to be white or black depending on which will be better contrast for that task.

One possible concern: with this on, the text in the timeline is always black or white, even if text in your theme is, say, red. I was unable to think of a better way to ensure contrast.

Looks great! Again, thanks for the submission 🚀


Support multiple windows

Thank you for this nice project!
I'm looking for a lightweight tmuxomatic replacement, however what's keeping me there might be a good feature for tmex -- multi-window support.
Is it something you could consider within tmex? Maybe running tmex with the same session name but with additional flag could create next window instead of detaching from the old one and re-attaching?
Another thing could be a focused pane for every separate window. Maybe with an -f P1,P2 flag.

Hey @vaygr, those both seem like great ideas, thanks. I'd be very interested in adding these features to tmex. I've been thinking about possible interface changes to accommodate this, curious what you think.

Maybe running tmex with the same session name but with additional flag could create next window instead of detaching from the old one and re-attaching?

100% on board with this as a way of composing a session from multiple commands. I'd also love to support the option of doing it all in one command – thinking something like this (using a -w/--window flag):
tmex mysession 12 "cmd 1" "cmd 2" "cmd 3" -w 21 "cmd 4" "cmd 5" "cmd 6" -w "cmd 7" "cmd 8"

This would spawn a session with window 1 running commands 1,2,3, window 2 running commands 4,5,6, and window 3 running 7,8. Each window can optionally have a layout specified. Each set of args following -w is treated as a full independent set of tmex args (with session name optional after the first), which I think would make implementation more straightforward.
The above would be equivalent to:
tmex mysession --window --detached 12 "cmd 1" "cmd 2" "cmd 3"
tmex mysession -wd 21 "cmd 4" "cmd 5" "cmd 6"  # same flags, but shorthand
tmex mysession -w "cmd 7" "cmd 8"  # finally attach to mysession which will now have 3 windows

Or instead of using --detached, you could run tmex from within the session to accomplish the same thing:
$ tmex mysession 12 "cmd 1" "cmd 2" "cmd 3"
  # now we're in mysession
[mysession:window1] $ tmex -w "cmd 4" "cmd 5" "cmd 6"
  # a window is added to mysession, and we're taken to that window
  # sessionname arg can be inferred from this context so you don't need to provide it
[mysession:window2] $ tmex -w "cmd 7" "cmd 8"
  # a third window is added, and we're taken to that window (or use --detached to create in background)
[mysession:window3] $

All this seems to make pane focus pretty natural to incorporate as well – -f/--focus could always accept a single integer (and error if anything else is passed, or if the int is out of range of the pane count). Each of the variations can accept focus for each window:
tmex mysession -l 12 -f 2 "cmd 1" "cmd 2" "cmd 3" -w -l 21 -f 1 "cmd 4" "cmd 5" "cmd 6" -w -f 1 "cmd 7" "cmd 8"

tmex mysession --window --detached --layout 12 --focus 2 "cmd 1" "cmd 2" "cmd 3"
tmex mysession -wd -l 21 -f 1 "cmd 4" "cmd 5" "cmd 6"
tmex mysession -w -f1 "cmd 7" "cmd 8"

or even this shorthand would be valid:
tmex mysession -wdf2 12 "cmd 1" "cmd 2" "cmd 3"
tmex mysession -wdf1 21 "cmd 4" "cmd 5" "cmd 6"
tmex mysession -wf1 "cmd 7" "cmd 8"

Does this design seem like it would support your use cases well?

Sorry about the delay here, been quite a week.
I may have limited understanding here due to the ways I use tmux, but my expectation would be that command execution behavior would remain the same as it is now – if you specify a command for a pane (instead of specifying an empty pane via the layout), the command is executed as soon as the pane is spawned, regardless of whether it's focused or not.
This means I can run tmex parallelsession "sleep 10" "sleep 10" "sleep 10" and all sleeps immediately start running in parallel, whether pane 1, 2, or 3 (default) is focused.
Is the ability to delay execution of commands in some panes, perhaps until they're focused, something that you're looking for?

Sorry, yeah, I got confused by one of the long lines in the example. Everything is clear now. Nothing extra besides what you initially proposed is needed.

Great to hear! I'll be working on this very soon (along with a few other minor improvements). Thanks again for the feedback and ideas.

Hello,
Any progress on this? The tool is amazing btw!

Hey @movy, thanks! Sorry about the long delay in response, have been sidetracked from this project by some other life events this year. I'm in the midst of an implementation on this, and should have something soon.

Thanks for the uodate, this is great
On Sun, 14 May 2023 at 02:02, Evan Purcer @.***> wrote:

Hey @movy https://github.com/movy, thanks! Sorry about the long delay
in response, have been sidetracked from this project by some other life
events this year. I'm in the midst of an implementation on this, and should
have something soon.
—
Reply to this email directly, view it on GitHub
https://github.com/evnp/tmex/issues/5#issuecomment-1546731687, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBCXMBL4CJ3V2KBNRZLD23XF7LGDANCNFSM6AAAAAARGF6CPU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hello @vaygr @movy, I've just published https://github.com/evnp/tmex/releases/tag/v2.0.0-rc.1 which implements the features described in this thread, along with some other things. I decided to make this the 2.0.0 release to reflect the fact that it includes significant changes to the tmex code, and thus comes with some risk of regression. The test suite has been expanded from 60 to around 250 test cases at present, to help mitigate this risk.
I'll be working on edge-case hunting and testing even further over the next two weeks, at which point I'd like to move from v2.0.0-rc.1 to a full v2.0.0 release (if no issues are discovered, and if so that timeline will be adjusted to fix them). Any bandwidth you have to try out the new version / report any issues is greatly appreciated!

Hey @vaygr, I've made this update in https://github.com/evnp/tmex/commit/c402fbc7e226e8c2bafa8fde5ed347d301549fb9, released at v2.0.0-rc.2. Let me know if that seems to work as expected.
Disregard this part if you're not installing via npm – the v2.0.0-rc.2 version seemed to break rendering of the readme at https://www.npmjs.com/package/tmex 🤔 I published v1.0.11 instead and tagged v2.0.0-rc.2 as "next" which fixed it, and feels more correct anyway. If you're installing that way, please use npm install -g tmex@next and you should get the latest.

@evnp ,
I tested new window feature, and it seems to fail creating windows when using iTerm tmux integration.
Below is the result of running the following command from  README:
tmex your-session-name --window abc 123 -w efg 44

As you can see, tmex/tmux/iterm packed all panes into the same window/tab. Do you have MacOS to test this scenario?
Thanks heaps for your support.

Hi @movy, sorry about the delay getting back, been in the middle of some travel.
Thanks for the report, that's very odd. I get the correct behavior when running
tmex your-session-name --window abc 123 -w efg 44

on my OSX laptop, with 2 tmux windows produced.
Can you try running the command with the --print option and let me know what it outputs? Here's mine for reference:
$ tmex your-session-name --print --window abc 123 -w efg 44
new-session -s your-session-name ; rename-window abc ; split-window -h -l67% ; split-window -h -l50% ; select-pane -L ; select-pane -L ; select-pane -R ; split-window -v -l50% ; select-pane -R ; split-window -v -l67% ; split-window -v -l50% ; new-window -n efg ; split-window -h -l50% ; select-pane -L ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50% ; select-pane -R ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50%

It would also be useful to know if you get the same behavior when running the command produced by the above with "tmux" pre-pended, eg.
$ tmux new-session -s your-session-name ; rename-window abc ; split-window -h -l67% ; split-window -h -l50% ; select-pane -L ; select-pane -L ; select-pane -R ; split-window -v -l50% ; select-pane -R ; split-window -v -l67% ; split-window -v -l50% ; new-window -n efg ; split-window -h -l50% ; select-pane -L ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50% ; select-pane -R ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50%

(this should have the same behavior as tmex your-session-name --window abc 123 -w efg 44)
It would also be useful to know these versions, I'm wondering if an earlier version of tmux behaves differently.
$ tmux -V
tmux 3.3a
$ tmex -v
tmex 2.0.0-rc.4

Thanks for your response. I've got the same versions installed:
$ tmux -V
tmux 3.3a
$ tmex -v
tmex 2.0.0-rc.4
But I guess I begin to understand the problem: I use iTerm with tmux integration, i.e. new tmux tab = new tmux tab and new tmux window = new iTerm tab (i.e. native MacOS tab within iTerm window). In addition, I work mostly remotely, and iTerm tmux integration is pure magic for remote work.
Now, whenever I run tmex your-session-name --window abc 123 -w efg 44 locally I do get two tmux windows (not native windows or tabs), but whenever I run tmex remotely, it always spans all tabs within same tmux window (i.e. within same iTerm tab).
Nevertheless, I'm already very happy with existing functionality where I can split a window into number of tmux tabs with a single command, the lack of window spawning from within iTerm is just  a minor nuisance.

Appreciate the details @movy. It's taken me a while to find the bandwidth to properly understand iterm2's tmux integration, but I have a decent repro now. Will be poking at this and hopefully have some improvements to the behavior soon.
Glad to hear the tool is still useful despite this! but definitely a use-case I'd like to work well if possible.

Hey @movy, I've published https://github.com/evnp/tmex/releases/tag/v2.0.0-rc.5 which attempts to fix this set of issues. Curious to hear whether it does the job for your workflows.
I'll be working on updating the tests, docs, and fixing one issue between this and the --npm set of functionality. But wanted to get this in front of you without too much delay to make sure the direction seems right. Thanks for your feedback!

This is great! Just tested with basic tmex  --window abc 123 -w efg 44 and seems to be working fine! Will update my npm scripts and test in production later today. Thanks heaps for the prompt update!

(at long last) I've released https://github.com/evnp/tmex/releases/tag/v2.0.0-rc.8 which intends to cover this functionality. This will become a 2.0.0 release in around a week. Please let me know if you come across any issues or changes needed in the meantime. Thanks!


[formrecognizer] Remove continuation_token kwarg

Removes continuation_token keyword argument.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-formrecognizer


bump helm charts for 0.9.17

Problem Statement
What is the problem you're trying to solve?
Related Issue
Fixes #...
Proposed Changes
How do you like to solve the issue and why?
Checklist

[ ] I have read the contribution guidelines
[ ] All commits are signed with git commit --signoff
[ ] My changes have reasonable test coverage
[ ] All tests pass with make test
[ ] I ensured my PR is ready for review with make reviewable

/ok-to-test-managed provider=aws sha=bc8d171

/ok-to-test-managed provider=gcp sha=bc8d171


Badge padding using em not rem

Hia, I've just noticed that $badge-padding-y and -x are using em not rem.
This has made some size maths not work as rem and em are incompatible.
Is there a reason these are using em not rem, or is it just an oversight? Happy to PR a patch if so.

Also the following are also using em:

$badge-pill-padding-x
$caret-width
$mark-padding

em units are used so it scales to the parent element's font-size.


QB: DAC-5 digit sectors not sorted in order

Describe the bug
When clicking the sectors drop-down, the sectors are displayed out of order. It be great for them to be listed in order - ordered by code (as on the Sector codelist); as the codes are deliberately grouped together in the coding system.
To Reproduce
Steps to reproduce the behavior:

Go to the Query Builder, core filters tab: https://test-datastore.iatistandard.org/querybuilder/core-filters
Under "Sector", click on "All sectors" to open the drop-down
See that 92030 is listed first.

Expected behavior
Code 11110 should be listed first, according to the Sector codelist.
Screenshots

Desktop (please complete the following information):

OS: OSX
Browser: Firefox
Version: 69.0.3

(Same issue on OSX, Chrome 78.0)

fixed