The  /Orders endpoint - separating between own orders and public orders

We have encountered an issue with the /Orders endpoint. It is needed both to

view own orders (in order to e.g. validate/update/delete them, or to get the latest status (e.g. if they have been filled)
view other orders

The second use case is a bit tricky, because different FMOs will have different policies regarding e.g.

Which orders actors are allowed to see
What information actors are allowed to see for other organizations' orders
Whether those orders represent single orders or aggregated views

Furthermore, those two use cases are somewhat distinct and may have different requirements regarding e.g. required search parameters etc. The result could also be confusing if FMOs aggregate multiple orders into one publicly visible order.
We propose splitting those two use cases, to make it easier to understand how to use the endpoint, and easier/predictable to understand the answer. In other words, actors should either query only for their own orders, or for all orders (that are visible to them).
The result model might still be the same. Some fields will be hidden (NULL) in some cases, but actors should anticipate this anyway since different FMOs have different business rules.
We can do this in one of several ways:

Have two separate endpoints, e.g. /own-orders and /public-orders
Add a required search parameter, e.g. VisibilityType=Public or VisibilityType=Own
Add ownerOrganizationId as a search paramter, corresponding to Order.ownerOrganizationId.

For the third proposal, FMOs can choose to make the ownerOrganizationId parameter required or not, depending on business rules. In NODES it would probably be optional. Other FMOs may choose differently.
FMOs are required to either respect the parameter or to exept with a proper message if that search parameter is not supported.
If the search parameter is required but not provided FMOs must return a proper exception stating that the parameter needs to be set.
@cdmNSIDE @ArnaudDebray what do you think?

@cdmNSIDE @ArnaudDebray What do N-Side think of this PR? Do you prefer separate endpoints?
I think NODES is leaning towards separate endpoints, but will wait with changing the PR until I have heard from you.

Hello Narve,
Concerning the ownerOrganizationId : it might be a good solution, but we should make clear in the API that the user may not receive all the information about an order if this order is not owned by his organization (i.e. the content of a private order may not be exactly the same one as a public order). I wonder also if this  ownerOrganizationId should not be added in the trades or other resources (ex: is it useful for the baseline or meter readings?)
Concerning the 2 separate endpoints: ok, why not, even if we pushed up-to-now to limit the number of endpoints. Do you think we should also have 2 separate endpoints for the trades ?
How to you see the integration of those 2 solutions with the authentication / authorization process ?

Good point about the trades, we have the same issue for those.
I will update the PR with a new endpoint and updated documentation. I suggest doing the trade-endpoint-split in a different PR once we agree on this one.

@cdmNSIDE Please have a look at the updated PR and see if it is acceptable. We'll handle your other points in separate PRs .


Table#delete(List) should mutate the list in place and remove successful actions

According to
https://hbase.apache.org/1.4/apidocs/org/apache/hadoop/hbase/client/Table.html#delete(java.util.List)
When an error happens, the list should get modified to only include failed deletes

Released in https://github.com/googleapis/java-bigtable-hbase/releases/tag/v1.21.0


Implemented datamodule for ecoacoustics dataset.

there should be a test

Is this ready for review?

There is the ImageTransformer to AudioTransformer conversion to do but I've kind of put it on the backburner for now, I also need to parameterise the spectrogram transform so maybe I can do that in another branch and this can get merged?


Add EU cookie law support

This patch contains 2 additional options to make it compatible with the EU cookie law. It can track without cookies and anonymize the ip address of the user.

This repository is just a mirror, pull requests are not monitored or accepted
here. Please look at the official page for instructions on how to contribute
changes back to this plugin. If none exist, we suggest posting a new topic to
address this on the support forum on WordPress.org.
Official Page: http://wordpress.org/plugins/nk-google-analytics/
Support Forum: http://wordpress.org/support/plugin/nk-google-analytics/


Race condition with secrets in Pulumi provider

I deployed a service with the pulumi provider and got the following error:
    error: 9 FAILED_PRECONDITION: missing secret source:"AWS_SECRET_ACCESS_KEY"

Here's the relevant part of the pulumi script:
const srvc = new DefangService("srvc", {
  // [...]
  secrets: [
    {
      source: "AWS_SECRET_ACCESS_KEY",
      value: accessKey?.secret || "-",
    },

Running the script a second time worked.

Possibly related to https://github.com/defang-io/defang-mvp/issues/621


Require Swift 5.6

As pointed out in #1489, we somehow lost compatibility with Swift 5.5 (Xcode 13.2). While we hope to drop support when we hit 1.0, let's try to keep compatibility in the meantime.
Unfortunately, it does not appear that Swift 5.5 is up to task when it comes to the new ReducerProtocol. While we'd be happy to support it for folks that are stuck building on Xcode <=13.2.1, we personally don't have the bandwidth to investigate the problem. I've opened #1494 to track this.

A direct consequence is that TCA can now ship SwiftPM plugins. There are probably interesting uses regarding 1.0 migration.


image shortcodes missing

../Fuji/layouts/shortcodes only contains img-lazy.html ... docs indicate there should be img-nz and img-nz-lazy as well. Using these shortcodes causes a build error:
/blah/blah/01/triffids.md:27:1": failed to extract shortcode: template for shortcode "img-nz-lazy" not found

25 26 27 28 | {{< img-nz-lazy "Alt text" "/Screenshot-2019-01-12-17.11.54.png" >}}

Hugo Static Site Generator v0.73.0/extended darwin/amd64 BuildDate: unknown

This may be my inexperience with Hugo and shortcodes ...

Oh, it was my fault.
The zoomable image depends on medium-zoom which once had some compatibility issues with the dark mode.
So the codes for medium-zoom were removed at that time.
I have fixed it but forgot to bring the zoomable image back in so I'll make it work in the next few days. 😂

With thanks. I’ll look forward to it.
Thanks for your work on the theme.
D.

On 7 Jul 2020, at 13:55, DSRKafuU<EMAIL_ADDRESS>wrote:
Oh, it was my fault.
The zoomable image depends on medium-zoom which once had some compatibility issues with the dark mode.
So the codes for medium-zoom were removed at that time.
I have fixed it but forgot to bring the zoomable image back in so I'll make it work in the next few days. 😂
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/amzrk2/hugo-theme-fuji/issues/37#issuecomment-654837123, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMZJKYOVVRXYUNWL5RXIV3TR2MLLHANCNFSM4OSYVSUQ.

Shortcodes should now work correctly🧐
Try update the theme


object.property? or object.getter? should cast boolean

CoffeeScript seems to follow Ruby pretty closely - so why can't this be the case?
foo.bar? currently translates to (foo.bar != null) but I think it would be better to translate to (!! foo.bar)

You failed to suggest a syntax for the replaced existence test.

Ok, better still..
object.property? => !! (typeof object.property === 'function' ? object.property() : object.property)
object['property']?
And for the existence test
object.?property => 'property' in object
object.?['property']

CoffeeScript's ? (existential operator) is very much not the same thing as adding ? to the end of a method in Ruby. Instead it's an operator that answers the question: "Does this variable exist?"


Ensure settings for Service and Mailer are read on the install page

NewContext does not set the mailer or service settings so add
a new function that will run this.
Fix #15894
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

There is one slight issue with this approach - the mailer settings will still not be set if [mailer] ENABLED is not equal to true.

Codecov Report

Merging #15943 (12f3b56) into main (6021fbf) will decrease coverage by 0.04%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main   #15943      +/-   ##
==========================================
- Coverage   44.07%   44.03%   -0.05%
==========================================
  Files         682      682
  Lines       82408    82412       +4
==========================================
- Hits        36322    36286      -36
- Misses      40176    40222      +46
+ Partials     5910     5904       -6

Impacted Files
Coverage Δ

modules/setting/setting.go
49.62% <0.00%> (-0.29%)
:arrow_down:

routers/init.go
44.33% <0.00%> (-0.43%)
:arrow_down:

models/repo_mirror.go
16.66% <0.00%> (-11.91%)
:arrow_down:

modules/notification/mail/mail.go
38.77% <0.00%> (-3.07%)
:arrow_down:

modules/cron/tasks_basic.go
85.43% <0.00%> (-2.92%)
:arrow_down:

modules/queue/manager.go
65.53% <0.00%> (-2.83%)
:arrow_down:

modules/charset/charset.go
71.71% <0.00%> (-2.03%)
:arrow_down:

modules/log/event.go
59.90% <0.00%> (-1.89%)
:arrow_down:

services/gitdiff/gitdiff.go
72.35% <0.00%> (-1.42%)
:arrow_down:

modules/queue/workerpool.go
53.81% <0.00%> (-1.15%)
:arrow_down:

... and 9 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6021fbf...12f3b56. Read the comment docs.


save editors before issuing an app restart command

save editors before issuing an app restart command

@danrubel

LGTM


DOCS-10097 db execute bulk examples kt

Rewrote Database Connector Execute Bulk operations.
Add Studio steps and screenshots
Reorganized content

Closing as creating new PR https://github.com/mulesoft/docs-connectors/pull/1804


Adding OBC StorageClass in converged mode

Made the required changes to provide OBC StorageClass in converged mode.
Signed-off-by: Arun Kumar Mohan<EMAIL_ADDRESS>

@jarrpa , @leseb , can you please take a look at this PR...
FYI: @rajatsingh25aug , you may have to rebase your PR#500 on top of this, so that you will get the OBC StorageClass at your disposal...

/ok-to-test

More comments left. In addition, there are a number of things going on here that should be in their own commits:

Using well-known label variables instead of strings and using an app variable
Creating the isCloudPlatform() function
Changing the CephObjectStore configuration (and Placement?)
Adding the OBC StorageClass

Please split up your commit along those lines.

Separated each changes into different logical commits.
@jarrpa , @leseb , @Madhu-1 , please take a look...

It looks like your third commit could still be two commits: one to make the changes to the RGW Placement and the CephObjectStore config, and another for adding the OBC StorageClass.
Even so, did you mean to remove the NodeAffinity and Toleration from the RGW Pod? I would imagine they should remain in the default Placement. If not, explain why.

That was my bad (sleepy head) (=
Can you please check now...

Even so, did you mean to remove the NodeAffinity and Toleration from the RGW Pod? I would imagine they should remain in the default Placement. If not, explain why.

@leseb ^^^

Even so, did you mean to remove the NodeAffinity and Toleration from the RGW Pod? I would imagine they should remain in the default Placement. If not, explain why.

@leseb ^^^

@jarrpa we are adding anti-affinity because we have 2 instances instead of one so we want them to run on a different machine, just like we do for CephFilesystem.
Makese sense?

@jarrpa , met all the review / concerns raised... Can you please take a look...

@jarrpa , met all the review / concerns raised... Can you please take a look...

3rd commit still needs to be broken.
Please mark all resolved conversations as resolved, so it's clear what is left out.

Commit 3 does more than one thing (CSV update, Placement change, Gateway spec change). Good idea to break it since they're not related.
Commit 3 and 4 both have CSV changes. But I don't see changes that should be affecting CSV.

3rd update, Changes for 'GatewaySpec', is basically one entity all related to GatewaySpec change (to be specific, Instances: 2 change) and we changed the Placement because of the multiple instances.
I postponed the CSV creation to the last commit... I will amend the said commit with CSV updations...

@umangachapagain ,

Commit 3 does more than one thing (CSV update, Placement change, Gateway spec change). Good idea to break it since they're not related.
Commit 3 and 4 both have CSV changes. But I don't see changes that should be affecting CSV.

3rd update, Changes for 'GatewaySpec', is basically one entity all related to GatewaySpec change (to be specific, Instances: 2 change) and we changed the Placement because of the multiple instances.
I postponed the CSV creation to the last commit... I will amend the said commit with CSV updations...

I re-ran the following make commands for verification, (on top of the above said commit)
make ocs-operator
make update-generated
make gen-latest-csv
but I couldn't see any CSV changes (except for the time timestamp updations). The reason, I could think of is that, these are internal specs and not something which we populate to a user.

@jarrpa , @umangachapagain , can you take look at the changes and let me know any further changes are required or not...

/retest

/retest

Code looks good overall. Now please add a unit test for newOBCStorageClass().

@jarrpa , added the new StorageClass into the tests, can you please take a look...

@jarrpa , I have made some refactoring to the initialization_reconciler_test.go file.
Added the tests for OBC storageclass as well.
Can you please take a look...

/retest

/override ci/prow/ocs-operator-e2e-aws

/override ci/prow/ocs-operator-e2e-aws


Trying to find a timeline for jdk21 @ eclipse-temurin

Question
As a temurin user (via containers), I am trying to find a timeline when I can expect to be running 21 with temurin?
I dont expect to find a ready-to-use version the day of GA, but for a way to track progress so that I can introduce 21 in my org once its finished with an idea when that is going to be.
So far tried looking into open/solved issues and/or PRs of these repos

https://github.com/adoptium/temurin-build
https://github.com/adoptium/containers
https://github.com/adoptium/jdk21u (not found, while https://github.com/adoptium/jdk20u exists)

also not here https://adoptium.net/temurin/releases/
so far I have only found this tag

https://github.com/adoptium/jdk/releases/tag/jdk-21-ga

Context
Java version: 21 is GA since 19.09.23

Your operating system and platform: Alpine container

oh well, just now found what I was looking for.
Took a bit till I landed in https://github.com/adoptium/adoptium and then found tickets relating to 21

https://github.com/adoptium/adoptium/issues/248
https://github.com/adoptium/adoptium/issues/249

I could still see there to be merit to this issue. A FAQ entry explaining a general timeline or philosophy, not even specific to any version or any date, might be useful. To me adoptium#248 is way too much into the weeds (and the target release date there is also not filled out; not to suggest that only a specific date would be satisfactory.

Since yesterday there is now also a banner stating that they wait for formal specification tests before releasing

25th of September 2023:We are awaiting access to the new Java 21's specification tests before formally releasing Temurin 21

Also, I found following here (although it was hard to spot as the numbers did not stick out from the text all that much)
https://adoptium.net/support/

there will be a short delay relative to these dates while we complete our extensive build and test cycles which can take up to three weeks. ... We always prioritise the most popular platforms which will typically appear within a few days of these dates.


updating hooks docs

There was an error in hooks>handle>ssr section using the old {request,response} instead of new {event,resolve}
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

Thanks!


[nfc] Update bazel to 7.0.1, clean up git-based dependencies and related documentation

Upstream PR to follow. I don't feel entirely sure about dropping shallow_since but if I interpret https://github.com/bazelbuild/bazel/issues/12857 correctly it will only be faster in edge cases while being slower otherwise as --depth 1 is not being used.

CC @jasnell here's the documentation cleanup based on v8 no longer being fetched using git.