Remove support for the $expand querystring

Bug Report
Whilst some API's allow specifying the $expand query string to conditionally return extra fields in the response, due to the nature of the Azure SDK's (across all languages) there's no way of accessing these dynamic fields. Whilst one option would be to add a map[string]interface{} to each struct of "Additional Fields" (which has been done I think in Track2) - there's no compatibility guarantees across API versions - so this is likely to be a source of crashes in end-user programs.
Instead, I'm wondering if support for the $expand querystring should be removed from (all) the Azure SDK's - since whilst this makes sense in the API (and hand-rolled clients), the design of the SDK's (using native structs) makes these a challenge to use. Arguably this is a design issue within the API's themselves and a Swagger issue where these aren't fully documented - but the $expand option ends up being a common source of breaking changes to method signatures for essentially zero value (since these fields can't be guaranteed/relied on) - so I'm wondering if this should be removed from the SDK?

Hi @tombuildsstuff thanks for opening this issue!
Since this involves massive breaking changes acrossing all packages, we might need to discuss more of this to avoid this kind of breaking changes.
Adding @jhendrixMSFT for discussion

Hmm I wasn't aware of this param and its behavior.
I took a cursory look through the specs repo, this appears to be authored like any other param.  Unfortunately the authoring is of varying quality.  For example, in consumption the additionalProperties appears to be incorrectly modeled (presumably it should be a dictionary type).  In authorization, the $expand param is modeled but not the additionalProperties in the response (I don't know if the author forgot or they expected the code generator to implicitly add it).
I don't think we can get into the business of omitting params modeled in a swagger file during codegen, they would have to be removed from the swagger (maybe we could do it for ARM only, but it's a slippery slope I'd prefer to avoid).  Of course, introducing a breaking change for an optional param (fixed in track 2) that doesn't even work is pretty terrible.  I'll follow up with how we can get this fixed on the swagger side.
Track 2 codegen doesn't perform any special handling for $expand, so it's just as broken.

The swagger should define a model that describes (and documents) all possible fields. $expand should just indicate which of these fields should be initialized by the service. A client should not be broken by changes here. If the swagger is bad, then it should be fixed but I do not think the SDK should change its ways.

Closing as we have moved optional params to the "optional params struct" to avoid method sig breaking changes (we can't omit this).


Order history enhancements

Order history is missing the following features:

order list: search/filtering by date range, orderno, status, productno
order details: add2cart button
currently order history is visible for the current user only. Optional configuration in backoffice to display order history for all users of the current customer

AB#89758

order list: search/filtering by date range, orderno, status, productno - implemented with #1571

order details: add2cart button - implemented with #1592

order history for all users of the current customer - the REST API for this feature will be available with ICM 12.1.0 and the functionality will be implemented in the PWA, the feature will be available based on a certain permission of the currently logged in user


Added CYOA - Craigslist scraper app

Biggest thing: no tests!
Otherwise, just minor refactors. But... tests.


feat: Added support for application emojis

This PR adds support for application emojis.
Code change checklist

[x] I have ensured that all methods and functions are fully documented using doxygen style comments.
[x] My code follows the coding style guide.
[x] I tested that my change works before raising the PR.
[x] I have ensured that I did not break any existing API calls.
[x] I have not built my pull request using AI, a static analysis tool or similar without any human oversight.

PR is fully tested now and is ready :saluting_face:

Would you mind if I ask about adding sync versions of it? (Also coro would be nice, but I think this is not mandatory)

oh yeah forgor to let them auto gen


Create documentation for DOI and snapshots

Feature Request
Desired behaviour
Need documentation for DOI and snapshotting
Should cover

what it means to snapshot
what it means to create a DOI
what users can do to make their DOI better (provide description, metadata)
what we will likely add as future work (pull in imports, link ORCID, etc.)

Should look akin to
https://beta.docs.dockstore.org/en/develop/advanced-topics/sharing-workflows.html
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Sprint: Seabright Sprint 18 Skipjack
┆Issue Number: DOCK-947

➤ Melaina Legaspi commented:
merge dock-402 descriptions


Page has a link all over the place

There's a link stuck somewhere in the page, so entire page turned into a link.

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

ID: 873500f9-ae68-2bdd-9956-01a5904c5a06
Version Independent ID: b3ce94fa-6e76-4ffe-e70e-07f7a321fcd4
Content: Uninstall Azure PowerShell
Content Source: docs-conceptual/azps-4.6.1/uninstall-az-ps.md
GitHub Login: @mikefrobbins
Microsoft Alias: mirobb

@Jamminroot Thanks for bringing this to our attention. This was also reported in #1561. I have submitted a PR to fix the issue that's in review.

Resolved by @BhargaviAnnadevara-MSFT via #1562.


MFEM archive for Windows

Hi All,
Recently, I was trying to help a student to build the MFEM library on a Windows machine. Even though there were some issues with that particular machine, and we ended up building it on Mac, I would like to let you know that even the very first step of obtaining the source code from the mfem.org was an issue. The archive has the .tgz format, which is totally okay if you're on a Unix-like machine, but it turned out that Windows doesn't necessarily have tools to unarchive that. There are, of course, tools like 7-zip and so on, available for Windows, but without admin rights we couldn't install anything.
My suggestion is therefore to have a .zip archive along with .tgz on the main page of mfem.org for those who use Windows machines. As an example, CMake comes as a tar.gz archive for Unix OS, and as a .zip archive for Windows.
Cheers,
Mikhail

Thanks Mikhail,
Let us think about it... maybe we can add another button with a Windows-friendly archive.
While not optimal, one can always download the ZIP file for the master branch on GitHub, https://github.com/mfem/mfem/archive/master.zip.
Cheers,
Tzanio

Hi Tzanio,
Ah, indeed, there is a way to download the zip archive from GitHub. I forgot about it. But anyways, another button with a Win-friendly archive would be also very nice.
Cheers,
Mikhail

BTW, @martemyev, check out the updated http://mfem.org/about page.

@tzanio That's super cool. Thank you guys!