[Feature Request] Create Higher-Level APIs for Plugins to switch contexts

Is your feature request related to a problem? Please describe
As a plugin developer, its necessary to differentiate between performing actions within 1) an authenticated user context and 2) outside of an authenticated user context.
When using the OpenSearch Security plugin, plugin developers use the threadPool.getThreadContext().stashContext() method to accomplish this as the security plugin uses headers in the ThreadContext to determine whether a transport action is being executed within the context of authenticated user or not.
stashContext allows a plugin to execute code in a fresh threadContext and the original context is restored upon closure.
stashContext is a low-level API that requires a plugin developer to have specific knowledge about the implementation of security. Ideally, there is a higher-level API that plugin developers can use to "switch contexts".
Note: Switching contexts is necessary for plugins that have system indices. Stashing the context is required before system index interaction.
Describe the solution you'd like
I am thinking about introducing a new parameter that is passed into plugin.createComponents. The new parameter would be an instance of an interface like ContextSwitcher:
public interface ContextSwitcher {
    ThreadContext.StoredContext switchContext();
}

There are 2 types of ContextSwitchers:

SystemContextSwitcher -> when calling switch context is will by default call markAsSystemContext (currently a public method of ThreadContext)
PluginContextSwitcher -> When stashing the context, this will also populate a special header (_plugin_execution_context) with the canonical class name of the class that extends Plugin. Canonical class name is chosen because its unique to every plugin and should match the key to this map.

This special header will have special protections to prevent it from being written to from higher-level ThreadContext APIs. A notion of FORBIDDEN_HEADERS would be introduced into the ThreadContext class which will prevent populating these headers directly.

Along with the ContextSwitcher, the ThreadContext class will be revisited to determine what level of access each method should have. For instance, the markAsSystemContext() method is currently public which means its accessible to plugins. I propose making markAsSystemContext and all stashContext methods to be package-private.
Related component
Plugins
Describe alternatives you've considered
Modify the NodeClient that is passed to plugins and expose select methods.
Additional context
stashContext nullifies all request + transient headers except for transient headers that have a registered propagator.

@reta @peternied I opened up another issue that discusses the issue and proposed solution on a higher-level. Let me know your thoughts. Does this capture enough detail or not enough?

As a plugin developer, it's necessary to differentiate between performing transport actions within 1) an authenticated user context and 2) outside of an authenticated user context.

2 as written doesn't make sense to me, is this operating as root, an admin, or as the plugin? I think it should be as the plugin and I need clear scenarios to understand the boundaries of what we are agreeing to build.
IMO Plugins should have ways to access their system index. Can you draw out what a plugin needs to do for this second scenario, how can it be fenced in such a way that allows for access controls to be added and shaped over time.
Let's not worry about the internal implementation in core but instead focused on the plugin developer experience, what APIs can be called that make this clear.

For example, what do you think about 2 node clients that can only be used one at a time. The user client and the plugin client, and unless inside a try block you cannot using the plugin client like so:
userClient.readIndex(...); // OK
pluginClient.readIndex(...); // throws CrossClientUsageException

try (pluginClient.activate()){
   pluginClient.readIndex(...); // OK
   userClient.readIndex(...); // throws CrossClientUsageException
} // deactivates the plugin client

Note: I don't like the side effect based relationship between the clients, but it's a starting point.
What do you think?

For example, what do you think about 2 node clients that can only be used one at a time.

Definitely, that looks nice and readable and I see a clear path to replacing threadContext.stashContext with pluginClient.activate().
In general, the access modifiers of the methods in ThreadContext need to be revisited. Many of those methods should not be public, especially the methods around stashing the thread context (stashContext, stashWithOrigin and stashAndMergeHeaders) and marking the context as system context (markAsSystemContext).

2 as written doesn't make sense to me, is this operating as root, an admin, or as the plugin?

For plugins, it would always operate in the context of the plugin. So if ISM switches contexts, then all transport actions would need to be authorized as if ISM itself is performing the transport action.
In the core repo, there are still instances of stashing the context (example). The core repo will retain the ability to switch contexts and operate as root, but that will be restricted for plugins.

[Triage - attendees 1 2]
@cwperks Thanks for creating this issue.

[Catch All Triage - 1, 2, 3]

Closing this issue now that https://github.com/opensearch-project/OpenSearch/pull/14630 is merged.


future-proof AZP_CACHING_CONTENT_FORMAT

@fadnavistanmay @owenhuynMSFT

@johnterickson - Can you resolve conflicts and we will review this change?

@fadnavistanmay or @owenhuynMSFT Can you rebase?

@fadnavistanmay or @owenhuynMSFT Can you rebase?

I resolved it via GH - UI. Let's wait and see 😬


DS-2971 Make bitstream description deletable again (5.x)

Via edit item it is now possible to delete the bitstream description for an item.

We need to recreate this PR against the "master" branch. There are no more planned 5.x releases at this time.

I can't reproduce this on master.

Descheduling this from 6.0.  It sounds like it may have been fixed during the 6.x Service API refactor (perhaps accidentally).  This patch may still be useful for individuals using 5.x.

Closing this PR, as the associated ticket was closed as "fixed".  This PR may still be useful for 5.x users, but has been fixed in 6.0.  See DS-2971 for more info.


Add --fast flag to skip Markdown validation

See https://github.com/executablebooks/mdformat/pull/49#issuecomment-702740026
Add a CLI flag for skipping Markdown validation.
I would name the flag --fast, --unsafe or --skip-validation.

Do you have a preference for which flag to add? I may have time to submit a PR by next week?

I think --unsafe and --skip-validation are both alright.
I always thought if things are eventually stable for years, it may be possible to change the default value of this check to off. If that happens we need the opposite flag. Then we'd have either --safe or --no-skip-validation out of which --safe seems much better. But that'd translate to safe = true/false in TOML which with --unsafe would slightly break the rule where CLI opt naming directly corresponds with TOML attribute naming....
Would --no-validate and validate = false/true be horrible? :smile: Either that or just --unsafe and unsafe = true/false, and don't worry about the future. Whoever implements can decide :smile:

I like --no-validate, but I would probably default to validate = true because plugins often break the AST (or maybe that's just me 😆 https://github.com/search?q=org%3AKyleKing+renders+to+different+HTML&type=issues)

I would probably prefer to default to validate = true

Yeah right now the default must definitely not change. And if it ever changes it may be useful for experimental plugins to be able to keep the validation on, similar to how they can turn validation off via CHANGES_AST already.

Closed by https://github.com/hukkin/mdformat/pull/496


Alternative Go version

Just in case if you're curious. It avoids using channels for communications and uses sync.WaitGroup instead. Results are collected via arrays and then aggregated inside a single goroutine. On my machine it's slightly faster than channel-based one.
package main

import "fmt"
import "time"
import "sync"

func skynet(out *int, num int, size int, div int, wg *sync.WaitGroup) {
	if size == 1 {
		*out = num
		wg.Done()
		return
	}

	var wgInner sync.WaitGroup
	wgInner.Add(div)
	results := make([]int, div)
	for i := 0; i < div; i++ {
		subNum := num + i*(size/div)
		go skynet(&results[i], subNum, size/div, div, &wgInner)
	}
	wgInner.Wait()
	var sum int
	for _, r := range results {
		sum += r
	}
	*out = sum
	wg.Done()
}

func main() {
	start := time.Now()
	var wg sync.WaitGroup
	wg.Add(1)
	var result int
	go skynet(&result, 0, 1000000, 10, &wg)
	wg.Wait()
	took := time.Since(start)
	fmt.Printf("Result: %d in %d ms.\n", result, took.Nanoseconds()/1e6)
}

@nsf I feel like channels are more idiomatic for communicating. @atemerev Do you believe these benchmarks should be a performance free for all pulling out all of the stops or should each language implementation strive to be idiomatic? Something in between?

I'm not implying that my version should be used instead of the one repo has. I just wrote it out of curiosity and sharing it here.

@nsf Awesome! Thanks for sharing it with everyone. I wasn't trying to attack, just wanted to clarify and help improve the benchmark.

Also you might want to include language versions in benchmark results

runtime.GOMAXPROCS(runtime.NumCPU())

func main() {
runtime.GOMAXPROCS(runtime.NumCPU())
start := time.Now()
var wg sync.WaitGroup
wg.Add(1)
var result int
go skynet(&result, 0, 1000000, 10, &wg)
wg.Wait()
took := time.Since(start)
fmt.Printf("Result: %d in %d ms.\n", result, took.Nanoseconds()/1e6)
}

func main() {
    runtime.GOMAXPROCS(runtime.NumCPU())
    start := time.Now()
    var wg sync.WaitGroup
    wg.Add(1)
    var result int
    go skynet(&result, 0, 1000000, 10, &wg)
    wg.Wait()
    took := time.Since(start)
    fmt.Printf("Result: %d in %d ms.\n", result, took.Nanoseconds()/1e6)
}


Add priorityClassName to CRDs

Fixes #687
Tested in my environment and working fine :)

I'm very unsure what I could have done to break the tests. I've just rebased this branch. Any help figuring it out would be great, thanks :)

it's most likely a ephemeral error and not related to your change, don't worry about it, the change as it is will get merged once we're ready


Question - goog.dom.query alternative

We were using goog.dom.query in preference to the native API because it supports :scope on IE11. I see that  goog.dom.query was deleted in 6d144d022e609d5e42e46357bcc9bc9d05945a53. I'm just curious if there's a recommended alternative?
Thanks!

You can replace it with document.querySelectorAll (or document.querySelector or parentElement.querySelectorAll, etc).  This is a drop-in replacement that's available in all browsers since ~IE8.  In migrating all of our Google-internal code off of it, I ran into maybe one or two subtle differences (out of thousands of usages), but they weren't too bad to fix once I figured out what was intended (but I don't remember the details, unfortunately).

We make use of :scope, which is not supported in IE11 via any of the querySelector methods. We use it to get elements that are the direct children of the container node, in cases where there might be recursive matches like a multi-level expanding dropdown.
Was :scope in use around Google, or did you have some workaround that made it unnecessary? I suppose we could add a unique ID to the container so that instead of > .select-option it becomes #new-id > .select-option.
Thanks for your thoughts


Building Node-RED Desktop v1.2.2 on macOS 10.15.7

Contrary to previous releases, Node-RED Desktop v1.2.2 isn't available as a binary for macOS.

Do you plan to release a binary for macOS?

So I try to build it by myself. I followed the procedure and faced some issues.
% npm install
% npm run build

><EMAIL_ADDRESS>build /Users/USER/Downloads/node-red-desktop-1.2.2
> tsc && node build.js

node_modules/ngrok/ngrok.d.ts:1:66 - error TS7016: Could not find a declaration file for module 'request'. '/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/request/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/request` if it exists or add a new declaration (.d.ts) file containing `declare module 'request';`

1 import { CoreOptions, Request, RequestAPI, RequiredUriUrl } from 'request';
                                                                   ~~~~~~~~~

Using the recommended command solved this first issue.
% npm i --save-dev @types/request

However, building failed with two errors.
% npm run build

Error #1 --------------------------------------------------------------------------------
TypeError: Cannot read property 'provider' of null
    at createUpdateInfoTasks (/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/app-builder-lib/src/publish/updateInfoBuilder.ts:110:44)

Error #2 --------------------------------------------------------------------------------
TypeError: Cannot read property 'provider' of null
    at createUpdateInfoTasks (/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/app-builder-lib/src/publish/updateInfoBuilder.ts:110:44)
    at throwError (/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/builder-util/src/asyncTaskManager.ts:90:11)
    at checkErrors (/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/builder-util/src/asyncTaskManager.ts:53:9)
    at AsyncTaskManager.awaitTasks (/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/builder-util/src/asyncTaskManager.ts:58:5)
    at PublishManager.awaitTasks (/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/app-builder-lib/src/publish/PublishManager.ts:210:28)
    at /Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/app-builder-lib/src/index.ts:94:32
    at executeFinally (/Users/USER/Downloads/node-red-desktop-1.2.2/node_modules/builder-util/src/promise.ts:25:9)
    at /Users/USER/Downloads/node-red-desktop-1.2.2/build.js:38:17

Thank you and best regards,

Hi @rei-vilo
Sorry for late response.
I don't encounter the above error.  (I used node v12.13.0 to build)
I will release v1.2.3(Node-RED 1.2.9) with Windows and Mac soon.

Thank you! Release v.1.2.3 works fine.


Plane Trips from Portugal (Continental) to Madeira or Azores

Plane Trips from Portugal (Continental) to Madeira or Azores

Why should we?
Why should we not?
Is it necessary?
Is it not necessary?
How much effort to apply realtime data?

Why should we? Because bus lines will have a connection to the remainder of all routes, avoiding their isolation;
Why should we not? Because catching a plane is not simple/fast/immediate/beginner friendly as catching a bus or a subway, for example.


Fix typo in prompt templates constructor

This PR fixes a typo in variable names in initialize_prompt_templates method.

Thank you very much @armmam !

@armmam Would you mind redoing this commit with under the name "fix: typo in prompt templates constructor" to align with our semantic release convention?

Yup, done


scheduler(ticdc): fix incorrect scheduling task counter

What problem does this PR solve?

Issue Number: close #9845
What is changed and how it works?
Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
`None`

/test dm-integration-test

/test dm-integration-test


How can I convert other datasets to fit the ROMP input?

Hello, thank you for your excellent job. I want to add another dataset, like MTC, into training datasets. However, I find the dataset files are complex in the romp/lib/dataset. Do I need to write a dataset file from scratch by myself considering the new dataset's parameters? Or do I have any convenient way to add new datasets?  Thank you.

I am afaid you have to add a new dataset file following
https://github.com/Arthur151/ROMP/blob/master/docs/train.md#training-guidance
Maybe you can follow the format of
https://github.com/Arthur151/ROMP/blob/master/romp/lib/dataset/mpi_inf_3dhp.py
as the template to properly pack_data and define get_image_info.

Thank you.


Fix: Pagination to consider limit value while .all() will return all records

Pagination fix
Problem?
Often times in production we don't want to return all matching records instead returning a paginated response based on values of limit and offset is desirable.
What is being fixed?
Calling .all() will keep returning all records matching the search criterion whereas if you set value of limit and then call .execute() with exhaust_results=False parameter, It will return number of records equal to value of limit.
Usage-
Let us consider 3 scenarios-
Scenario 1
model = Model.find(
    (condition 1) &
    (condition 2) &
    ....
    (condition n)
)
model.limit = 5
model.offset = 0
model.execute(exhaust_results=False)

This will return first 5 records matching search criterion.
Scenario 2
model = Model.find(
    (condition 1) &
    (condition 2) &
    ....
    (condition n)
)
model.execute()

This will return all records matching search criterion.
Scenario 3
model = Model.find(
    (condition 1) &
    (condition 2) &
    ....
    (condition n)
)
model.execute(exhaust_results=False)

This will return top 10 records matching search criterion because default value of limit is 10
How is it fixed?
To break away from loop executing the query a condition is added wherein if total number of fetched records is equal or greater than limit. (see file changes)

@simonprickett  - Any input is appreciated

@dvora-h can you please have a look?


space left

We need a way for the user to tell how much space is left on the mothership 6 drives. Maybe add this to the front page in the upper right. We just need to look at the % remaining in /mnt/nvmedata5 right now.

What would be the longest refresh interval that would be useful. As in we need to run a command on ms6 to get the information and probably don't want to run it every second!

How about every time something changed: a new scan is acquired or a scan is deleted? If that is harder than it sounds then maybe once every 1-5 minutes (Im not sure what would be considered too often). There also could be a button for the user to run it manually.

Good idea, we can come up with something that doesn't trash too much ...

Fixed in #620


Email template changes

@bsweger or @jworcestBAH

@nmonga91 done reviewing--can you re-merge dev into this branch to make sure the template fix from @jworcestBAH gets in there?

@bsweger the merge has been completed and please note the additional commit that brings a couple more changes to the email template.

Look good!


":contains" selector sometimes returns all parents instead of one

Hello team,
I've been using Goquery for several years and I love it, thanks for the good work!
For the first time I'm running into an issue I'm unable to solve though...
I'm trying to retrieve the surrounding element around some text.
So I'm using the :contains selector. But the latter seems to behave weirdly and sometimes selects all the parent elements instead the first parent only. It even sometimes invents elements...
Let me give you an example.
html := "
Julien, Developer

Martin, Developer
"
doc, _ := goquery.NewDocumentFromReader(strings.NewReader(html))
doc.Find(":contains('Developer')").Each(func(j int, s *goquery.Selection) {
    fmt.Println(goquery.NodeName(s))
}

The above returns:
html
body
div
#text
div
#text

While it should return:
div
div

Do you know if there's a way to bypass this weird behaviour?
Can you think of a better way to look for some text and then return the surrounding element?
Thank you very much!
EDIT: I think I would need a way to refine searches by text content, like Beautifulsoup does in Python, but not sure it's supported by Goquery: https://stackoverflow.com/questions/9007653/how-to-find-tag-with-particular-text-with-beautiful-soup/13348425

Salut Julien,
I'm not super familiar with :contains, but shouldn't that be containsOwn? I.e. the following (slightly modified) code does what you want:
func main() {
	const html = "
Julien, Developer

Martin, Developer
"
	doc, err := goquery.NewDocumentFromReader(strings.NewReader(html))
	if err != nil {
		log.Fatal(err)
	}
	doc.Find(":containsOwn('Developer')").Each(func(i int, s *goquery.Selection) {
		fmt.Println(i, goquery.NodeName(s), s.Text())
	})
}

// prints
// 0 div Julien, Developer
// 1 div Martin, Developer

I think :contains returns all nodes that contain that text, so every node does?
Hope this helps,
Martin

Oh, looks like :containsOwn is not even a jQuery selector, but a jsoup one, that somehow cascadia (the selector package used by goquery) decided to support. See https://jsoup.org/apidocs/org/jsoup/select/Selector.html
But yeah, from what I read, it seems like :contains behaves as expected.

Merci Martin !
Indeed :containsOwn perfectly works. Sorry I did not look into Cascadia's docs, but I will from now on.
Thanks again Martin ;)


Implement list of logged user repositories

https://developer.github.com/v3/repos/#list-your-repositories


cachable: make sure to clear caches between tests

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

We've been seeing some difficult to debug test failures recently related to not clearing some caches between tests. Normally we use the Cachable mixin to facilitate caching in classes and modules. I thought it'd be nice to automatically clear those caches between tests without having to create a list manually of all of the classes and modules that use this mixin.
This adds a registry for all modules and classes that cachable is included in. The registry allows us to programmatically clear all caches in between tests so that we don't forget to do that when adding a new class or refactoring code. The goal here is to reduce the number of flaky tests in the future. We only fill this registry when HOMEBREW_TESTS is set.
Marking draft to wait for discussion in https://github.com/Homebrew/brew/pull/16671 since this will depend on that.

I'm marking this as ready for review since it no longer changes any of the same files as https://github.com/Homebrew/brew/pull/16671 and should be useful whatever we decide to do there.


use getSignaturesForAddress, deprecate getConfirmedSignaturesForAddress2

note: the devnet api doesn't seem to support getSignaturesForAddress yet

Looks good! @gqln, would you mind running make format and make lint?


Make the TraceOptions Builder methods public for testing.

Codecov Report

Merging #247 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #247   +/-   ##
=========================================
  Coverage     94.54%   94.54%
  Complexity      456      456
=========================================
  Files            64       64
  Lines          1431     1431
  Branches        104      104
=========================================
  Hits           1353     1353
  Misses           51       51
  Partials         27       27

Impacted Files
Coverage Δ
Complexity Δ

...com/google/instrumentation/trace/TraceOptions.java
97.05% <ø> (ø)
18 <0> (ø)
:arrow_down:

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 937906b...21a8f3f. Read the comment docs.

Not related to this change, but you may also want to make one of the two abstract addAnnotation() on Span final, because it seems one can delegate to the other.

@bogdandrutu sorry for those last-minute requirements. Apparently I didn't think through the testing requirements when I reviewed the API. If you'd prefer the APIs that we made public today to be non-public, you could consider providing fake implementations for classes such as SpanFactory and SpanContext so that you can keep their constructors and construction parameters private. We probably won't have time to explore that option now, but we can annotate them @VisibleForTesting today and add javadoc saying that they might be turned package-private or protected in the future.


Diff not showing show-skipped info when using compare-to

Hello Team,
I don't know if i'm doing something wrong here...
Im using multi folders with a config file, comparing a feature branch with the main branch and posting a comment in a DevOps PR.
The output shows, as expected, the cost difference inside the feature itself (columns new and diff if its new module and new, previous and diff if modifying a module) and the cost of all modules (projects).
The report seems OK, and although both baseline and target branches breakdowns have the show-skipped info, the diff does not show the show-skipped data.
Is this expected or am i doing something wrong here?
Ex: infracost diff --path "VM-feature.json" --compare-to "VM-baseline.json" --show-skipped
Azure DevOps
yaml with infracost CLI tasks
Config-file with multi folders
Thank you for your help!

Thanks @RaZloR! I've confirmed that's a bug and added reproduction steps below.
$ git clone https://github.com/infracost/example-terraform

$ cd example-terraform

$ infracost breakdown --path . --format json --out-file infracost-baseline.json

$ vi main.tf and add this resource:

resource "google_apigee_instance" "apigee_instance" {
  name     = "tf-test"
  location = "us-central1"
  org_id   = "123"
}

$ infracost breakdown --path . --format json --out-file infracost.json

$ cat infracost.json | jq '.summary.unsupportedResourceCounts'
# NOTE that the unsupported resource is shown in the file.

$ infracost diff --path infracost.json --compare-to infracost-baseline.json --show-skipped
# NOTE the skipped resource is not shown.
#      the skipped resource should be shown, similar to what `infracost output --path infracost.json --show-skipped` does

Thank you @alikhajeh1 for your fast reply!
Looking forward for a fix.
Thank you

@RaZloR Thanks for the report, the fix will go out in the 0.10.17 release.

Hello @RaZloR the fix for this issue has been released as part of the v0.10.17 infracost CLI. Thanks for bringing this to our attention.


add fabric.properties to JetBrains

Since that is what it should be called now a days according to https://dev.twitter.com/fabric/android/integrating

Thanks!


[FEATURE] - upgrade to latest version, Kong and KIC

In this PR i'm upgrading kong OSS kong-gateway EE and kong ingress controller to the latest available version + some minor upgrades to READMEs and examples. The new version will be -> 2.8.1 to follow Kong versioning
Tasks:

[x] Upgrade KIC to 2.3.x
[x] Upgrade Kong to 2.8.x
[x] Align petstore examples
[x] Align README with new standard
[x] Check CI/CD tests

sounds good to me


personality chat npm package

is there a node.js version?

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

ID: f19cd48c-985a-9ab4-8514-b8f956320251
Version Independent ID: 776a690a-a866-6edd-4092-980e75c4ef36
Content: What is Project Personality Chat? - Azure Cognitive Services
Content Source: articles/cognitive-services/project-personality-chat/overview.md
Service: cognitive-services
GitHub Login: @noellelacharite
Microsoft Alias: nolachar

@madymantha Thanks for your feedback! We will investigate and update as appropriate.

@madymantha Sorry, we don't have a node.js version now.

@madymantha We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Core 1016 authentication project

@mthambipillai refactor-oom-protocol branch is now merged to master - you can change the base branch in this PR to master.


reload-page never works , gotopage also never works...

is it because reload-page and gotopage are isolated scope ?

Hmm, there is a passing test for this here:
https://github.com/begriffs/angular-paginate-anything/blob/master/test/paginate-anything-spec.js#L411-L421
Can you give me more information about your code and situation?

would you please give me more samples how to use reload-page ?

in template
<bgf-paginationpage="page" per-page="generalPerPage"
client-limit="clientLimit"
collection="gqs"
url = "generalPageUrl"
repload-page = "{{reloadPageFlag}}"
passive = 'false'
template-url="/templates/directive/paginate-anything.html">
</bgf-pagination>

In controller
SomeService.updateSomething({},function(data){
                    $scope.reloadPageFlag = true;
                })

It was my mistake.  repload-page = "reloadPageFlag", misspelling. repload.
However i found one more issue. reload page doesn't work several times....
It works only one time.

Maybe you have to toggle it from true to false and back to true in order to get another reload.

In your code, I saw it you already toggle it false.
$scope.$watch('reloadPage', function(newVal, oldVal) {
                        if($scope.passive === 'true') { return; }

                        if(newVal === true && oldVal === false) {
                            $scope.reloadPage = false;
                            requestRange({
                                from: $scope.page * $scope.perPage,
                                to: ($scope.page+1) * $scope.perPage - 1
                            });
                        }
                    });


Prevent background redraw for transparent widget (embedding wgpu inside druid)

Hi,
I am trying to write a small proof of concept of embedding a wgpu surface inside a druid app, as a custom widget. I've started druid yesterday and I am really liking this project, but would like to make sure it is possible to render a 3D view inside a desktop app. The typical use case is a 3D viewport with some 2D UI around it (think something like a game editor / Unity3D / UnrealEngine, or any CAD application, or some 3D modeller like Maya or Max).
I've started from the multiwin example and lightly modified druid for WindowHandle to implement the HasRawWindowHandle trait, which allow creating a wgpu instance from it (is that of interest for #891 by the way? the patch is 10 lines (Windows only)). Then I more or less copy-pasted the "cube" example of wgpu-rs into the multiwin example of druid.
Now it almost works, but it seems that some background redraw is still active, so I cannot get a stable image. When the mouse moves out and in of the window borders, or other repaint is triggered, I briefly see the 3D cube, but then immediately get back the normal 2D druid UI on top of it.
Does someone has any idea how I could fix this, or could point me in the direction of where widgets are cleared? I don't do that background repaint myself. I've tried with PaintCtx::paint_with_z_index(9999) but that doesn't work either.
Many thanks for any pointer! :)

I've just seen #1249 and changed theme::WINDOW_BACKGROUND_COLOR to (0,0,0,0) but this doesn't do anything in my case, presumably because the 3D clear from wgpu is clearing the window anyway. But it seems druid is still painting it.

The background is drawn at druid/src/window.rs:354. Does commenting it out help at all?

Thanks @jneem; no not really, I see a change (it flickers to black instead of dark gray) but there's still some bad interaction between wgpu and druid. So it's not a problem with the background. I need to dig into the wgpu rendering and the wgpu::Queue to understand what is being submitted when.

Sadly I think this is a composition issue. The way I patched up things, wgpu reuses the same HWND created by Druid:

wgpu creates its own composition pipeline (I don't know the details) from the HWND
Druid (Windows; piet-direct2d) creates some DXGI surface from the HWND it created. Actually I'm not quite sure exactly of the details because I looked at the code for 1 hour and I am now more confused than before; I've seen some DXGI swapchain, some HWND, some Direct2D, some Direct3D, ... a bit of everything.

Anyway I think the two composition pipelines are targeting the same HWND and rendering in parallel, fighting to present to the window.
One workaround I am thinking of trying when I have time is to create a child window (HWND) inside the Druid one, and use that one for wgpu. I think that could possibly work around the issue. Otherwise unfortunately I don't see how to do for now, except waiting for piet to have a wgpu backend that is exposed and can be accessed for manual rendering.

I'm very interested in wgpu, but think that having embedded 3d widgets is a pretty hard problem. Either you use wgpu for everything, which I think is fine (but involves building that), or you start having to expose composition up through the widget hierarchy, so for example a wgpu inside a scroll view can get translated and clipped appropriately as it scrolls. Doing that in a cross-platform way is hard. I'm not sure there's a simple answer to this, or what might be the best path forward.
See #891 for more discussion.

Yes I've read #891 actually before starting my experiment. This is why I was trying with wgpu, and why I've tried a simpler workaround than using wgpu for everything, which I agree is probably the best way but also the most involved in terms of workload. Instead I was trying to come up with a (temporary) workaround in the meantime, even if that means limited features (I am not interested in scrolling personally, and I think it would be fine anyway if an embedded 3D view doesn't handle it, as opposed to not having any solution).
I've looked at how Qt does it nowadays and it is interesting to see they went the child window approach back in 2013 (I couldn't find anything more recent on the subject; I think this is still the recommended approach), which is my next plan for when I have time. This delegates the clipping to the OS compositor by leveraging the parent-child relationship of the native windows (HWND on Windows). Then this native child window  (with no border etc.) can be embedded via a custom Druid widget which controls its position and size.
In fact the Qt documentation has a list of restrictions in this case, and they explicitly mention the scrolling one (highlights mine):

The window container is attached as a native child window to the toplevel window it is a child of. When a window container is used as a child of a QAbstractScrollArea or QMdiArea, it will create a native window for every widget in its parent chain to allow for proper stacking and clipping in this use case. [...] Applications with many native child windows may suffer from performance issues.

I know this approach is also used sometimes when e.g. the inner window is rendered by a separate process (for example, a game engine) to avoid crashes to the renderer affecting the stability of the surrounding application. This is doable on Windows for sure, and I believe on other OSes too.
So I think this may be a more feasible approach short term, even if it means it has limitations compared to other widgets. I'll see if I can try it when I have some spare time. Would you be open for Druid to take this kind of change? I appreciate this somehow goes against the philosophy of "druid is safe high-level abstraction, druid-shell contains the low-level platform-dependent implementation", since it would leak the native platform handle to end users for them to embed their content (unless the change is restricted to embedding wgpu only, in which case the widget can act as an abstraction barrier).

Thanks for looking into Qt, I think that's good background.
Overall I am open to landing this in Druid, as I think it's good to get experience; it's clearly a use case people care about. I think if we're up front about the limitations and don't let it constrain our development too much, it can be ok. We're already partly down the path of doing subwindows for things like menus.
I also think it's a fair amount of work, especially as it has to be rethought on different platforms, and even within Windows, as subwindow is compatible with Windows 7, but "swapchain for composition" might be a richer and more performant experience on 10. Similarly for X11 and Wayland on Linux. But if you're willing to take it on, I certainly won't stop you :)

I am willing to try it on Windows 10 for now, see if that works at all :)

If you'd like to try things the other way around, both Iced and KAS are WGPU-native. Iced supports embedded usage (GUIs inside a WGPU app) and KAS supports custom WGPU render pipes (embedded WGPU). (Yes, this is a shameless plug — don't let me stop you working on Druid.)

@dhardy thank you for the shameless plug of good info! I had a very quick look at Iced, and didn't know KAS. I am going to continue for now with Druid because I really like its design, somewhat (I personally find) in-between event-based UI (Qt style / React) and gaming style "immediate-mode UI" (no state inside widgets). So I'm really curious to see if I can overcome that 3D limitation and try a simple 2D+3D app with that Druid approach of embedding the data inside the widgets.
As for progress, I struggled quite some time trying to drill a hole into that druid-shell abstraction, but I think I've finally found a way. No doubt I broke stuffs in the process, but at least I got that:

Note how the wgpu native child window renders over its parent correctly, thanks to (I think) WS_CLIPCHILDREN set on the parent.
This is a prototype; don't mind the wrong aspect ratio, the native child window position/size are hard-coded.
The way things roughly work:

Added some sys::NEW_NATIVE_WINDOW command to submit the creation of a native child window during the LifeCycle::WidgetAdded event on the parent. Added LifeCycleCtx::new_native_window() for that.
The NEW_NATIVE_WINDOW is handled with a new AppState<T>::build_native_child_window() which skips some of the parts of AppState<T>::build_native_window() that are irrelevant (menu, app title).
Added some Event::NativeWindowConnected(NativeWindowHandle) event similar to the WindowConnected one but only for native child windows.
Added DruidHandler<T>::parent_window_id: Option<WindowId> as a hack because the child window reuses the parent's message proc, so need its ID to dispatch the new NativeWindowConnected.

DruidHandler<T>::connect() is hacked to check that new parent_window_id and dispatch the NativeWindowConnected instead of the WindowConnected one. There's no proper Window<T> for child windows.

Added WindowBuilder::parent: Option<WindowRef> to store in the window builder the HWND of the parent if the native window is a child one. This is the main switch in build() to decide which styles to apply to the native window : WS_OVERLAPPED | WS_CLIPCHILDREN for top-level ones, vs. WS_CHILD | WS_VISIBLE for child ones.

Update and food for thought:

WS_CLIPCHILDREN doesn't work, or at least is probably helpful to avoid unnecessary drawing (will exclude the child rect from Windows native invalid rects) but not sufficient to avoid overlapping. The reason I think is that the "present" op of Piet/Direct2D is done in parallel with the one of wgpu, resulting in non-deterministic order; sometimes the wgpu content appears, sometimes not.
To overcome this, probably we need to invoke the wgpu present op after the Piet one by adding some after_paint() callback to Widget for example.
Child window management is an issue, and with it positioning. The current layout process only passes down the size of the area to paint, internally setting the origin to the Piet painter, so there's no easy way to automatically move the native child window to its position when e.g. the wgpu view widget is a child of a flex.
Currently I reuse the same WinHandler for both parent and child; this poses some issues (some events needs to be handled differently) but also has some advantages (don't need to rewrite a full handler with most event handled the same way). Not sure what the best design is here.

So I implemented the after_paint() callback which is invoked once the present operation of Piet is submitted, and is used to submit the wgpu rendering to ensure it appears on top of the Piet one (and so, a natural restriction is that the WgpuView widget I wrote cannot be obscured by other widgets or contents, except system menus). I also added some auto-layout for the child window, which hooks into set_origin() as I believe this is always called after the widget layout was calculated by its parent. That all seems to work:

I need to clean-up things a bit and I'll try to at least push a branch on a fork, or even maybe make a draft PR to discuss the code directly. There's only Windows support, but once the bits are in place for child windows I believe this should be easy to replicate for other platforms.

So I implemented the after_paint() callback which is invoked once the present operation of Piet is submitted, and is used to submit the wgpu rendering to ensure it appears on top of the Piet one (and so, a natural restriction is that the WgpuView widget I wrote cannot be obscured by other widgets or contents, except system menus). I also added some auto-layout for the child window, which hooks into set_origin() as I believe this is always called after the widget layout was calculated by its parent. That all seems to work:

I need to clean-up things a bit and I'll try to at least push a branch on a fork, or even maybe make a draft PR to discuss the code directly. There's only Windows support, but once the bits are in place for child windows I believe this should be easy to replicate for other platforms.

I still have some issue to set the origin. I had temporarily overlooked it but now would like to fix it, because this breaks as soon as the wgpu view widget is not a direct child of the root one. The native child window origin needs to be the position of that window relative to its parent window, which in general is not its parent widget but another ancestor. However since set_origin() is called as part of the layout() of the parent after the layout() of its children, at this point the origin of the parent widget itself is not yet know until its own layout() call returns. The only way I see this would work would be to do another traversal after layout() to re-descend into all widgets having a native child window, accumulating the ancestor's origins along the way now that the full layout of all widgets is done.
Any thought or guidance on this @jneem or @raphlinus ?
If it makes more sense with pseudo-code, now I have:
parent.layout() {
  child.layout();
  child.set_origin(origin) {
    self.origin = origin;
    if is_native {
      set_native_origin(child_hwnd, self.origin); //< This is wrong if parent is not a window
    }
  }
}

And I think we'd need instead:
parent.layout() {
  child.layout();
  child.set_origin(origin) {
    self.origin = origin;
  }
}

parent.post_layout(native_origin) {
  native_origin += self.origin;
  child.post_layout(native_origin) {
     native_origin += self.origin;
     if is_native {
       set_native_origin(child_hwnd, native_origin); //< Now this is properly accumulated from ancestor window
    }
  }
``

I still have some issue to set the origin. I had temporarily overlooked it but now would like to fix it, because this breaks as soon as the wgpu view widget is not a direct child of the root one. The native child window origin needs to be the position of that window relative to its parent window, which in general is not its parent widget but another ancestor. However since set_origin() is called as part of the layout() of the parent after the layout() of its children, at this point the origin of the parent widget itself is not yet know until its own layout() call returns. The only way I see this would work would be to do another traversal after layout() to re-descend into all widgets having a native child window, accumulating the ancestor's origins along the way now that the full layout of all widgets is done.
Any thought or guidance on this @jneem or @raphlinus ?
If it makes more sense with pseudo-code, now I have:
parent.layout() {
  child.layout();
  child.set_origin(origin) {
    self.origin = origin;
    if is_native {
      set_native_origin(child_hwnd, self.origin); //< This is wrong if parent is not a window
    }
  }
}

And I think we'd need instead:
parent.layout() {
  child.layout();
  child.set_origin(origin) {
    self.origin = origin;
  }
}

parent.post_layout(native_origin) {
  native_origin += self.origin;
  child.post_layout(native_origin) {
     native_origin += self.origin;
     if is_native {
       set_native_origin(child_hwnd, native_origin); //< Now this is properly accumulated from ancestor window
    }
  }
``

Latest version pushed to fork branch wgpu_v5 for reference : https://github.com/djeedai/druid/commit/9d4db197612cd8fa2ba1ffd046005903550caa0b.
The remaining issue about the native origin is there : https://github.com/djeedai/druid/commit/9d4db197612cd8fa2ba1ffd046005903550caa0b#diff-18ee77c070e42a5dfbf2a1f99a1f1afdeff1a92a5aeb1ebfed22d112154edef6R294

Latest version pushed to fork branch wgpu_v5 for reference : https://github.com/djeedai/druid/commit/9d4db197612cd8fa2ba1ffd046005903550caa0b.
The remaining issue about the native origin is there : https://github.com/djeedai/druid/commit/9d4db197612cd8fa2ba1ffd046005903550caa0b#diff-18ee77c070e42a5dfbf2a1f99a1f1afdeff1a92a5aeb1ebfed22d112154edef6R294

What if we were to have the window-relative position available in PaintCtx?

That's a good idea, provided any widget that moves always receives a paint event for that move. I'll see when I can find some time if I can try it that way.

That's a good idea, provided any widget that moves always receives a paint event for that move. I'll see when I can find some time if I can try it that way.

Something like that maybe? 😜

Note the delay in redraw and the visible positioning artifacts when moving/sizing. This is because accessing the native origin (= window-relative position) in paint() from the PaintCtx means the window will only move after the next message loop pumped the native move/resize event whereas Piet paints the widgets immediately for this frame. With this hack there's not much we can do about it.

Something like that maybe? 😜

Note the delay in redraw and the visible positioning artifacts when moving/sizing. This is because accessing the native origin (= window-relative position) in paint() from the PaintCtx means the window will only move after the next message loop pumped the native move/resize event whereas Piet paints the widgets immediately for this frame. With this hack there's not much we can do about it.

I opened a PR. It's probably not going to be mergeable as is, but should be a good base for further discussion on the code itself. We can then break down individual changes if needed for easier review and I can make separate PRs for those. There's also the (newly discovered 😥) issue of sub-window seemingly implementing the same thing as I was working on with child native windows, and which was pushed already, so would require more work to be adapted to (if it does what I think it does; I didn't look).

I opened a PR. It's probably not going to be mergeable as is, but should be a good base for further discussion on the code itself. We can then break down individual changes if needed for easier review and I can make separate PRs for those. There's also the (newly discovered 😥) issue of sub-window seemingly implementing the same thing as I was working on with child native windows, and which was pushed already, so would require more work to be adapted to (if it does what I think it does; I didn't look).


Opencast breaks if booted before Elastic-/OpenSearch

Describe the bug
When starting Opencast before Elastic-/OpenSearch, multiple errors occur, and Opencast fails to start even if the index service starts afterwards. This issue was reported following a power failure at an institution.
To Reproduce

Start Opencast without Elastic-/OpenSearch running.
Observe that Opencast fails to start (check the logs or attempt to log in).
Start Elastic-/OpenSearch.
Notice that Opencast still doesn't start properly.

Expected behavior

Start Opencast (index service didn't boot yet).
Opencast detects the missing connection to the index service and waits.
Elastic-/OpenSearch starts.
Opencast connects to Elastic-/OpenSearch and completes its startup process.

Hopefully, this will be fixed by #5944 (once I complete the PR).


fix: NetSuite - 'Select existing' invoice item option isn't highlighted when selected.

Details

Fixed Issues
$ https://github.com/Expensify/App/issues/46767
PROPOSAL: https://github.com/Expensify/App/issues/46767#issuecomment-2267143042
Tests

Click on FAB - New workspace
Enable "Accounting" in the "More features" page.
Navigate to "Accounting"
Connect to NetSuite and upgrade the workspace to Control when asked
Wait for the sync to finish
Navigate to Export - Invoice item
Tap on Select existing
Verify that the selected option is highlighted.

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

Offline tests

Click on FAB - New workspace
Enable "Accounting" in the "More features" page.
Navigate to "Accounting"
Connect to NetSuite and upgrade the workspace to Control when asked
Wait for the sync to finish
Navigate to Export - Invoice item
Tap on Select existing
Verify that the selected option is highlighted.

QA Steps

Click on FAB - New workspace
Enable "Accounting" in the "More features" page.
Navigate to "Accounting"
Connect to NetSuite and upgrade the workspace to Control when asked
Wait for the sync to finish
Navigate to Export - Invoice item
Tap on Select existing
Verify that the selected option is highlighted.

[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/da39ef15-a880-42bf-be08-92f5b39df748

Android: mWeb Chrome
https://github.com/user-attachments/assets/f9b7bb5a-ead9-4995-8f23-fb2bca309853

iOS: Native
https://github.com/user-attachments/assets/0e094f20-3a67-4819-b38d-9838c2c74c30

iOS: mWeb Safari
https://github.com/user-attachments/assets/5070781f-22cd-4a6f-a98a-e26416833164

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/153853fb-0d9f-4554-9d73-4cf817149b1b

MacOS: Desktop
https://github.com/user-attachments/assets/84bf381f-ddcc-470f-9fa2-65d4e247af78

: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/AndrewGable in version: 9.0.21-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 9.0.21-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
failure ❌

🚀 Deployed to production by https://github.com/Beamanator in version: 9.0.21-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


[DCOS_OSS-4343] account for recovery plan completing quickly

when waiting for a kicked off recovery plan, plan could already have completed

ack makes sense @elezar this may be an actual issue then where recovery plan isnt getting kicked off, I assumed that the recovery plan had completed


Add Input to Connect the Dots

@rahulbot and I are discussing the activity and we'd love to include a copy and paste option so that people can copy from either Google Sheet or Excel doc and use that as input to connect the Dots. This is consistent with WordCounter and SameDiff (where you can just paste text as input).
This feature would parse tab-delimited text (which is how Google Sheets and Excel do the copy) and use that as input to Connect the Dots.
@s2tephen do you think you could work this in?

Doesn't address the edge case of actual tabs within the data, i.e.
"source"\t"target"
"node"\t"node\twith\ttabs"

It's pretty low-priority so I'll come back and follow up on this scenario later.


Add styles to "Prevent Duplicate Submission" page

Blocked on mocks in #7987

Don't need a full page. Just a modal: https://www.figma.com/design/RmhVJCLgAKWGENJLWWAtNS/CiviForm%3A-Components%2C-Styles?node-id=3671-22538&m=dev


updated blog entries added 6th post

👷 Deploy Preview for joharehawkinslofthouse processing.

Name
Link

🔨 Latest commit
45819f9cbf63643a7f639d2129143d8fd9769d48

🔍 Latest deploy log
https://app.netlify.com/sites/joharehawkinslofthouse/deploys/661847b86917240008c9d63d


Autoplay HLS Live VideoJS 7

I am trying to get Google IMA Pre-roll or any ads to work with my live HLS feed... The ad triggers but then the video doesn't autoplay. Console doesn't show any errors.
https://codepen.io/terrafox/pen/27fc73aba1c2823370f1c84c872e8965/

If I git play... the video plays... but it doesn't autoplay... what am I missing?

Are you sure that your videojs player is set up to play HLS content? What happens if you try to play your stream without ads?

Yes. And like I said, just hit play and it plays, it just doesn't autoplay after the ad.

Delete lines 16,17 and 18 in codepen (link above) to remove the videojs-ima scripts. Then the video plays just fine.

I did a bunch of digging on this one, and ultimately it comes down to some logic in contrib-ads. Our plugin assumes that endLinearAdMode will ultimately result in a call to play() on the player. The contrib-ads implementation assumes that live streams continue to play in the background during ad breaks, and as such, don't call play on the content player in endLinearAdMode.
In adBreak.end():
if (!player.ads.shouldPlayContentBehindAd(player)) {
    snapshot.restorePlayerSnapshot(player, player.ads.snapshot);
}

and in plugin.js:
shouldPlayContentBehindAd(somePlayer) {
      return !videojs.browser.IS_IOS &&
             !videojs.browser.IS_ANDROID &&
             somePlayer.duration() === Infinity; // Here's the issue - if the content is live, assume it kept playing during the ad break
    },

So when we call endLinearAdMode() after the pre-roll, we expect that to result in a call to play() on the video player, and it doesn't.
@incompl, any tips on how to handle this?

The live video support in contrib-ads is designed for ID3 cuepoints. Support for prerolls before live videos would need to be carefully planned and built from scratch. It's on the list of things we'd like to do, but for now, I wouldn't expect it to work.

@incompl will I confuse contrib-ads if I call play() on the vjs player from within my plugin? In the short term we could add a new option to videojs-ima, isLiveStream or something like that, which will call play() on the vjs player when the pre-roll ends. I could call it after endLinearAdMode(), so hopefully it won't mess with contrib-ads.

I think what I'd like to do in contrib-ads is have the current behavior (live ads on metadata cuepoints while live stream plays muted behind ads) be an option, and have the default behavior be useful for prerolls before live streams, since that seems to be what most people want. Does that make sense?

That is exactly what I am trying to achieve.. Preroll before the livestream..

My two cents: calling play() after endLinearAdMode() (and pause() before startLinearAdMode()) does not break anything (atleast I never saw any issue yet). I use it just for sure and because both methods are Promise-based so multiple calls should be safe..

Did this issue every get any attention?

@mrtucker videojs-contrib-ads 6.5.0 introduced the liveCuePoints feature to address this scenario. I'm not sure if videojs-ima has been updated to use it or how much updating would be needed.
Docs: http://videojs.github.io/videojs-contrib-ads/integrator/options.html

Hi @deeperid,
I'm taking a look into this issue. Did you ever find a solution to your issue?


[Site] The site's footer could use an update to 2024

Current State of the Service Mesh Patterns site

Desired State of the Service Mesh Patterns site

Contributor Resources
This website uses React and GitHub Pages. Site content is found under the master branch.

See the Contributing to Service Mesh Patterns Website section of the readme.md and other contributing instructions, too.
Layer5 Brand Kit
📑 Service Mesh Patterns in Meshery Catalog
📖 Service Mesh Patterns Book
🎨 Wireframes and designs for Layer5 site in Figma (open invite).
📑 Fill-in the Layer5 Community Member Form and join the Layer5 Community Slack for access.
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@jameshorton2337  has this issue already been worked on

May I work on this?


About  cocotest_bu_fc.tar file

I download cocotest_bu_fc.tar, the number of the .npy files is 81435, not 40755.   In cocotest.json file, the number of images is 40775.  Why are their numbers inconsistent？

I believe 40755 comes from 2014 test, and 81435 comes from 2015 test. I forgot which one is actually the test for coco captioning.

I think 2014 is for captioning. So the cocotest is correct. The tar file contains some useless ones.


Revert "Totally undo changes for 10494. Revert once that is committed."

This reverts commit 5bfc5937c931998918a62a896a7bbc575c4d439c.
Do not merge until 10494 is merged.

10494 committed. Merging this now.


fix: revamp page

@juaoose yeah getting those to be align would be nice, though im unsure how to even do that


[Windows] Modify What Counts as a Regular File

Reparse points should be checked to ensure they are actually symlinks
A regular file may not have FILE_ATTRIBUTE_REGULAR set. It may have
alternative attributes like FILE_ATTRIBUTE_ARCHIVE or
FILE_ATTRIUBTE_HIDDDEN and should still count as a regular file.

@swift-ci please test and merge


tag

can you please add tag, such as v1.0.0
https://github.com/yapingcat/gomedia/tags

could you tell me the reason？


Attiny 0/1 series

Is there any chance you can support the new Attiny 0/1 series?
ADMUX is not defined (in the Arduino IDE at least).

Hi Simone,
I currently don't have time to work on adding support for new chips. That said, if you (or someone else) want to work on it, I'd be happy to accept pull requests 😉
Cheers

Seems like this should do it?
https://github.com/SpenceKonde/ADCTouch/tree/master/src


Process definition API

Hi,
I've discovered xarray-simlab recently and it has caught my attention.
The project looks very promising: I'm using more and more xarray in my models and a framework helping the assembling and running of models could help a lot my workflow.
These days, I mostly work with frequency-domain models, but I guess it would be easy to extend xarray-simlab to this kind of models. They are actually simpler than the time dependent ones.
After reading the doc and playing with some toy cases, I'd like to share some feedback about the API.
Hopefully, the issue tracker is not such a bad place for that.
I'm very impressed by the implementation, in particular the automatic assembling of the processes in a model. The integration with xarray is quite promising. The efforts on the documentation and the availability of the package are also great!
However, I am not totally convinced by the way the processes are defined.
Let's consider the example from the tutorial.
The ProfileU and u_vars abstractions were not very clear to me, so I rewrote them in the framework of conservation laws, with which I'm more familiar:
@xs.process
class EulerForwardTimeIntegration:
    fluxes = xs.group('fluxes')
    u = xs.variable(dims='x', intent='inout', description='conserved quantity')

    def run_step(self, dt):
        self.sum_of_fluxes = dt * sum(self.fluxes)
                                    # ^ Note that you don't need a generator here

    def finalize_step(self):
        self.u += self.sum_of_fluxes

@xs.process
class UpwindAdvectionFlux:
    v = xs.variable(description='velocity', intent='in')
    dx = xs.foreign(UniformGrid1D, 'dx')

    u = xs.foreign(EulerForwardTimeIntegration, 'u', intent='in')
    flux = xs.variable(dims='x', intent='out', group='fluxes')

    def run_step(self, dt):
        if self.v > 0.0:
            self.flux = self.v * (np.roll(self.u, 1) - self.u)/self.dx
        else:
            self.flux = self.v * (self.u - np.roll(self.u, -1))/self.dx

The full code is here.
I love the modularity of the design, allowing me to easily replace the advection term by another one or to add more of them.
However, I was not able to easily modify the time integration process to have a second order scheme such as:
@xs.process
class RK2TimeIntegration:
    fluxes = xs.group('fluxes')
    u = xs.variable(dims='x', intent='inout', description='conserved quantity')

    def run_step(self, dt):
        predicted_u = self.u + dt * sum(self.fluxes)
        # Missing something like: predicted_fluxes = Flux(predicted_u)
        self.next_u = (self.u + predicted_u)/2 + dt/2 * sum(predicted_fluxes)

    def finalize_step(self):
        self.u = self.next_u

To do that, I would have to create new advection flux classes:

The explicit reference to EulerForwardTimeIntegration in the foreign variable of UpwindAdvectionFlux is not a big problem. It could be possible to define this kind of linking in another way, for instance at model creation.
What bothers me more is that I would have to add in all Flux classes an expression mapping predicted_u to predicted_flux which would be the same as the one mapping u to flux. Or in other words, the process UpwindAdvectionFlux should be a function accepting other arguments than u.

And this last point illustrates my general feeling about the current API: most of the process classes could be rewritten as functions, and maybe (functional programming aficionado speaking) they should.
The wrapping around attrs is quite nice but the xs.process are not data holders but functions, and the xs.variable are functions inputs and outputs with annotations.
So, maybe the best way to define the processes is to define functions.
The metadata on the variables could be passed by the docstring or the type annotations, e.g.:
def upwind_advection_flux(
        u: Variable(dims=("x",), name='u'),
        v: float,
        dx: float,
) -> Variable(dims=("x",), name='flux'):
    if v > 0.0:
        return v * (np.roll(u, 1) - u)/dx
    else:
        return v * (u - np.roll(u, -1))/dx

I made a mock-up of the whole model here.
The code would be (in my humble opinion) both more flexible and more secure.
Indeed, the processes could be easily unit-tested, unlike the current process class.
I don't know exactly how the model builder works, but it should still have enough clues to link the processes together.
Note finally that this framework would be easily extendable to other kind of models than the time-dependent ones.
These were my two cents. I'd be happy to discuss it further if you want.
Cheers,

Hi @mancellin,
Many thanks for your detailed feedback! I try below to give some thoughts on each topic you've mentioned:
Doc enhancement / process naming

Let's consider the example from the tutorial. The ProfileU and u_vars abstractions were not very clear to me, so I rewrote them in the framework of conservation laws, with which I'm more familiar

I agree that this example from the tutorial could be improved. The code you have rewritten is clearer at several places, so I'd be very pleased if you could put this together in a PR!
On a same note, I've often found it difficult to find a good name for a process. Although it's natural to choose a name that describe what the process does, sometimes it doesn't work very well. In your example, EulerForwardTimeIntegration / time_scheme is explicit, but then when you use the xarray extension you end up with a variable named time_scheme__u in your input/output datasets, which is not very meaningful. A name like profile__u is slightly better to understand IMO, especially when the dataset is saved and loaded later in another context.
Support advanced time stepping

I was not able to easily modify the time integration process to have a second order scheme

I admit that I haven't really considered time schemes like RK2 when working on the design of this modelling framework.
One limitation is that by design no cycle is allowed in the graph of process dependencies. As a workaround, you could duplicate process classes (both flux and time integration) to implement each step of the RK2 scheme. You could also use class inheritance so that you don't need to duplicate all the code but just re-define u and flux.  I agree that this workaround is not ideal, though, and it's still quite laborious , e.g., if you want to include a lot of different "flux" process classes.

it could be possible to define this kind of linking in another way, for instance at model creation

I'm very open to any suggestion to improve the situation! That said, I think that the linking between processes should  remain automatic as much as possible (That's a core feature of the framework)!
Define processes as functions
I haven't really thought about that but I like the idea!
Process classes are still useful, though. I have a few use cases where a process holds some data, e.g., some working arrays that are allocated at the beginning of a simulation and updated later, some state variables recorded for the last n time steps or complex objects from wrapped code dealing with more than one variable... Classes are also useful to implement some variables computed "on-demand".
In cases where a process doesn't hold any data, I agree that using functions would be simpler and much easier to test!
I think that both classes and functions might co-exist.
I don't see any major implementation issue. We could decorate those functions like we do for classes to extract/handle/stick all the information needed to build models. Function arguments consist of variables with intent=in and the returned value(s) are related to variable(s) with intent=out (intent=inout is not supported with functions).
My main concern is that we'll probably have to maintain two different systems for declaring variables in processes, e.g., attr.ib wrappers for class variables and typing derived classes for annotated functions.
Time-independent models

this framework would be easily extendable to other kind of models than the time-dependent ones.

Yes that's definitely the aim of this framework: to be as generic as possible.
If we support both classes and functions for processes, maybe a run method in process classes could help for better clarity when used in time-independent models? The general order of simulation steps would be initialize -> n_steps*[run_step -> finalize_step] -> run -> finalize. Implementing the related methods is entirely optional in a process class, so it’s easy to just ignore all methods but the .run() one. For process functions, an argument to the decorator would help defining the simulation step (run would be the default one?).

Hi @benbovy,
Thanks for your answer. Below some comments:
Doc enhancement / process naming

On a same note, I've often found it difficult to find a good name for a process. Although it's natural to choose a name that describe what the process does, sometimes it doesn't work very well. In your example, EulerForwardTimeIntegration / time_scheme is explicit, but then when you use the xarray extension you end up with a variable named time_scheme__u in your input/output datasets, which is not very meaningful. A name like profile__u is slightly better to understand IMO, especially when the dataset is saved and loaded later in another context.

Ok, I understand better the ProfileU process now. It is meant to be a frame for the variable u and its role as time integrator is kind of a coincidence.  Maybe the problem here is that u is shared by several processes and does not really need to belong to any process in particular.
Process linking

I think that the linking between processes should remain automatic as much as possible (That's a core feature of the framework)!

I totally agree. The builder should be able to guess which output to plug on each input, based on the shape, physical unit or name of the variables.
My critic of the current implementation is that writing explicitly that the input of a process should come from another process (in xs.foreign) hinders the modularity. It could be necessary in some cases: for instance when there is too many variables and not enough metadata to distinguish them. But then, it would be better to make the link as an option to the model builder rather than hard-coded in the process.
Define processes as functions

Process classes are still useful, though. I have a few use cases where a process holds some data, e.g., some working arrays that are allocated at the beginning of a simulation and updated later, some state variables recorded for the last n time steps or complex objects from wrapped code dealing with more than one variable...

Could you make those classes callables? For instance:
@process
class InitialGaussianProfile:
    loc = Variable(kind='position', description='location of initial profile')
    width = Variable(kind='length', description='width of initial profile')

    def __call__(self, x: Variable[kind='position']) -> Variable[dims=('x',), kind='u']:
        return np.exp(-1 / self.width**2 * (x - self.loc)**2)

So you have basically a function with attributes.
Note that it solves the naming problem by separating the private parameters that define a process and the variables that are just going through it.
Other time stepping or time-independent models

One limitation is that by design no cycle is allowed in the graph of process dependencies.

My suggestion is to have process taking subprocesses as arguments. It complexifies the implementation of the model builder and the graph representation, but I don't see any other way to assemble complex models in a generic framework without dependencies cycles.

The general order of simulation steps would be initialize -> n_steps*[run_step -> finalize_step] -> run -> finalize. Implementing the related methods is entirely optional in a process class, so it’s easy to just ignore all methods but the .run() one.

The time variable would then be a normal variable used it in a "metaprocess" taking processes as arguments. That's what I tried to do in my function-based mockup.
The "standard library" of xsimlab could then come with a generic process of the form:
@process
class TimeDependentSimulation:
    step_runners: List[Process]

    def __call__(self, clock: Variable[dims=('t',)], ...: ...) -> ...:
        for t in clock:
            for run_step in step_runners:
                ... = run_step(...)
        return ...

model = Model(
    {
    some_initialization_process,
    TimeDependentSimulation(step_runners=[some_function, ...]),
    some_time_independent_process,
    ...
    }
    )

And the model would now have just a single run step.
The problem is to figure out how to make the dependancy graph when you have processes containing other processes. Maybe this is a bit too complicated and your solution is better in the short term.

Maybe the problem here is that u is shared by several processes and does not really need to belong to any process in particular.

Actually, nothing prevents the user from creating a "process" class that only declares one or more variables without doing any computation. Such classes could be abstract (to be subclassed) or could serve as a glue (i.e., declare variable aliases) between two sets of process classes using different naming conventions for the same physical fields.  So maybe the problem is the name process which doesn't accurately represent the concept here.
The framework encourages the creation of small components, so it might make sense to have a process class only for declaring u. However, in practice this could results in a lot of classes, which is a bit tough to deal with in Model objects. That's why in the example in the docs I've created a single class to declare u and to implement the time integrator (the main driver).

The builder should be able to guess which output to plug on each input, based on the shape, physical unit or name of the variables.

This is another approach that I've considered and which is used by other (more domain specific) modelling frameworks such as landlab. Both approaches have pros and cons. Here I've chosen not to rely on standards (names, units, etc..) because I wanted the framework to be as generic as possible and flexible enough so that it's easy to connect model components, e.g., written by people working in different domains / using different standards. Standards are good but sometimes they are not very flexible. Unfortunately, I haven't found any better alternative than xs.foreign.

But then, it would be better to make the link as an option to the model builder rather than hard-coded in the process.

I've also considered this, but in early mockups it quickly became ugly to (re)link at model creation all the variables declared in each process. I really want to keep the creation of a new Model very simple, i.e., ideally requiring no more than just a collection of processes. Fortunately, things like subclassing processes or xs.group already address some issues with hard-coding linked processes (only to a limited extent, I admit).

Could you make those classes callables?

They might be indeed some advantages of splitting variable declaration as you show in your code, but I think I prefer to have a clearer separation between the declarative and computation part, i.e., one declarative block at the top of the class and then methods for computation below is cleaner IMO.
Also, I'm not a big fan of encouraging the use of dunder methods like __call__ in the public API (process classes are end-user code).

My suggestion is to have process taking subprocesses as arguments.

A nested collection of processes looks indeed too complicated to me. I can see how difficult it will be to deal with it when implementing features like a callback system for model diagnostics/debugging/logging or even basic things like the repr.
There exist other, possibly better approaches to solve the problem of advanced time stepping schemes, time-independent models and cycles. For example, we could design a more generic/flexible way to define the passes trough the graph of processes during a simulation, with possible filtering. Currently, the framework defines 4 (optional) simulation stages, but we could imagine these stages somehow defined by the user (maybe with repeating/nested patterns, e.g., time steps coupled to one or more other iterative schemes). Regarding the API, decorating methods in process classes might help here (see, e.g., #40).

Actually, nothing prevents the user from creating a "process" class that only declares one or more variables without doing any computation. Such classes could be abstract (to be subclassed) or could serve as a glue (i.e., declare variable aliases) between two sets of process classes using different naming conventions for the same physical fields. So maybe the problem is the name process which doesn't accurately represent the concept here.

Its interesting to notice that we are thinking with different programming paradigms.
You've designed xsimlab with an imperative programming paradigm (a process is a sequence of instructions that affect preexisting mutable variables) and I'm imagining it in a functional programming mindset (a process is a mathematical function and the model is a fancy composition of functions).
I guess they both have pros and cons.
For instance, in the case of xs.foreign, I see it as a side-effect of the imperative design of the code and I think it is possible to get rid of it.
I'll make a small prototype to try to make my case for a more functional design.

I think that it would be great if we could add to xarray-simlab the capability to create models using Python functions as processes. However, I don't think that a purely functional design is possible or wanted here.
A pure functional, stateless approach might not always be the best nor the most natural. I have use cases where using exclusively immutable variables is simply not an option (e.g., allocating/destroying big arrays in memory at each time step). After all, a computational model is often viewed as a set of instructions that update one or more state variables.
That being said, some sort of functional style is already supported! By appropriately setting intent for variables in each process class, it is actually totally possible to produce a model with only immutable variables:

For intent=in variables, it is not possible to set their value within their process class:

the xs.process class decorator turns these variables into read-only properties
a value may still be set either in another process class (using xs.foreign) or by the user as model input

For intent=out variables, it is not possible to set their values outside of their process class:

they'll never be model inputs
an error is raised at model creation if intent=out is also set for any of its reference (i.e., a xs.foreign) declared in another process class

So, even though xarray-simlab uses Python classes to define processes, your definition of a process (a mathematical function...) may still be perfectly valid here!
What you suggest is not much different: using Python functions instead of classes where intent is implicit (intent=in for function arguments and intent=out for returned values). As I said before, I'm not opposed to also eventually support Python functions as processes, even though it will certainly raise some design questions. I'm one of those who think that functions are generally easier to deal with than classes, and in some cases like yours it might be nicer.

Rather than following an imperative paradigm, I've designed xarray-simlab as an object-oriented layer on top of a common data store for the simulation. Process classes are just a way to split the overall computation of a model into building blocks and to provide some "syntactic sugar" for accessing the simulation data store in a consistent manner (i.e., with safe guards).
Off the top of my head, I can imagine decorated (and annotated) Python functions that could be syntactic sugar for creating simple process classes that are also callable. That should be reasonably straightforward to make it work with everything else. The big remaining question is how to define variables with type annotations.

I guess you're right, you're more familiar than me with the design constraints.
I'll take a closer look at the working of the code and the implementation details.

As you suggested above, I've started drafting a PR to improve the example in the documentation.
I've just noticed that we don't really need to pass the grid spacing from grid to advect: if we use a DataArray, all the information should already be in the coordinates of the array.
But, assuming we keep it as it is, shouldn't there be an arrow linking directly grid to advect in the dependency graph, since the latter requires a variable from the former?

Simulation runtime data is only data.

Ok, it makes sense.

Process dependencies are defined as follows: Process 1 depends on process 2 if the later declares a variable (resp. a foreign variable) with intent='out' that itself (resp. its target variable) is needed in process 1.

Ok, I understand. In the graph, the arrows represent dependency in the sense of the order of execution. I was thinking of dependency in the sense of requiring the other Process to be also part of model.

In the graph, the arrows represent dependency in the sense of the order of execution. I was thinking of dependency in the sense of requiring the other Process to be also part of model.

You're right. "dependency" is confusing here. Maybe "workflow dependency" or "runtime dependency" would be better to clearly differentiate from "variable dependency".

Sure, you can close the issue.
Sorry for never finishing the documentation PR I mentioned above.
Since then, I've been scratching my itch by doing some experimentation on my side: https://github.com/mancellin/labelled_functions
The idea is to add labels on the inputs and outputs of Python functions, similarly to xarray adding labels to the dimensions of numpy arrays.
It allows to interact with labelled data and compose functions more easily.
The scope and implementation are different from xarray-simlab, but your work was a major source of inspiration.


Update the path users/userId/:userId to users/?id=abc in dashboard site (Do not merge it before issue #966 in website backend)

This need to be deployed along with issue https://github.com/Real-Dev-Squad/website-backend/issues/966.

can i work on this?

There is some change in requirement, will update the ticket and assign to you.
As there one more API users/{userName} so it will cause conflicts if we make the api as users/{userId}

The update after discussion is, we decided to change the API users/userId/{userId} to users/?id=abc
@Srinja333 can you share your discord username, are you part of Real Dev Squad server?

Srinjay disc

is your lift simulation done? @Srinja333

@Srinja333 can you share an ETA, by when this task can be completed?

I will complete by tomorrow

@vikhyat187  i have done, please check it out

Sure @Srinja333

Please share the PR link @Srinja333


Password management

I am reading that the goal of this feature is to allow Administrator of the app to manage the password, so user never knows the password. As it is setup right now, it looks like the user still has to know the password to sign-in on their own the first time. Shouldn't this password be securely stored in the Azure AD app blade, where the administrator creates and manages this password-enabled App, not on the client side?
I would think adding the shared username/password for an app would fall under the heading above: Configure the application for password single sign-on
<>.
Am I missing the point or a step somewhere?

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

ID: 43ffa778-8641-2036-2eee-8d3cfe8651bd
Version Independent ID: 2070db99-89d1-7324-d700-bbd6171d7482
Content: How to configure password single sign-on for an Azure AD Gallery application | Microsoft Docs
Content Source: articles/active-directory/application-config-sso-how-to-configure-password-sso-gallery.md
Service: active-directory
GitHub Login: @ajamess
Microsoft Alias: asteen

Actually, how you described it is how it works - see step 10:
"Additionally, you can also provide credentials on behalf of the user by selecting the rows of the users and clicking on Update Credentials and entering the username and password on behalf of the users. Otherwise, users be prompted to enter the credentials themselves upon launch."
Basically, you have 2 options - 1) manage the password as the admin so users don't know about it 2) let your users manage passwords for themselves. In both instances, the password is stored securely in Azure AD. Does this clarify for you?  Feel free to send me a note at<EMAIL_ADDRESS>if you have more questions.

I responded above - is there a way to close this request?

Thanks for the response Ajames - yes I saw step 10, I just hadn't found that. So far it is still pretty clunky, but I'm curious if the website I'm trying to hit as a use-case is the problem. I finally found out where to collect and store the shared credentials in AAD, as well as how to set credentials specifically for a user in AAD for that app.  However, in execution it doesn't really work for the website when my test user goes to logon. The webpage fills in the username but throws an error like, you need to sign-in again so we know it's really you.   Perhaps it's trying to block password keepers like this?
Also, is this functionality (for shared passwords) 100% tied to the new browser extension "My Apps Secure Sign-In" or will it work with a native browser configured with SSO/S+SSO as well?

Hey C016smith - the password vaulting requires the browser extension you mentioned - that is the only way to get SSO to these applications (you can also use the managed browser on mobile devices). It sounds like you may have misconfigured the application you mentioned, or perhaps the application is using an unsupported sign on page type .
You can use these documents to troubleshoot further:
https://docs.microsoft.com/en-us/azure/active-directory/application-config-sso-problem-configure-password-sso-gallery
https://docs.microsoft.com/en-us/azure/active-directory/application-sign-in-problem-password-sso-non-gallery
Please send me a note at<EMAIL_ADDRESS>and we can help you further there :).

#please-close

@c016smith
We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Created additional api_v2.py file, potential additions to general API scripts

Put together a simple GreyNoiseAPI class with all the new v2 API endpoints. Each method returns a JSON with no parsing.
This is really a no-frills class with no exception handling, but I have found it useful.

Apologies for the late response on this- I've neglected this library for a long time. We're now gutting everything and more or less completely rebuilding it. I'm going to close this PR but I want you to know how deeply I appreciate you taking the time to commit this code and reiterate how strongly I would still like to receive your feedback on our work moving forward. @vr0al thanks again, and cheers.


Having a Sort Option

I have cards with in Days of the Week Columns but the results are not in any order for a day.  It would be great to sort by Start Time field.

I'd like to second a request for an "order by" clause on the query and card display!


🐛 CameraViewManager cannot be cast to ViewGroupManager

What were you trying to do?
I'm trying to run the app and use the camera screen on an Android device.
Reproduceable Code
No response
What happened instead?
I'm receiving this error when I open up the camera screen of my app. Everything builds fine. The app runs with no warnings.
Then, I receive com.mrousavy.camera.CameraViewManager cannot be cast to com.facebook.react.uimanager.ViewGroupManager when I open the camera screen.
react-native: 0.66.3
It appears this issue has been encountered before. Did we find a solution?:
Okay so first off those are all very different errors.

the error CameraViewManager cannot be cast to ViewGroupManager happened

This seems really weird. I have never seen that error before and do not know how to reproduce it, if you can provide me a GitHub repository that I can run to reproduce it that would help me.

but when refreshing the c++ linking this happens
ninja: error: '../../../../build/react-native-0.64.2.aar/jni/armeabi-v7a/libjscexecutor.so', needed by '../../../../build/intermediates/cmake/debug/obj/armeabi-v7a/libVisionCamera.so', missing and no known rule to make it

This should be fixed by running the build twice. See https://github.com/mrousavy/react-native-vision-camera/issues/338

Now I did also try running the example project. Downloaded it and ran yarn install. Try running it on the phone with "Run 'app'" and got error:
ninja: error: "../../../../build/third-party-ndk/hermes/jni/arm64-v8a/libhermes.so", needed by "../../../../build/intermediates/cmake/debug/obj/arm64-v8a/libVisionCamera.so", missing and no known rule to make it

Same as above. See https://github.com/mrousavy/react-native-vision-camera/issues/338. Also you want to run yarn in both the root directory and in the example/ directory. Then open example/android/ in Android Studio.

But another error "parallel-video-processing-not-supported".

This happens in the Example app? See "the supportsParallelVideoProcessing prop", or related issue: https://github.com/mrousavy/react-native-vision-camera/issues/315

Maybe this whole thing has to do with you using an M1 laptop? the CameraViewManager cannot be cast to ViewGroupManager still seems so weird to me....
Originally posted by @mrousavy in https://github.com/mrousavy/react-native-vision-camera/issues/388#issuecomment-904680871
Relevant log output
No response
Device
Issues on both Motorola Moto E (physical device) and Google Pixel 4 (emulated), no issue on iPhone 11 (physical device)
VisionCamera Version
2.10.0
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

@mrousavy @trta2352 did you all ever find a solution to #388?

My bad! Issue derived from using SafeAreaView in combination with the Camera component.

My bad! Issue derived from using SafeAreaView in combination with the Camera component.

@willcray can you please elaborate what the solution was? I encountered the same problem but I couldn't find the solution. Much appreciated 😄

@willcray can you please elaborate what the solution was? I encountered the same problem but I couldn't find the solution. Much appreciated 😄

Yes, it was a simple fix. I stopped using SafeAreaView in the same JSX component as the Camera. I removed it from the component that renders the camera.

I have exactly the same error and I may know what is causing the issue. In my case I needed to render some elements on top of camera view so I'm rendering the as a children of Camera element. It works fine on iOS but crashes with:

com.mrousavy.camera.CameraViewManager cannot be cast to com.facebook.react.uimanager.ViewGroupManager

I'm not using SafeAreaView as Camera parent but regular View.

Yes, i am facing the same issue with Android. Did you guys find work around?

Same issue, dont have SafeAreaView but just View.

I'm also seeing the same issue.


Fix US address suffixes

I have made things!

Checklist

[x] I have read contributing guidelines
[x] I'm sure that I did not unrelated changes in this pull request
[ ] I have created at least one test case for the changes I have made

Related issues

Closes #1247

I didn't include a test because I'm not sure how to write something meaningful for this change. If you have an idea, please let me know.
The change is fairly trivial so I didn't update the change log or add myself to CONTRIBUTING. If you want those updated, just let me know

Thank you!


Please provide a version of Github Actions

Please provide a version of Github Actions

Done; see the workflow here. I have also updated the readme to mention this.


loading png graph reported an error of missing InputMarker node

I loaded your graph png but it gives me a node error and I can't find the missing node, How to fix it ?

vid2vidLongAnimateDiff.json
Here is a json that should work, try it out instead ( I removed the undefined nodes)


Turning screen off (mirroring) kills brightness adjustment

When I start scrcpy with the --turn-screen-off command line option, or if I use ctrl-o keyboard shortcut, once running to keep the mirroring working while turning the screen off, then any subsequent screen brightness change is no more taken in account until I reboot.
No matter what I do after:

Changing  brightness manually
Turning off and on adaptive brightness

The screen brightness will remain what it was before the scrcpy session. And this, until I reboot which eventually restores the mechanism.
If I run scrcpy without passing the command line option or issuing the ctrl-o keyboard shortcut, everything is fine from brightness adjustment point of view...
I didn't notice this initially, or at least didn't make the link as clear as it is now.
This is on Samsung S9 running /e/ (basically the same as LineageOS) based on Oreo , but a friend of mine running LineageOS on a Samsung S7  do not face the same issue...

Some ROMs have bugs with screen power state. I even disabled the possibility to turn back the screen on via a shortcut due to similar problems: https://github.com/Genymobile/scrcpy/commit/8c8649cfcd710859ce18eab557ed2af8cedb9a42
Unfortunately, I think there's nothing scrcpy can do.