Suggestion: add classes at breakpoints

In many cases I don't want to create multiple elements for large/small layouts, I simply need a different css class applied. It would be nice to have a directive that would apply a css class based on the screen size (versus show/hiding the element).
For example:
<p *sm-class="my-small-class" *lg-class="my-big-class">example</p>
When the window is small, .my-small-class is applied to the element, and when the screen is large, .my-big-class would be applied to the element.

Hi,
That's sound a good idea, but maybe instead of changing the class on the element, wouldn't it be easier if there was a specific class on the body like "responsive-breakpoint-lg". We could also add other devices information.
In the application you could then use the class as a media query to handle different layout according to the screen size:
body.responsive-breakpoint-lg .myClass{/*layout for lg, same as .my-big-class*/}
body.responsive-breakpoint-sm .myClass{/*layout for sm, same as .my-small-class*/}

The main advantages of this :

no need to redefine breakpoint size in the css
can handle other type of information (device ...)
only one entry point, reduce number of watchers and directives to implements!!!

Would this meet your requirements ?

I've just come across this repository so forgive me if this is already a feature, but what about injecting a service into components, that way we can use the ngClass directive, and even trigger functions on changes to orientation etc.

Hi,
You can use the following directives:

DeviceInfo, OrientationInfo, ResponsiveSizeInfo, PixelRatioInfo.
or responsive - Detection of multiple functions at once.

You can also use ResponsiveState provider but it's currently not the recommended way to do this as it may change at any time.

Work in new features with css class detections as does ng-class. ; )
And new events changes in responsive directive for get events in your components.

Hi,
Do we have any update about this suggestion?
I would like to be able to do something like: [ngClass]="{'my-class-lg': *lg, 'my-class-sm: *sm}"
Is it possible now? Does *lg, *sm and similar directives return boolean?


Basic support for currencies

This is a quick and dirty attempt to support multi currencies. Since the project is not supported I doubt that it will be merged but this might be useful to some people anyway so I post it here.
It also uses the amount and currency for the prediction, which might or might not be desirable (hence be aware that using this PR will change the behavior). The changes from 6525c2d can be removed to get rid of that part.
Be aware, though, that all this is mostly untested.

This feature is implemented in #81 and adds additional testing.


fix(extendRoutes): override child with relative paths

Allow setting relative paths for child routes

@posva I'm not entirely sure how the trees are structured or created. I had to update the code to check that the parent was the root. Can you think of any cases where this would not work?

Do you have a bug reproduction? This doesn't seem to be fixing something 😅
Changing paths with non absolute routes is not supported yet #341

@posva Quite right! It's actually more of a feature 😊 https://github.com/posva/unplugin-vue-router/issues/341 is exactly the problem I was trying to solve 😊

I think I'm seeing the problem now. Here's a snippet out of TreeNode. Here the path is assumed to be relative (a path segment) or absolute if there is a path override. Interesting behaviour... There has to be a bit more thought put into this. Marking this as a draft 😊
  get path() {
    return (
      this.value.overrides.path ??
      (this.parent?.isRoot() ? '/' : '') + this.value.pathSegment
    )
  }

If we were to make a slight change to the behaviour of the TreeNode I think relative paths could be supported. It would be a breaking change though. Can you see any reasons why this would be a bad idea?

The fullPath shouldn’t change its behavior, or at least it shouldn’t be needed

I'll have a look at where it is being used and see if I can remove it 😊

Sorry, I was overcomplicating this a lot. I didn't realise that you could have absolute paths as child routes. I just assumed you had to put an extra / in the URL or something. Does what I'm doing now make more sense?

Looking good. I will probably give this a review and merge next Monday during the stream

Closing in favour of https://github.com/posva/unplugin-vue-router/pull/519


add log

Related Github tickets

a list of github issues that are relevant for this PR

Background
A short paragraph on test what exactly this PR solves.
Testing completed

[ ] a list of actions that you've performed to ensure that this PR works as intended
[ ] 99% of the times you should have an item: "wrote tests"

Breaking changes

[ ] I have checked my code for breaking changes
[ ] If there are breaking changes, there is a supporting migration.

@taariq none of them, you lint the code before actual deploying it. You can do it locally (as a developer) or in a github-ci worker (CI/CD). So linting message is different from application logs.
When app is built, there will be nothing more to lint (since no source .go files with the binary are deployed)


qtbase_%.bbappend: update PACKAGECONFIG name for xkbcommon

As per Qt 5.12.2 commit update, xkbcommon-evdev PACKAGECONFIG option has been renamed to xkbcommon.
This commit fixes BitBake QA:
WARNING: qtbase-5.12.2+gitAUTOINC+856fb1ab44-r0 do_configure: QA Issue: qtbase: invalid PACKAGECONFIG: xkbcommon-evdev [invalid-packageconfig]

Note for maintainers
I do not think those rpi appends are necessary anymore. The very same configuration is now automatically enforced in meta-qt5 by default. (Look above).
Before merging, I would like to discuss whether the appends are still required.
Thanks

Can one of the admins verify this patch?

Yes appends are needed

@jenkins-ag ok to test


Fix value auto is set like null

When I use the property with 'auto', it set like null, for example:
img {
  width: 100%;
  height: auto;
}

Generate:
"img":{"width":100,"height":null}

I compare the value, if the value is auto, I don't parse the value.
It's my first pull request, tell me if I can do it better.
Thanks

I think the issue is that in React Native, all values that would take percentages or the 'auto' value in standard CSS can only accept pixel units.  Additionally, passing null should result in effectively the 'auto' layout equivalent for height while passing the string 'auto' will throw an error in RN, meaning the 'auto' -> null transform is valid.  Replicating 'auto' values for properties such as margin requires flexbox align and justify properties.
Instead of of passing auto value through or just the truncated numeric for relatives values (%, em, etc.) as well as non-supported values ('calc()' for example), it should probably omit the property in the output entirely and throw a console warning to the user.  A warning mentioning that relative values are not supported and they need to be using flexbox for any non-static layouts would be perfect.
Some validation would be good all around.  Since this is only run at build time, we don't really have to worry about any performance issues with adding the extra layer to the transform process. Since I think one of the major use cases (if not the main use case) of this project is leveraging existing CSS assets or allowing designers to create assets in their native tongue, validation could play a big roll.
Good links to point to in warning messages:
https://facebook.github.io/react-native/docs/layout-props.html
https://facebook.github.io/react-native/docs/flexbox.html

Set the value to null and show a warning message?

Agreed to need some validation messages and defiantly something I want to improve. In regards to this PR, we should really avoid setting null values and merge this PR but I will let @jpomazal decide.
I will set a milestone for us.

This pull sets the value to 'auto', which will throw an error in RN.  I'll close this and create an issue for validation.


Custom Themes

Tasks

Customize existing themes and create new ones.
Delete all but one theme.
Save themes automatically to local storage.
Generate a sharable key or json object that can be shared with other devices or users.
Option to reset themes to default selection.

these themes could also include different audio sets


1-element array

r? @reitermarkus
(rust-highfive has picked a reviewer for you, use r? to override)


Port-forwarding not compatible with recent Kubernetes versions

Issue
On this PR https://github.com/epinio/epinio/pull/2001/ we bumped Kubernetes version in K3s from v1.20.11-k3s2 to v1.25.4-k3s1
Port-forwarding started to fail with error:
❌  error port forwarding to application: error upgrading connection:

The same happens with v1.26.0+k3s2, v1.24.9+k3s2, v1.23.15+k3s1
Steps to reproduce

Change K3S_IMAGE on scripts/acceptance-cluster-setup.sh to any of the above
Deploy epinio using:

make acceptance-cluster-delete
make acceptance-cluster-setup
export KUBECONFIG=$PWD/tmp/acceptance-kubeconfig
make install-cert-manager
make prepare_environment_k3d

Push an app

➜  epinio git:(main) epinio push -n sampleapp-1 -p assets/golang-sample-app

Redirect port-forwarding:

➜  epinio git:(main) epinio app port-forward sampleapp-1 8088:8080

Observed behavior
Following error appears:
❌  error port forwarding to application: error upgrading connection:

Expected behavior
Port-forward should work with recent k3s vesions like v1.26.0+k3s2 displaying an output like this
➜  epinio git:(main) ✗ epinio app port-forward sampleapp-1 8088:8080

🚢  Executing port forwarding
Namespace: workspace
Application: sampleapp-1
Forwarding from <IP_ADDRESS>:8088 -> 8080
Forwarding from [::1]:8088 -> 8080
Handling connection for 8088

Note: applying a curl should confirm a new entry with the port-forward:
➜  epinio git:(main) curl localhost:8088

Extra notes
The following versions (v1.22.16+k3s1 and v1.21.14+k3s1) seemed to allow port-fowarding but did not work using the golang-sample-app commented above.
Error appearing for v1.22.16+k3s1:
error pushing app to server: can't deploy app: Internal Server Error: Get "https://github.com/epinio/helm-charts/releases/download/epinio-application-0.1.24/epinio-application-0.1.24.tgz": EOF

Error for v1.21.14+k3s1:
 [stage-workspace-sample-b75c89bd4bdb236cb43caf9f89969cbf9das9nrt] buildpack ERROR: failed to build: exit status 1

Confirmed behaviour, good and bad for 1.20.11 and 1.23.15.
Looking into the E server logs I see an additional line

2023/01/25 14:18:37 http: proxy error: http2: invalid Upgrade request header: ["SPDY/3.1"]

Based on additional log entries I added this seems to be reported from
https://github.com/epinio/epinio/blob/97509919cc87fe7cb4d2a9eb85c32a1d30411da3/internal/api/v1/application/portforward.go#L93-L106
I am guessing that Kube switched to a new protocol (SPDY), and the go code from net/http/httputil is not uptodate to handle that.
I will check if Go 1.19 has changes in that area.

Reduced the failing block to
https://github.com/epinio/epinio/blob/97509919cc87fe7cb4d2a9eb85c32a1d30411da3/internal/api/v1/application/portforward.go#L106

https://github.com/pomerium/pomerium/issues/2126#issuecomment-827137371 contains

... Unfortunately out of the box the Go HTTP reverse proxy doesn't support SPDY, because it will use HTTP/2 first. ...

Related PR ... https://github.com/pomerium/pomerium/pull/2134/files#diff-f6d92a8f39b323b40cde569ed5f78ba3e1704e2c5976fa7b9046f8b093fef485

Note: Our exec uses the same reverse proxy (code) as the port forwarding. Should be affected by the same issue.

Notes ...

Giving the reverse proxy a clone of the default http transport replaces the invalid Upgrade request header: ["SPDY/3.1"] error with x509: certificate signed by unknown authority.
The issue with speedy is gone, and replaced by an issue with cert verification. Worse, this fails for the kube 1.20.11 also, i.e. our normally working base case.
I believe that speedy is ok because we modified the default http transport to not use http v2.
It is unclear why the certs have become an issue. Looking into the structures the transport has all the system certs, and extended trust from other places. The cloning was not an issue either, the certs (pool) was properly cloned over.
Forcing InsecureSkipVerify: true to bypass cert checking stops the x509 server error, however something else still chokes because the client now report a third error, namely error upgrading connection: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}. Again, this is for the base case.

A confusing part in my notes is that the documentation for the reverse proxy says

// The transport used to perform proxy requests.
// If nil, http.DefaultTransport is used.
Transport http.RoundTripper

Yet the behaviour seems to be different when I explictly set (a clone of) the DefaultTransport, vs. not.
And when not setting it, the Transport seems to be nil ... Although I will check that now.

I may have to implement the ErrorLog, ModifyResponse, and ErrorHandler function vectors to see more details.

Ah! The transport is not nil. It is a custom transport set by the kube rest client.


[Bitwarden Vault] When searching the vault, Other Items displayed before Favorites

Extension
https://www.raycast.com/jomifepe/bitwarden
Raycast Version
1.78.1
macOS Version
14.5
Description
First of all, I'll mention that I'm putting this as an issue and not a feature request because I've noticed some inconsistencies with this behavior, so I'm not exactly sure if it is a bug or this is how this fuzzy search implementation is supposed to work.
Up until lately, when I typed into the search bar filtered items would be always shown with Favorites first and Other Items after that. However, now in some cases, Other Items are shown before the Favorites, which is very inconvenient, since in 99% of cases the item I'm looking for is in my favorites, so now I have to scroll all the way down to find it, while before it was always the first or just a couple of rows down.
It still works 'correctly' when the searched term is in the beginning of items' names:

But differently when items just contain the search term (typo in a search term to limit the amount of items in the list):

Not sure when this happened exactly, nor do I seem to find any commits related to this that would explain this change.
Tried re-installing both the extension and bitwarden-cli.
Steps To Reproduce
See description above for screenshots
Current Behaviour
Favorites are sometimes listed below Other Items
Expected Behaviour
Favorites are always shown first

Thank you @jomifepe. Everything works as expected now.

Awesome 🚀


WIP Use label not pattern as primary navigation key

Pattern is not as fundamental an attribute as label, for example MDDA and CMIP6 intake drivers do not even use a file system. Also, SQL database locators, while there is a GLOB statement, the results might not relate to the existing file system

@LaurenceBeard this PR is working towards separating Dataset UI from Dimension UI so that I can swap pattern to label as the primary key to select datasets. It is needed by #217 as I've hit a road block trying to support sql_pattern and not pattern for database locators

#222 makes this easier by replacing state with selectors, a View can then specify a label in the construction of a Selector(state, label) and the selector.initial_time etc. will be relevant to that View or whatever algorithm the state suggests to use to find the relevant value.


Swagger Breaking Changes PR check fails with "command failed"

The Swagger Breaking Changes PR check in PR #18174 fails with a really strange error message:
"details":"Command failed: node /mnt/vss/_work/_tasks/AzureApiValidation_5654d05d-82c1-48da-ad8f-161b817f6d41/0.0.27...

I re-ran the PR pipeline with /azp run and got the same error, so does not appear to be a transient issue.
Here's a link to the full results in ADO: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1496495&view=logs&j=98f87804-8e1f-5655-af02-e80aefa7aa97&t=65457206-7ab6-5966-2a2f-9ae3efa14a03

it was caused by the invalid swagger example and already been fixed in the PR
https://github.com/Azure/azure-rest-api-specs/blob/b3c76f6891f5d98250783fec3f1629fdab50101b/specification/cost-management/resource-manager/Microsoft.CostManagement/stable/2021-10-01/examples/Operations.json

I have reopened this issue because I think our tooling should be resilient to buggy swagger examples.

Sorry, do you mean to have friendly diagnostic message?

seems it's also about error message, create a unified issue to do such stuff


Visualization templates backend

Closes #4805

Created earlier to check how tests go with the downgrade of activerecord-postgres-array gem

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

retest this please

retest this please

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

@juanignaciosl CR please
NOTE: On purpose the feat. flag is not checked on the vis/table controllers new endpoints because no matter if the user triggering the action has the flag or not, we should try to keep data integrity (as else we could be removing stuff without the user knowing).
@xavijam @javisantana Anything you miss or looks wrong?
Being feature flag based I'll release as soon as tests pass so you can use ir whenever you want.

retest this please

Frontend tests were OK :+1: (details)

retest this please

retest this please

Frontend tests were OK :+1: (details)

retest this please

retest this please

Frontend tests were OK :+1: (details)

Last commit only removes the if inside template model because now there is no ambiguation as the only code fragment calling it is always from a Table model

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

:+1:

retest this please

Frontend tests were OK :+1: (details)

At a staging, all looks fine:
                                  Table "public.templates"
         Column          |            Type             |              Modifiers
-------------------------+-----------------------------+-------------------------------------
 id                      | uuid                        | not null default uuid_generate_v4()
 source_visualization_id | uuid                        | not null
 title                   | text                        | not null
 description             | text                        | not null default ''::text
 min_supported_version   | text                        | not null default ''::text
 max_supported_version   | text                        | not null default ''::text
 code                    | text                        | not null default ''::text
 organization_id         | uuid                        | not null
 required_tables_list    | text                        | not null default ''::text
 created_at              | timestamp without time zone | not null default now()
Indexes:
    "templates_pkey" PRIMARY KEY, btree (id)
    "organization_id_idx" btree (organization_id)
    "source_visualization_id_idx" btree (source_visualization_id)
Foreign-key constraints:
    "organization_id_fkey_cascade_del" FOREIGN KEY (organization_id) REFERENCES organizations(id) ON DELETE CASCADE
    "source_visualization_id_fkey_cascade_del" FOREIGN KEY (source_visualization_id) REFERENCES visualizations(id) ON DELETE CASCADE

So, for now disabling the offending test until we take down current CI system.

retest this please

Frontend tests were OK :+1: (details)


Users have access to others home directory including mail.

I seen lrvick asking this morning if irc user woompydoompydoo filed a report on this. Since no report was made yet, I decided to go ahead and submit this. I actually brought this up before in irc, but I guess I should have filed the report.
woompydoompydoo is correct. Users do have access to other users home directories, including Mail. I haven't went further than /home/xxx/Mail for privacy, but looking at cur, new, tmp permissions I am pretty sure that I could just read other users emails in nano.
4 drwxr-xr-x.  2 xxxx 3000 4096 May 19 05:04 cur
4 drwxr-xr-x.  2 xxxx 3000 4096 May 19 05:04 new
4 drwxr-xr-x.  2 xxxx 3000 4096 May 11 18:14 tmp
This is caused by most users sharing the *group 3000. It seems legacy users and admins are not affected by this. For a list of affected users see  getent passwd. Anyone who shares the same group has access to eachothers files. daurnimator also stated last night in irc that you can also see there is a problem by checking getenv group
I see that there are already a few test accounts created and that they also share the same group 3000, so this all can easily be tested using one of those accounts or by creating a new account and then checking file permissions.
28 -rw-------. 1 xxxxx 3000 27271 Jun  9 22:00 .bash_history
4 -rw-r--r--.   1 xxxxx 3000   220 May 11 16:42 .bash_logout
4 -rw-r--r--.   1 xxxxxx 3000  2129 Jun  3 16:16 .bash_profile

@gmcclins This will be fixed when hashbang/provisor#25 is (completely) resolved.
Thanks again for reporting the issue.

Fixed.


feat: OR-1389 fork public network

Description
Fork the public network by using anvil
How to test it

Create .env file

export FORK_PUBLIC_NETWORK=true
export L1_RPC='change me'
export FROM_BLOCK_NUMBER=19277372
export L2_NATIVE_TOKEN=0x2be5e8c109e2197D077D13A82dAead6a9b3433C5
export IMPL_SALT='change me'

Export these envs

export $(xargs < .env)

Run

make devnet-up

Thank you very much! 🙇🏼♂ Do we need these functions? (anvil_dumpState, convert_anvil_dump) Are you making this for later? If so, I'm curious. Do we use anvil node? (About, anvil_dumpState JSON RPC method)

I am using anvil to fork the public network, and anvil doesn't support dump_block endpoint, instead of that, it has a new endpoint anvil_dumpState, which is similar to dump_block from geth
Oh I missed my code, I updated


WIP elasticsearch: Initial implementation of the search-engine in elasticsearch

The search engine is based on elasticsearch and uses the
invenio_query_parser to transform the user's query to a dsl query.
This is still a work in progress, but can present the main ideas.
The elasticsearch extension consist of the following files:

the _init.py file that sets up the extension and exposes the basic functions
to be called
the backend.py that is the implementation of the extension itself and knows
how to communicate with elasticsearch
the query_handler.py responsible to format the elasticsearch dsl query and
calls the
ast_to_dsl.py which uses the invenio_query_parser and creates the basic
elasticsearch query on the user query.
the record_enhancer.py is the place where the json record is manipulated
before it is stored in elasticsearch. There we could add all the calculated
fields etc. For now on only the collentions, name variations and full_text are
handled.
the results_handler.py is treats the elasticsearch results and brings them to
the form that the UI expects.

For demo and testing purposes, the elasticsearch extension is completely
separate from the rest of invenio search engine and user interface. In order to
be tested, I used the elasticsearch_view by jma. I changed it so that it can
deal with the changes.
The search engine can be tested in action at http://marioskogias-invenio:4000/es
There you can ask queries such as:

Efstathiou
author:Efstathiou and abstract:perform (to check highlighting)
author:'G Efstathiou' (to check name variations)

The search engine is not configured yet. So, it convers just some basic cases
for demo purposes.
Next steps:

Fix search engine configuration
Put elasticsearch configuration in the correct place (probably JSONAlchemy fields)
Implement all CRUD operations for elasticsearch records

Superseded by #3307.


upgrade to 6.4.0.Final

Upgrade to 6.4.0.Final
Replace StatefulSession into StatelessSession
Load resource from classpath

+1

+1

When will 6.4.0 support be merged?

@maciejwalkowiak I forgot this PR.... Do I have to review the code?

First of all I am sorry for long delay.
I haven't been working with Drools for quite a while and this repository felt pretty abandoned.
Great job @Fabryprog. Thanks a lot for contribution. Before I can merge it I would like to know the reasons you switched from Stateful to Stateless session?

@maciejwalkowiak i don't remember! Perhaps it would be good both be present

Great job @Fabryprog. Thanks a lot for contribution. Before I can merge it I would like to know the reasons you switched from Stateful to Stateless session?

Too mary types in 6.1.0 Final did not exist in 6.4.0 Final, that may be the reason.

Great job @Fabryprog. Thanks a lot for contribution. Before I can merge it I would like to know the reasons you switched from Stateful to Stateless session?

Just now，I thought Stateful was better than Stateless,  because more than two entities were needed in UT.
I am looking forward to the release of the new version. :)

Unfortunately due to the lack of time I am not able to continue developing and maintaining junit-drools project. Thank you for your contributions and I hope you will find one of the forks still maintained and helpful for you!


update method of terminate

Features
update method of terminate

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.63%. Comparing base (4ef53a2) to head (60fd49e).
 Consider uploading reports for the commit 88cea94 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@                 Coverage Diff                  @@
##           code_interpreter    #1002      +/-   ##
====================================================
+ Coverage             81.61%   81.63%   +0.01%
====================================================
  Files                   223      223
  Lines                 13127    13136       +9
====================================================
+ Hits                  10714    10723       +9
  Misses                 2413     2413

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


build: update golang version to 1.20

Description

closes: #1024
Motivation and context

How has this been tested?

Screenshots (if appropriate):
Checklist:

[x] I followed the contributing guidelines and code of conduct.
[x] I have added a relevant changelog to CHANGELOG.md
[ ] I have added tests to cover my changes.
[x] I have updated the documentation accordingly.
[ ] I have updated API documentation client/docs/swagger-ui/swagger.yaml

I MUST revert the replace on ostracon.

Or, we should merge #1025 into main and deal with the differences between 1.19 and 1.20.

Or, we should merge #1025 into main and deal with the differences between 1.19 and 1.20.
What do you think @zemyblue ?

No I think it's not a good idea.


User is not authorized to perform action on API gateway when using Sign In with Apple

Before opening, please confirm:

[X] I have searched for duplicate or closed issues and discussions.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework
React
Amplify APIs
Authentication, Analytics
Amplify Categories
auth, api
Environment information

Put output below this line
I have these versions of SDK :
pod 'AWSCore', '~> 2.28.0'
pod 'AWSMobileClient', '~> 2.28.0'
pod 'AWSAPIGateway', '~> 2.28.0'

Describe the bug
We are experiencing an issue where users Signed In With Apple are getting "[”Message”: User: arn:aws:sts::x:xassumed-role/golfonaut-master-xxxx-unauthRole/CognitoIdentityCredentials is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:eu-central-1:xxxx:cccc/master/GET/xxx]” error when trying to access an API after being logged in for 10 minutes.
We are listening to user state changes but when issue is observed the event is not triggered.
Expected behavior
Tokens expiry duration in cognito is configured to 30 days. So we expect the token to only expire after 30 days.
Reproduction steps
I have these versions of SDK :
pod 'AWSCore', '~> 2.28.0'
pod 'AWSMobileClient', '~> 2.28.0'
pod 'AWSAPIGateway', '~> 2.28.0'
Code Snippet
// Put your code below this line.

func init_aws() async {
        print("AuthManager init_aws")
        let (user_state, error) = await [self.aws ](http://self.aws/)_mobile_client_initialize()
        if let user_state_strong = user_state {
            await self.action_triage(user_state: user_state_strong, app_launch: true)
        }
        else if let error = error {
            print(error.localizedDescription)
        }
        AWSMobileClient.default().addUserStateListener(self) { (user_state, info) in
            print("AWSMobileClient listener : ", user_state)
            Task(priority: .medium) {
                // to avoid conflict with auth vc logic
                guard self.presenting_auth_vc == false else { return }
                await self.action_triage(user_state: user_state, app_launch: false)
            }
        }
        return
    }

private func aws_mobile_client_initialize() async -> (UserState?, Error?) {
        return await withCheckedContinuation { continuation in
            AWSMobileClient.default().initialize() { (user_state, error) in
                continuation.resume(returning: (user_state, error))
            }
        }
    }

func action_triage (user_state: UserState, app_launch: Bool) async {
        print("AuthManager action_triage : ", user_state)
        switch(user_state){
        case .signedIn:
            Mixpanel.mainInstance().track(event: "Phone: Auth Signed In")
            do {
                let (_,_) = try await Purchases.shared.logIn([CacheManager.Player.email ](http://cachemanager.player.email/))
            }
            catch {
                print("Purchases logIn error")
            }
            if CD_Player.fetch_last() != nil {
                // when user sign in during app use, just_sign_in method calls applicationDidFinishLaunching()
                if (app_launch == true){
                    await AccountManager.sharedAccountManager.applicationDidFinishLaunching()
                }
            }
            else{
                print("CD_Player.fetch_last() = nil, we force signed out")
                // If no player and signedIn, we try to get the email from the token.
                // Case 1: when someone signedIn re-install Golfonaut
                // Case 2: when I re-install Golfonaut
                let (email, _) = await AuthManager.sharedAuthManager.get_token_email_safe()
                if let email_strong = email {
                    await self.just_signed_in(email: email_strong)
                    if (app_launch == true){
                        await AccountManager.sharedAccountManager.applicationDidFinishLaunching()
                    }
                }
                else{
                    await self.sign_out()
                }
            }
        case .signedOut:
            Mixpanel.mainInstance().track(event: "Phone: Auth Signed Out")
            do {
                let _ = try await Purchases.shared.logOut()
            }
            catch {
                print("Purchases logOut error")
            }
            await [MainActor.run ](http://mainactor.run/) {
                self.presentAuthViewController()
            }
        case .signedOutFederatedTokensInvalid:
            Mixpanel.mainInstance().track(event: "Phone: Auth Signed Out Federated Token Invalid")
            await self.sign_out()
        case .signedOutUserPoolsTokenInvalid:
            Mixpanel.mainInstance().track(event: "Phone: Auth Signed Out User Pools Token Invalid")
            await self.sign_out()
        case .guest:
            Mixpanel.mainInstance().track(event: "Phone: Auth Guest")
            await [MainActor.run ](http://mainactor.run/) {
                self.presentAuthViewController()
            }
        case .unknown:
            Mixpanel.mainInstance().track(event: "Phone: Auth Unknown")
            await self.sign_out()
        }
    }

### Log output

<details>

// Put your logs below this line

</details>

### aws-exports.js

_No response_

### Manual configuration

_No response_

### Additional configuration

_No response_

### Mobile Device

_No response_

### Mobile Operating System

_No response_

### Mobile Browser

_No response_

### Mobile Browser Version

_No response_

### Additional information and screenshots

_No response_

Hello,
@Bathande opened this Github for me, as part of AWS support service.
As you can see the code is in Swift. I am using "AWSMobileClient", "AWSAPIGateway" and "AWSCore" frameworks, version 2.30.4.
The issue is for Sign In With Apple users. After few minutes, they encounter issues with the API Gateway. Cognito says they are signed in, but API Gateway says they are unauth.
When the SIWA user launches the app, we init AWS. AWS says the user is signedIn (!). We also add the listener as you can see above.
When we need the API Gateway (just after), we ask for a fresh token
AWSMobileClient.default().getTokens()
It gives us a token. The token looks not expired, even if the expiration date is soon :
Tokens(idToken: Optional(AWSMobileClient.SessionToken(tokenString: Optional("**"))), accessToken: Optional(AWSMobileClient.SessionToken(tokenString: Optional("***"))), refreshToken: Optional(AWSMobileClient.SessionToken(tokenString: Optional("***"))), expiration: Optional(2023-04-07 17:24:58 +0000))
2023-04-07 16:29:16 +0000

We use this token with API gateway:
let api_request = AWSAPIGatewayRequest(httpMethod: "GET", urlString: url_string, queryParameters: query_parameters, headerParameters: ["Content-Type": "application/json","Accept": "application/json", "Authorization": token], httpBody: nil)
But we got rejected by API Gateway:
User: arn:aws:sts::***:assumed-role/***-master-***-unauthRole/CognitoIdentityCredentials is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:**-**-1:************:***/master/GET/download*
If we sign out, and sign in again the user, we get a valid token, accepted by API Gateway.
Am we missing something?

Hi @harsh62 , sorry for late response.
Also it took few days to reproduce the error.

Please find Sign In With Apple signing code:

var hosted_UI_options: HostedUIOptions = HostedUIOptions(identityProvider: "SignInWithApple", signInPrivateSession: true)
let (user_state, error) = await self.sign_in_with(hosted_UI_options: hosted_UI_options, calling_window: calling_window)

private func sign_in_with(hosted_UI_options: HostedUIOptions, calling_window: UIWindow) async -> (UserState?, Error?){
        return await withCheckedContinuation { continuation in
            AWSMobileClient.default().showSignIn(presentationAnchor: calling_window, hostedUIOptions: hosted_UI_options) { (user_state, error) in
                continuation.resume(returning: (user_state, error))
            }
        }
}

2. Logs in debug

AuthManager init_aws
2023-05-25 08:19:32:200 ***[60224:6420624] Configuring SignInProvider : CognitoUserPool.
AuthManager action_triage :  signedIn
download_player()
2023-05-25 09:05:41:612 [60432:6440343] Invoking hostedUI getTokens
2023-05-25 09:05:41:612 [60432:6440343] ED240171-6892-4CE6-8D45-93372EF08611 Created FetchUserPoolTokensOperation
2023-05-25 09:05:41:612 [60432:6440343] ED240171-6892-4CE6-8D45-93372EF08611 Start execution
2023-05-25 09:05:41:614 [60432:6440349] ED240171-6892-4CE6-8D45-93372EF08611 notStarted: startOperation -> fetching
2023-05-25 09:05:41:614 [60432:6440349] ED240171-6892-4CE6-8D45-93372EF08611 Inside fetch token
2023-05-25 09:05:41:618 [60432:6439999] Request headers:
{
Authorization = "AWS4-HMAC-SHA256 Credential=/20230525/eu-central-1/mobiletargeting/aws4_request, SignedHeaders=content-type;host;user-agent;x-amz-date;x-amz-security-token, Signature=";
"Content-Type" = "application/x-amz-json-1.1";
Host = "pinpoint.eu-central-1.amazonaws.com";
"User-Agent" = "aws-sdk-iOS/2.30.4 iOS/16.4.1 en_FR aws-amplify/cli";
"X-Amz-Date" = 20230525T070541Z;
"X-Amz-Security-Token" = "";
}
2023-05-25 09:05:41:618 [60432:6439999] Request body:
<EMAIL_ADDRESS>2023-05-25 09:05:41:619 [60432:6440349] ---- fetching: tokenFetched -> fetched
2023-05-25 09:05:41:619 [60432:6440349] ----*** Success
get_token_safe - tokens_strong =  Tokens(idToken: Optional(AWSMobileClient.SessionToken(tokenString: Optional("***"))), expiration: Optional(2023-05-25 07:16:26 +0000))
2023-05-25 07:05:41 +0000
2023-05-25 08:19:32:366 [60224:6420619] Response headers:
{
"Access-Control-Allow-Origin" = "";
"Cache-Control" = "no-store";
"Content-Length" = 73;
"Content-Type" = "application/json";
Date = "Thu, 25 May 2023 06:19:32 GMT";
Via = "1.1 .cloudfront.net (CloudFront)";
"x-amz-apigw-id" = "=";
"x-amz-cf-id" = "-==";
"x-amz-cf-pop" = "-";
"x-amzn-requestid" = "----";
"x-amzn-trace-id" = "Root=1--**";
"x-cache" = "Miss from cloudfront";
}
2023-05-25 08:19:32:366 [60224:6420619] Response body:
{"RequestID":"-df97-4976-9701-***","Message":"Accepted"}
download_player - *** server bad response - json =  ["message": User: arn:aws:sts:::assumed-role/-dev-***-unauthRole/CognitoIdentityCredentials is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:eu-central-1:*****5006:/dev/GET/downloadplayer]

awsconfiguration.json:

{
    "UserAgent": "aws-amplify/cli",
    "Version": "0.1.0",
    "IdentityManager": {
        "Default": {}
    },
    "CredentialsProvider": {
        "CognitoIdentity": {
            "Default": {
                "PoolId": "eu-central-1:***-***-***-***-***",
                "Region": "eu-central-1"
            }
        }
    },
    "CognitoUserPool": {
        "Default": {
            "PoolId": "eu-central-1_***",
            "AppClientId": "***",
            "Region": "eu-central-1",
            "AppClientSecret": "***"
        }
    },
    "Auth": {
        "Default": {
            "OAuth": {
                "WebDomain": "***.auth.eu-central-1.amazoncognito.com",
                "AppClientId": "***",
                "AppClientSecret": "***",
                "SignInRedirectURI": "***://",
                "SignOutRedirectURI": "***://",
                "Scopes": [
                    "phone",
                    "email",
                    "openid",
                    "profile",
                    "aws.cognito.signin.user.admin"
                ]
            },
            "authenticationFlowType": "USER_SRP_AUTH",
            "mfaConfiguration": "OFF",
            "mfaTypes": [
                "SMS"
            ],
            "passwordProtectionSettings": {
                "passwordPolicyMinLength": 8,
                "passwordPolicyCharacters": []
            },
            "signupAttributes": [
                "EMAIL"
            ],
            "socialProviders": [
                "GOOGLE",
                "APPLE"
            ],
            "usernameAttributes": [
                "EMAIL"
            ],
            "verificationMechanisms": [
                "EMAIL"
            ]
        }
    },
    "DynamoDBObjectMapper": {
        "Default": {
            "Region": "eu-central-1"
        }
    },
    "PinpointAnalytics": {
        "Default": {
            "AppId": "***",
            "Region": "eu-central-1"
        }
    },
    "PinpointTargeting": {
        "Default": {
            "Region": "eu-central-1"
        }
    }
}

It looks like the AWS Credentials are not loaded for the signed in user yet. Could you try invoking AWSMobileClient.default().getAWSCredentials before making your API call and see if the issue get resolved?


Have street lamp preset use light:direction

Per the wiki, the orientation of a street lamp should be using light:direction instead of just direction: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstreet_lamp
Maybe even suggest it as an upgrade if the direction tag already exists?

I don't have a problem with .direction= in general, but we need to document these types of generic extensions. As a data consumer/creator there needs to be some consensus on when *:direction is an expected tag. If we allow *.direction on anything that could possibly have a direction it's not tractable.


Enhance support for Application Properties

I'm submitting a ...  (check one with "x")
[] bug report => search github for a similar issue or PR before submitting
[x] feature request
[] support request
[] general question

Current behavior (how does the issue manifest):
Currently, there is no support for property type or grouping of properties.
Expected behavior:
Users should be able to set a type as well able to group set of properties together.
Minimal steps to reproduce the problem (not required if feature enhancement):
What is the motivation / use case for changing the behavior?
https://github.com/TIBCOSoftware/flogo/wiki/Application-Properties
Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):
Flogo version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X
Additional information you deem important (e.g. issue happens only occasionally):

I like the idea! One small question though, in one of the code blocks you're referring to $env[ENV_DB_URL] while today that would be $env.ENV_DB_URL. Do we expect to change that too and if so, will it be backward compatible with the existing apps?

Thats proposed change for consistency with $property and $activity. Though supported for few releases, we will deprecate use of  $env. in the future.

are you talking about deprecating $env completely ?  or just the $env.ENV_VAR syntax ?

@ayh20 just changing the syntax. so we'll make the switch to $env[ENV_DB_URL] and support the syntax of $env.ENV_DB_URL and $env[ENV_DB_URL] for a period of time.

Resolved in TIBCOSoftware/flogo-lib#171


Ensure all links to the example repo code are still valid

Acceptance Criteria
The links at the beginning of each chapter of the Full Day workshop (beginning in Chapter 2) link to the appropriate repo URL, for example: https://github.com/FrontEndFoxes/docs/blob/master/workshops/vue/full-day/ch2.md

☝ this links to https://github.com/FrontEndFoxes/projects/tree/master/chapter-1-end which is no longer a valid URL, it should link to https://github.com/FrontEndFoxes/projects/tree/main/chapter-1-end

these links are broken because we changed the repo's default branch name form master to main

Assigned to Farhia ❤


Improve testing to check for edge cases

Some tests need to done to ensure proper workflow of the the website. Refer to #149 for example.

I think this have been addressed via the other referenced issue, so we can close? @goneall

@jlovejoy It's a pretty general issue and still applicable to other workflow items.  I'm 50/50 on keeping it open.
@rtgdk what do you think?

Yeah, the automated testing state is in very bas shape right now. Some tests don't even finish locally due to jpypy getting stuck. Also, tests hardly covers all the cases so I think we should keep this one open.
I plan to take a look at this once I get time 😅


Replace Mediator with ScopedMediator in Blazor Server

This pull request refactors the Blazor Server project by replacing the existing Mediator with ScopedMediator. The changes ensure that the mediator's lifetime is correctly scoped per request, improving resource management and avoiding potential issues related to singleton services. This update aligns the application with best practices for Blazor Server environments.

#699


Update to issues templates

Reassigned to Ken as was discussed in Friday's call...

Sam, can this be closed because #29 replaces it?

I'm closing this as it is now conflicted because I accepted PR #29.  FYI, I have had to make a couple of commits to clean up the templates folder so update your local copy...


Is it possible to avoid redirects to 3rd parties?

When using the NPM package, it seems to follow redirects to 3rd parties, then analyzes them. Is it possible to disable this behavior? Here's an example of code where this happens...
async function wappalyze(url) {
  try {
    const wappalyzer = new Wappalyzer()
    await wappalyzer.init()
    const result = await wappalyzer.open(url).analyze()

    console.log(JSON.stringify(result, null, 2))
    await wappalyzer.destroy()
  } catch (error) {
    console.error(error)
  }
}

Output example...
{
  "urls": {
    "https://example.com/": {
      "status": 302
    },
    "https://someThirdParty": {
      "status": 200
    }
  },
  "technologies": []
}

Thanks!

Also see #5304. I'll be making some changes around this but I don't think the initial redirect should be avoided in normal cases. We could add an option to disable redirects completely if that helps.

This has been added in 1097edd. By default, cross-domain redirects are only allowed on the first request. To disable redirects on all requests you can set noRedirect to true or pass --no-redirect or -N.

Thanks!


[stable/prometheus] upgrade impossible since ClusterIP changes

Is this a BUG REPORT or FEATURE REQUEST? bug
Version of Helm and Kubernetes: 2.8.2, kube 10.0
Which chart: stable/prometheus
What happened: upgrade failed from chart version 6.1.2 -> 6.2.1
$ helm whatup
...
There is an update available for release prometheus (prometheus)!
Installed version: 6.1.2
Available version: 6.2.1

$ helm upgrade prometheus stable/prometheus
Error: UPGRADE FAILED: Service "prometheus-kube-state-metrics" is invalid: spec.clusterIP: Invalid value: "": field is immutable && Service "prometheus-node-exporter" is invalid: spec.clusterIP: Invalid value: "": field is immutable

Anything else we need to know:
This is likely due to the change in https://github.com/kubernetes/charts/commit/1b11ef35d676a95f50baaafb925835e9f309cd1a
my values.yml file:
alertmanager:
  enabled: true
  nodeSelector:
    purpose: apps
  persistentVolume:
    existingClaim: prometheus-apps
    subPath: alertmanager
  resources:
    requests:
      memory: 22Mi
  ingress:
    enabled: true
    hosts:
    - prometheus-alerts.example.nl
    tls:
    - secretName: example-ssl
      hosts:
      - prometheus-alerts.example.nl
    annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
      nginx.ingress.kubernetes.io/auth-type: basic
      nginx.ingress.kubernetes.io/auth-realm: "Auth required"
      nginx.ingress.kubernetes.io/auth-secret: sysadmins
nodeExporter:
  # Run on master too
  tolerations:
    - key: node-role.kubernetes.io/master
      effect: NoSchedule
  resources:
    requests:
      memory: 12Mi
pushgateway:
  resources:
    requests:
      memory: 12Mi
  ingress:
    enabled: true
    hosts:
    - prometheus-push.example.nl
    tls:
    - secretName: example-ssl
      hosts:
      - prometheus-push.example.nl
    annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
      nginx.ingress.kubernetes.io/auth-type: basic
      nginx.ingress.kubernetes.io/auth-realm: "Auth required"
      nginx.ingress.kubernetes.io/auth-secret: sysadmins
server:
  baseURL: https://prometheus.example.nl/
  nodeSelector:
    purpose: apps
  persistentVolume:
    existingClaim: prometheus-apps
    subPath: server
  resources:
    requests:
      memory: 400Mi
  ingress:
    enabled: true
    hosts:
    - prometheus.example.nl
    tls:
    - secretName: example-ssl
      hosts:
      - prometheus.example.nl
    annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
      nginx.ingress.kubernetes.io/auth-type: basic
      nginx.ingress.kubernetes.io/auth-realm: "Auth required"
      nginx.ingress.kubernetes.io/auth-secret: sysadmins
networkPolicy:
  enabled: false

Cluster IP was previously set to None which causes a cluster IP to not be allocated.  6.2.1 sets cluster IP to "" to allow a cluster IP to be allocated.  Due to this a direct update of the service from < 6.2.1 is not possible.  Upgrades from 6.2.1 and forward will not have this issue.

It seems like the use of None for the cluster IPs of those services was likely intentional? That pattern is called a "headless service": https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
In this case, it looks like the idea was to provide a way for Prometheus to discover the exporters, but nothing needs to actually send network traffic to that service, so it doesn't need to be given an IP. Is there a reason to give those services, engine-prometheus-node-exporter and engine-prometheus-kube-state-metrics, an IP?
If there is a good reason to do that, then it seems like that breaking change should cause the chart version to bump to 7.0.0 in order to communicate that fact. Let me know if I'm missing something here!

@kujenga I remember running into an upgrade issue, but off the top of my head I can't remember what the issue was.  It might make sense to just revert those cluster ip changes back to None for now.

Okay, I'll open a PR for that against this repository with that. If you recall the specific issues that lead to the change I'd be happy to look into them as well!


Plugin Review PR

Codecov Report

:exclamation: No coverage uploaded for pull request base (dummy-master@888455f). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff               @@
##             dummy-master      #72   +/-   ##
===============================================
  Coverage                ?   38.06%
===============================================
  Files                   ?        7
  Lines                   ?      557
  Branches                ?        0
===============================================
  Hits                    ?      212
  Misses                  ?      326
  Partials                ?       19

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 888455f...b82b516. Read the comment docs.

@larkox / @hanzei This is to review technical requirements are met for adding a plugin to the marketplace: https://developers.mattermost.com/extend/plugins/community-plugin-marketplace/#requirements-for-adding-a-community-plugin-to-the-marketplace
@jupenur Similarly, this is to review security requirements are met: https://developers.mattermost.com/extend/plugins/community-plugin-marketplace/#requirements-for-adding-a-community-plugin-to-the-marketplace
@DHaussermann I just tagged you for visibility, but you can continue to work with Jesús (and myself) for QA review.
BIG thanks everyone in advance!
cc @seansackowitz Completely optional for you to review the PR, of course, but feedback is more than welcome :)

Just for the record, security review is also in progress. I'll create Jira tickets for issues instead of commenting here directly, since the repo is public.

A couple of non-blocking UX-y comments:

Should JitsiURL default to https://meet.jit.si? Seems like that would be a friendlier experience.
Does Jitsi automatically generate secrets you can export to this plugin for JWT auth? If not, I think the plugin should provide automatic generation instead of just manual entry.
If you set a topic for a meeting, it also becomes the meeting name; that seems counter-intuitive and potentially insecure. At the very least the behavior should be clearly documented, but I'd prefer removing it altogether.

@jupenur about the https://meet.jit.si I think is a great idea, but I'm not sure if it should be the default value or the placeholder. What do you think @jasonblais?
About the secrets generation, the secrets comes from the Jitsi instance, here we are just using the ID and the secret to sign the JWT messages to be trusted by the Jitsi server. But the Jitsi server is the source of thru there. We can generate them, but I'm not 100% sure if that makes sense, for sure you want to allow to write the values by hand.
We can allow the users to use meeting names and somehow add a meeting id, but at the end of the day, you may want to build meetings that have guessable ids, for example, I'm ok having a meeting for "developers-meeting" that is guessable, because I don't mind people to access there. I only see the need of non-guessable ids for private/secret meetings.
For example, the personal meeting room, is not guessable (yo can infer it, with some data), but it doesn't change, so, once you know the personal meeting room of somebody, you can enter there whenever you want.

1 - @jespino I'm in favor of using https://meet.jit.si as the default. Then, if someone wants to try it, they only have to enable the plugin. Very fast. Love the idea @jupenur.
BigBlueButton plugin does the same actually: https://github.com/blindsidenetworks/mattermost-plugin-bigbluebutton
(We can also adjust the help text to say something like The URL for your Jitsi server, for example https://jitsi.example.com. Defaults to https://meet.jit.si, which is the public server provided by Jitsi.
2 - @jespino @jupenur

If you set a topic for a meeting, it also becomes the meeting name

What if we called the command /jitsi [meeting name] and refer to the parameter as setting the name, not the topic of the meeting? Because that's really what we're doing.

I going to create another PR for the point 1.

@jasonblais 2. Actually we are setting both, the meeting name and the meeting topic

You're right, I got confused. I agree with Juho though that when I set the meeting topic, I only expect it to set the topic, not also the meeting name. I see the value in specifying the meeting name as well, but we are combining two things into one which is not obvious.

Here is the PR for the point 1. #83
About the point 2. What is the alternative to that? I think is a more or less expected behavior, actually what happens in the web interface.

Thanks! Reviewed #83
@jespino These are two different use cases - setting a meeting topic, and setting a meeting name.
If I wanted to create a meeting name japsjfa9fsai, I wouldn't want that to be the topic. On the other hand, if I created a meeting with topic Top Secret - Don't Share, I probably wouldn't want that to be the meeting name.
So it's two different use cases.
One question that comes to mind is, do we need both? The Zoom plugin doesn't support either, and I only found feature requests for /zoom start <meeting-id>, not for setting a meeting topic.

I think we can create an issue to investigate the posibility create meetings with name and topic separated, but I think is something extra to add, and I think the current approach is the expected behavior for any jitsi user, because is how it behaves in the jitsi app.

Actually, by the way, I think would be great to add some kind of "description" to the meeting, to show in the invitation, that is useless for the most common use (click the meeting button), but if you want to create a meeting and explain why, you can add that description, and more important, if you want to schedule a meeting every week at 6:00 pm, probably you want to explain the reason why is this meeting popping up there every week.

because is how it behaves in the jitsi app.

I see. I didn't realize this. So in Jitsi, meeting name = topic?

Yes by default, but can be different

I think the current approach is the expected behavior for any jitsi user, because is how it behaves in the jitsi app.

I would have to disagree with this. It doesn't matter what Jitsi does in it's own web UI, when the plugin doesn't align with that logic and in fact implies something completely different in the settings UI. When there's an option to explicitly define how meeting names are generated, I would expect that setting to be respected always -- unless there's a clearly marked exception.

Fair enough, @jasonblais what do you think?

If in Jitsi, "meeting name = topic", then I wonder if Jitsi even has a concept of a "topic". In which case we're confusing the experience by incorporating one (I checked other Jitsi integrations, e.g. Slack, and they just use meeting names, not "topics"). Also, as noted above, other video conference plugins for Mattermost don't let you customize the "topic" nor do I see any requests for it.
I'm also noticing that when someone posts "/jitsi ", the resulting post doesn't indicate it's a Jitsi meeting because we override the Jitsi Meeting heading and use the user's account to post the message.
So I will need to think about the user experience a little more. I can do that hopefully on Monday.
@jupenur In terms of the System Console setting - we have another setting called "Teammate Name Display" which can be overridden by the user and it doesn't say so in the help text.

I'm mentioning because /jitsi settings also allows the user to override the default meeting name generation.
Regardless, I'm open to updating the help text to something like Select how meeting names are generated by default. Can be overridden by the user in "/jitsi settings".

By default, jitsi have a meeting names and from there derives de subject, but you can set the subject manually if you want, because of that we use the topic to set the meeting subject and the I'd can be different.
I don't see it confusing, but maybe it's me. About not identifying it is a jitsi meeting is not that important, it is a videoconference meeting and you going to join or not, and normally your platform is going to have only one videoconference system installed.

Discussed meeting name generation with @jespino. We will

keep the command as /jitsi [topic] which generates a topic matching [topic] and a meeting name that appends a random string to the specified [topic].
update System Console help text for meeting naming schema to Select how meeting names are generated by default. Users can override their preference with "/jitsi settings", and create custom meetings with "/jitsi".

We'll also want to revisit the user experience with generating meeting names and topics, and also gather feedback from users on how obvious it is. I think there's still room for improvement.

The QA pass is already being done in the master branch, so I think this is a thumbs up for this review, so I guess the plugin is ready for the marketplace, unless you want to have another review for the changes since this review started.

Two new tickets in Jira:
https://mattermost.atlassian.net/browse/MM-26161
https://mattermost.atlassian.net/browse/MM-26162
Please be careful when referring to these in public issues and PRs, since upstream is also affected.

@jespino Can this PR get closed?

@hanzei yes, I think so.


what is HTC++ mean?

Dear author
I Want to know what is HTC++ mean? what is the difference between HTC and HTC++ mean?
do you have any explanation or url for me ?

Hi, you can find the explanation in the appendix (A2.2. Object detection on COCO) of the paper:
For system-level comparison, we adopt an improved HTC [9] (denoted as HTC++) with instaboost [22], stronger multi-scale training [7] (resizing the input such that the shorter side is between 400 and 1400 while the longer side is at most 1600), 6x schedule (72 epochs with the learning rate decayed at epochs 63 and 69 by a factor of 0.1), soft-NMS [5], and an extra global self-attention layer appended at the output of last stage and ImageNet-22K pre-trained model as initialization.

@zeliu98 Am I right that HTC++ mean HTC together with improvements below:

instaboost
stronger multi-scale training
6x schedule
soft-nms
global self-attention layer

Or does it mean some other HTC++, and then improved with all these?
Is there an open-source mmdet/detectron2 implementation/config of HTC++? Thank you!

What is InstaBoost? The referred paper [22] An image is worth 16X16 words: transformers for image recognition at scale  contains no mention of InstaBoost technique


Publish May 2018 Changelog

User story
As an MDN enthusiast, I want to know what was done in May 2018, so I know where MDN is improving.
Acceptance criteria

May 2018 Changelog is published on Hacks on June 8
Post is promoted on Twitter and Discourse

Tasks

[x] Gather things that shipped and June plans
[x] Submit draft to Havi
[x] Approve final draft for publishing
[x] Publish June 8
[x] Reshare on Twitter
[x] Update Discourse post
[x] Correct Interactive Examples section

@schalkneethling tells me that the Shadow DOM polyfill did ship in May, in https://github.com/mdn/interactive-examples/pull/894. I think I was relying on the meeting notes at https://github.com/mdn/interactive-examples/wiki/Weekly-Meeting-Notes#8-may-2018. I'm going to see if I can add a correction, and point to https://github.com/mdn/interactive-examples/issues?q=is%3Aissue+is%3Aopen+label%3AP1

This shipped on June 8: https://hacks.mozilla.org/2018/06/media-mathml-and-django-1-11-mdn-changelog-for-may-2018/


When CLA manager already associate with another company no need to redirect to corporate console.(As per discussion with Vinod)

Is this the ticket for the Corporate Console v2 needing to support multiple Organizations for a user in order to view/sign CCLAs and manage the approval list?

@dealako  Yes

@dealako  as discussed earlier, we will wait for the feedback from Legal about supporting CLA Manager for multiple orgs.
Please let us know when you hear from Legal about it.


feat: vendor infrastructure prvider APIs

@jimmidyson and I were briefly talking about this idea. Here is an attempt of using infra provider types that are synced from upstream repos. It is easier to work with Go types instead of unstructured.
Switched the AWS region handler to use these new types to show that it works.
An important part of this PR is the automated syncing. I added it as makefile targets to keep it simple, but can be extended if no longer enough as we add additional providers.

https://github.com/d2iq-labs/capi-runtime-extensions/pull/190/commits/aec53639e10adaa6537f937980ad856a23c52a0b here is a fun idea @faiq and I saw in some CAPI provider (don't remember which one), using a separate go.mod for each provider. This has the benefit of using dependabot to keep the version updated.
If we don't want this, we should still bring in the directory change from that commit, I think placing it in the more explicit dir is nicer common/pkg/external/sigs.k8s.io/cluster-api-provider-aws/v2/api/v1beta2/.

This is amazing!
I think I'd prefer to have a separate go module just for provider APIs rather than common. That would make it useful across other projects too, keeping dependencies to a minimum for API module. WDYT?

I love this! I've taken the liberty of making a few changes (all can be reverted if you disagree with what I've done btw):

Use go mod cache paths instead of vendoring

Moving stuff around a bit (not the final API destination btw): moved placeholder modues into hack/third-party for what feels like a "cleaner", never-import-this, kinda place.

Added CAPD to show how we can extend this for other providers nice and easily

Fixed up build stuff, golangci-lint ignoring, etc and added pre-commit hook to ensure it is kept up to date


How to transform EPSG:4326  To   EPSG:32647

Can you tell me how to transform EPSG:4326  To   EPSG:32647, show the example will be more helpful.

Thank you very much, this is useful.


Flux with telepresence

Hey guys, I started experimenting with telepresence recently. This "issue" is about the deployment swapping feature in particular.
When I instruct telepresence to proxy a locally running container to my cluster, it spins down the replicas of the initial deployment temporarily from n to 0 and creates another deployment with one instance of my proxied container. Everything works as intended so far.
Just until flux runs another sync cycle, applying all configuration and restoring the n instances which were scaled down to 0 for telepresence development. Now the proxied local container competes/gets loadbalanced against the remote instances and makes actual development near impossible.
I don't have a clear solution in mind, but is there a way to tell flux to pause syncing for a while and therefore not touch the replica settings of a spun down deployment?

You can annotate a resource with flux.weave.works/ignore: "true" and fluxd will not attempt to sync it. Either in the file, or in the cluster object.

Thank you. Works. 👍
Didn't think it would work with just annotating the cluster object and not the file.
At least we have a solution for anybody coming across this issue in the future 😁


Database error when running post_process from WP-CLI

Error on output is:
WordPress database error Unknown column 'blob_value' in 'field list' for query SELECT blob_value FROM wp_wp2static_core_options WHERE name = 'hostsToRewrite' LIMIT 1 made by include('phar:///usr/bin/wp/php/boot-phar.php'), include('phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php'), WP_CLI\bootstrap, WP_CLI\Bootstrap\LaunchRunner->process, WP_CLI\Runner->start, WP_CLI\Runner->run_command_and_exit, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, WP2Static\CLI->post_process, WP2Static\PostProcessor->processStaticSite, WP2Static\FileProcessor->processFile, do_action('wp2static_process_html'), WP_Hook->do_action, WP_Hook->apply_filters, WP2Static\SimpleRewriter::rewrite, WP2Static\SimpleRewriter::rewriteFileContents, WP2Static\CoreOptions::getLineDelimitedBlobValue, WP2Static\CoreOptions::getBlobValue

Error occurred when running wp wp2static post_process in a basic site in Lokl.

probably related to https://github.com/leonstafford/wp2static/pull/809


[Bug] Can not delete first item

I have the same problem. Did you find any solution?

There is PR ready to merged. Is it possible release this bug fix?

Same issue here


Enable fetching more search results

At present, we fetch the 20 most recent search results, and do not provide a way for the user to get more. This can lead to a bad experience when the user is looking for an older message. We should:

Fetch additional search results when the user scrolls up from the search results that have already been fetched.
Consider fetching more results (100?) in the first place, as 20 is quite low when the query is not very specific.

The implementation of this will require some refactoring and be a bit tricky.
For the message list in all cases other than search, we get the messages from our global Redux store, and the way to fetch more is to go and do a fetch that puts the results into the global Redux store. So that's what the fetchMore function in src/webview/handleOutboundEvents.js does, dispatching a fetchOlder or fetchNewer thunk action.
But in the case of search, the list of messages isn't in the global Redux state; instead it's in the local state of the SearchMessagesScreen component. We do that because, especially with search-as-you-type causing lots of searches, we don't want to be keeping around indefinitely the results of all the different searches you've done.
As a result, in order to fetch more messages and have them show up in the list, we need to do a fetch that will put the results into that screen's local state.
The first step we'll need for this is to wire things up so that the parent of MessageList passes in a pair of callbacks to tell it how to fetch more messages. These can probably just be props called fetchOlder and fetchNewer, and then in handleOutboundEvents.js we'll have
-    dispatch(fetchOlder(narrow));
+    fetchOlder();

and similarly for fetchNewer.
That step should be a pure refactor with no functional change; in the search case we can pass no-op callbacks for those props.
Then, we'll want to implement those callbacks for search. This will interact with the other state on SearchMessagesScreen. Here's some thoughts on that:

The existing state structure has some trickiness because the query whose results we're showing isn't necessarily the latest one the user entered, if that latest one hasn't yet gotten a response or didn't succeed.
We should be sure we never end up showing a mixture of results from one query and results from another.
On scroll, the query we fetch more messages for should probably be the one we're currently showing messages for. That means we should start remembering what that query was, with a state property like query: string that we update at the same time as messages.
Then when the fetch-more-messages callback gets a response from its fetch, it needs to check that the query it used is still the current one. If not, it shouldn't store the messages, and can just return.
I think the fetch-more-messages callback doesn't need to interact with any of the lastIdSuccess, lastIdReceived, lastIdSent state; I think it can just pay attention to what the current query is.


Service types in file names do not match actual service types

It seems the contents of two files are mixed up in the ch05/service directory.
I would expect service-clusterip.yaml to define a clusterip service but this file contains a nodeport service.
kubectl create -f service-clusterip.yaml
# service/echoserver created

kubectl get svc
# NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
# echoserver   NodePort    <IP_ADDRESS>   <none>        5005:30807/TCP   6s

Meanwhile, service-nodeport.yaml defines a clusterip service.
kubectl create -f service-nodeport.yaml
# service/echoserver created

kubectl get svc
# NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
# echoserver   ClusterIP   <IP_ADDRESS>   <none>        80/TCP    5s

I swapped the contents of these two files so that file names can reflect the expected service types.

Good catch. Thanks!


decomp: finish orbit-plat and sage-finalboss

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 3 (66.67%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.001%) to 53.434%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

common/type_system/TypeSystem.cpp
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

goalc/debugger/Debugger.cpp
1
72.86%

Totals

Change from base Build<PHONE_NUMBER>:
0.001%

Covered Lines:
40856

Relevant Lines:
76461

💛  - Coveralls


delete outdated upgrade procedures

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 66.02%. Comparing base (de60fb3) to head (7f2bc27).

:exclamation:  There is a different number of reports uploaded between BASE (de60fb3) and HEAD (7f2bc27). Click for more details.
HEAD has 7 uploads less than BASE

Flag
BASE (de60fb3)
HEAD (7f2bc27)

unit
4
1

integration
4
0

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #162       +/-   ##
===========================================
- Coverage   85.91%   66.02%   -19.89%
===========================================
  Files          19       13        -6
  Lines         994      627      -367
===========================================
- Hits          854      414      -440
- Misses         92      203      +111
+ Partials       48       10       -38

Flag
Coverage Δ

integration
?

unit
66.02% <ø> (-0.49%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Components
Coverage Δ

api/v1alpha1 (u)
90.47% <ø> (-9.53%)
:arrow_down:

pkg/helpers (u)
∅ <ø> (∅)

pkg/log (u)
36.84% <ø> (-57.90%)
:arrow_down:

pkg/reconcilers (u)
36.68% <ø> (-38.00%)
:arrow_down:

pkg/limitador (u)
87.42% <ø> (-10.70%)
:arrow_down:

controllers (i)
∅ <ø> (∅)

pkg/upgrades
∅ <ø> (∅)

see 13 files with indirect coverage changes


Possible typo in paper?

Hello! Thanks for the awesome paper and open-sourcing your work!
I just had a quick question regarding some of the notation in your released paper. Specifically, on the bottom right column of page 7 under "E-M based Estimation Method", should the k=0,...N-1 be k=0,..., K-1? Since k appears to be a class index (top sentence in left column on page 8)? Wanted to double check my understanding of the method.
Thanks!

Thanks for your attention on our paper. We confirm again that the description of "k=0,1,...,N-1" is no problem. It is  worth noting that "k" is the index of class or k-th Gaussian distribution, and "N" denotes the number of classes or the number of Gaussian distribution in the Gaussian mixture distribution. However, the "K" represents the number of labeled samples (support samples) per class (please refer to the section 3.1).


[Event Request] Table 39 - Variant Code - OnValidate

Hi!
We need an additional event before the Drop Shipment check on OnValidate on Variant Code in the Purchase Line table. We need the IsHandled pattern to be included.

Thanks!

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Unpin glibc

This reverts commit a1d0cc898f9fa1cab518b94f3b7e8b52175eb50c.

Fixes

Fixes #3157 by @stacimc
Description

This PR unpins glibc that was pinned in #3154 as a security patch. With an updated python3.11-slim image containing the patched version of glibc, this is no longer necessary.
Testing Instructions

Check the glibc version in the current web image (ldd --version shows this info).
Check out this PR and build the web image again.
Check that the glibc version does not change.

Checklist

[x] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.
[ ] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@AetherUnbound I can look into updates for this image, but I have a question. This is only for the local dev environment, we don't use Docker to host the production databases so is using an unpatched image for the DB even a risk at all?


Hyper-Parameter Optimization for multivariate forecasting

Description
Hi,
Can you please share an example of how to do hyper-parameter optimization when one has exogenous variables?
The MLForecast allows for a simple way to do so by declaring the variables such as static_features, etc. But in the AutoMLForecast, how can one declare these features? If I try including this as an argument to the fit function of AutoMLForecast, it gives me an error citing that this is not a valid argument.
Looking forward to hearing soon.
Thanks!
Link
No response

Hey. The static_features argument is part of MLForecast.fit, so you have to provide it through the fit_config of the auto models. You can find an example here  which tunes whether or not the id should be included as a feature.

Clears it up. Thanks :)


Use leaf classes for ems type validation

Recent changes put the automation thingy factory back to not being a leaf class and LJ wouldn't leaf me alone so.
From comment here: https://github.com/ManageIQ/manageiq/pull/19330/files#r329235409
@miq-bot assign @jrafanie
I think this's all, right?

Don't do this. Change to use factory :automation_manager_ansible_tower instead of :automation_manager

Don't do this. Change to use factory :automation_manager_ansible_tower instead of :automation_manager

We can't.  The automation_manager factory is unusable right now.

Don't do this. Change to use factory :automation_manager_ansible_tower instead of :automation_manager

We can't. The automation_manager factory is unusable right now.

This is passing: https://github.com/ManageIQ/manageiq-content/pull/586

@jameswnl LJ's spec on https://github.com/ManageIQ/manageiq/pull/19330/files#r329235208 shows that the factory is currently unusable. It doesn't matter if the content repo is green, that's a symptom and we need to put the factory back.

This fixes an issue introduced in https://github.com/ManageIQ/manageiq/pull/19330

@jameswnl I'll merge this for now since ems factories can't be abstract/non-leaf classes, see: https://github.com/ManageIQ/manageiq/blob/c518bf5f68a63a668fe481c380f3dc8c5cddea76/app/models/ext_management_system.rb#L852
We can discuss other solutions for the original problem of preventing creation of these non-leaf classes that was implemented in https://github.com/ManageIQ/manageiq/pull/18842.  Ultimately, in that PR, we decided it was better to have all the base factories use a concrete leaf ems class from a provider to allow non-provider tests to be able to use the base factory in situations that are provider agnostic.  In other words, it's better to have provider class information in one location in the base factories than to force tests in several repos to know this class information in their tests.  Of course, if the non-provider tests are testing provider specific use cases, then they should be using the specific provider, so I think your change in https://github.com/ManageIQ/manageiq-content/pull/586 was good.
It's a gnarly problem and any other solutions would be greatly appreciated.
cc @agrare

We can discuss other solutions for the original problem of preventing creation of these non-leaf classes that was implemented in #18842. Ultimately, in that PR, we decided it was better to have all the base factories use a concrete leaf ems class from a provider to allow non-provider tests to be able to use the base factory in situations that are provider agnostic. In other words, it's better to have provider class information in one location in the base factories than to force tests in several repos to know this class information in their tests. Of course, if the non-provider tests are testing provider specific use cases, then they should be using the specific provider, so I think your change in ManageIQ/manageiq-content#586 was good.

This approach is problematic because it allows creating tests that seems general (i.e. applicable to all implementations of that provider), but in fact it depends on implementation-specific features.

This approach is problematic because it allows creating tests that seems general (i.e. applicable to all implementations of that provider), but in fact it depends on implementation-specific features.

Yes, these tests need to depend on the specific subclass factory like I mentioned was good about https://github.com/ManageIQ/manageiq-content/pull/586

This approach also creates barrier to make our providers more pluggable.

Sure, if there are better solutions to prevent non-leaf ems classes from being created, I think we're open to something better.  I think https://github.com/ManageIQ/manageiq/pull/18842 was the solution we disliked least.

I still believe ManageIQ/manageiq-content#586 is the way to go.

👍 It's ansible tower specific tests so it should use ansible tower specific factories.
This PR was merely to make the base factory usable again.  It's not the complete solution.


999- Cancelled Error

Hi,
As stated in the title, I am trying to upload a file through the CC API, which goes through the process, reporting each percentage point correctly. Once it gets to 100%, I receive the following error:
Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLKey=https://host123d1qj.cloudconvert.com/process/8Zyvqb5Q3NTReftAHlL7, NSLocalizedDescription=cancelled, NSErrorFailingURLStringKey=https://host123d1qj.cloudconvert.com/process/8Zyvqb5Q3NTReftAHlL7}
My code looks like this:
    CloudConvert.convert([
        "inputformat": "gif",
        "outputformat" : "mov",
        "input" : "upload",
        "file": file],

        progressHandler: { (step, percent, message) -> Void in

            dispatch_async(dispatch_get_main_queue(),{
                print(percent!)
                self.progressBar.hidden = false
                self.progressBar.doubleValue = Double(percent!)

                if percent == 0 || percent == 100 {
                    self.progressBar.hidden = false
                }

            })

        },
        completionHandler: { (path, error) -> Void in
            if(error != nil) {
                self.progressBar.hidden = true
                self.generalAlert("ERROR", text: "Your file could not be uploaded. Error: \(error!)")
                print("ERROR: \(error)")
            } else {
                self.progressBar.hidden = true
                self.generalAlert("MOV Uploaded", text: "Your MOV has been saved to your computer and uploaded to Cloud Convert")
            }
    })

Is the example project working correctly for you?

Closing because of inactivity


fix(v2): Algolia: allow contextualSearch + facetFilters

Motivation
Merge contextual search facetFilters with config-provided facetFilters.
Remove security: not a big deal because users will notice easily if their search is broken due to an extra useless config filter.
Fixes https://github.com/facebook/docusaurus/issues/3790
Test Plan
preview
Related PRs
https://github.com/facebook/docusaurus/pull/3550

Yes @lex111 , was actually going to fill an issue because the search page does not respect Algolia site config


GitHub Actions Cache key

The current documentation suggests to use the following cache key for GitHub actions:
${{ runner.os }}-rector-${{ hashFiles('**/composer.lock') }}

https://github.com/rectorphp/getrector-com/blob/be17729dedb91d48dbe6a904ba3f84bed391d28d/resources/docs/cache-in-ci.md?plain=1#L42
GHA caches are immutable. Therefore the cache will be stored once and updated only if the composer.lock changes. I do believe that the cache contents are dependent on non-vendor php files which might changes without alterations to the composer.lock. Therefore the cache should also be updated without changes to the composer.lock.
I suggest to change the cache key to:
rector-${{ hashFiles('**/composer.lock') }}-${{ github.run_id }}

The pattern is suggested here: https://github.com/actions/cache/blob/main/tips-and-workarounds.md#update-a-cache

/cc @staabm could you verify it? Thank you.

we usually use something like
key: ${{ steps.setup-php.outputs.php-version }}-rector-${{ github.run_id }}
restore-keys: ${{ steps.setup-php.outputs.php-version }}-rector-

${{ hashFiles('**/composer.lock') }} is not really useful, I agree.

I am not familiar with it, could you guys try create a PR for it? Thank you.

just sent https://github.com/rectorphp/getrector-com/pull/2023
@SomeBdyElse could you double check it?


Question on commit 181170f, delete button/tabindex

@kevin-brown or anyone else, in this commit, https://github.com/select2/select2/commit/181170f8a4d5c7eb4670ccd3926add33391b6b2d, it says
The clear button has also been changed to use a `<button>` element,
though it is still removed from the tab order. This allows for the
purpose to be properly communicated to screen readers while not
disrupting the natural tab order of the select box.

While I love all the changes from this commit, and agree with this being changed to a button, I don't understand the tabindex and the "the natural tab order of the select box".
With tabindex="-1", KB only user cannot tab-to or access this item to delete. Can anyone explain why tabindex="-1" helps or fixes? I update the DOM to "correct" this and it works great for me. I just wonder why it's not the default.
Thanks

The clear button is not focusable by standard keyboards without assistance. Select2 has key bindings for triggering the clear button (DELETE I believe, BACKSPACE in some cases) for those without tools overriding standard key bindings.

kevin-brown Thanks for the reply.
I am very glad that actual thought was given to this topic. I now understand that what is meant by "the natural tab order of the select box" is the "usual way tab works for a normal select element". I can respect that.
However, the issues are these:

This is not a select input anymore, it's a "custom user control", and now has more responsibility than select element alone has. With great power comes great responsibility.
Delete does nothing I can tell, and backspace does work, but it's weird. These "issues", a) you need to hit backspace and then esc to quickly remove an item and b) you can only remove the last item.
Having any action-button that cannot be accessed with the KB is bad. This makes sense to me and comes from complaints I have received from paid "Level Access" evaluations.

I have no issues with changing my local select2, changing it to have a tabindex on these buttons, but it seems like it should be that way already. Another option, which I think would be in line with WCAG, would be to use the arrow keys to focus the delete buttons. I think this would address KB access to the buttons AND preserve "the natural tab order of the select box".
What do you think?


Add ?parent= query param to GET /tenants to view all tenants that share a parent tenant

I'm submitting a ...

[ ] bug report
[x] new feature / enhancement request
[ ] improvement request (usability, performance, tech debt, etc.)
[ ] other

Traffic Control components affected ...

[ ] CDN in a Box
[ ] Documentation
[ ] Grove
[ ] Traffic Control Client
[ ] Traffic Monitor
[x] Traffic Ops
[ ] Traffic Ops ORT
[ ] Traffic Portal
[ ] Traffic Router
[ ] Traffic Stats
[ ] Traffic Vault
[ ] unknown

Current behavior:
All tenantable resources (ds, dsr, origin and user) except for tenants (which is also a tenantable resource) can be filtered based on their direct tenancy assignment. i.e.
GET /api/deliveryservices?tenant= <-- gives you all the ds's directly assigned to the tenant
GET /api/deliveryservice_requests?tenant= <-- gives you all the dsr's directly assigned to the tenant
GET /api/origins?tenant= <-- gives you all the origins directly assigned to the tenant
GET /api/users?tenant= <-- gives you all the users directly assigned to the tenant

Expected / new behavior:
Add the ability to filter tenants based on their direct tenancy assignment. i.e.
GET /api/tenants?parent= <-- gives you all the tenants directly assigned to the (parent) tenant

This differs from accessibleTo in that it returns only those Tenants that are the direct child of the parent with the specified identifier? That is in a tree like: root -> A ->B if I request GET /tenants?parent={{whatever the ID of root is}} I'll get back a response containing only A?

That is in a tree like: root -> A ->B if I request GET /tenants?parent={{whatever the ID of root is}} I'll get back a response containing only A?

yes, but i can't remember for the life of me why i suggested this so i guess i'll close.


Add the missing title and text explaining how to use the playbook

TODO
Add a title and text, part of the file, to explain how to use the playbook referenced as currently the link to the playbook is showed end of the file without any text to introduce it.

Note: The section VM required information should be better introduced too.

Question: Does it make sense to have 2 files; this one and the link to the ansible openstack doc file or only one ?

Today, the documentation has been developed around 3 levels where level 1 is the README.adoc project file, 2nd level corresponds to a module that we support (kind, ibm-cloud, openstack, hetzner) and 3rd to files living close the place where we handle the code: playbooks, etc

NOTE: If I remember correctly the idea/plan was using. tool to generate the playbook/role documentation. Correct ? @jacobdotcosta

WARNING: Some projects, like ibm-cloud do not follow this org as documentation and playbooks are maintained within the 2nd level ibm-cloud !!


CUDA Driver and CUDA runtime version mismatch after update

Expected Behavior
Application was working. Application now fails with error. Everything worked great previously. My driver and card appear functional as I can build the test nvidia projects, it passes dlib build, and I can also use hashcat with my GPU for password cracking just fine. The error appears to be in the gpu_data.cpp code.
Current Behavior
Traceback (most recent call last):
  File "./example.py", line 2, in <module>
    from ml_face import *
  File "/home/aaron/Development/bulk-image-facial-recognition/ml_face.py", line 1, in <module>
    import face_recognition
  File "/usr/lib/python3.6/site-packages/face_recognition/__init__.py", line 7, in <module>
    from .api import load_image_file, face_locations, batch_face_locations, face_landmarks, face_encodings, compare_faces, face_distance
  File "/usr/lib/python3.6/site-packages/face_recognition/api.py", line 21, in <module>
    cnn_face_detector = dlib.cnn_face_detection_model_v1(cnn_face_detection_model)
RuntimeError: Error while calling cudaGetDevice(&the_device_id) in file /home/aaron/Development/tmp/dlib/dlib/dnn/gpu_data.cpp:178. code: 35, reason: CUDA driver version is insufficient for CUDA runtime version

The line in question is -
                CHECK_CUDA(cudaGetDevice(&the_device_id));

Steps to Reproduce

Update to latest drivers for nvidia provided by manjaro

Attempt to run application

Receive error.

 nvidia-smi                                                                                1 < 06:39:20
Mon Dec 25 06:40:53 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.98                 Driver Version: 384.98                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GPU         Off  | 00000000:01:00.0 Off |                  N/A |
| N/A   43C    P8    N/A /  N/A |     11MiB /  1998MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0       345      G   /usr/lib/xorg-server/Xorg                      8MiB |
+-----------------------------------------------------------------------------+

Version: Latest 19.8.99
Where did you get dlib: GitHub
Platform:

lsb_release -a                                                                                127 < 06:42:23
LSB Version:	n/a
Distributor ID:	ManjaroLinux
Description:	Manjaro Linux
Release:	17.1-rc2
Codename:	Hakoila

Compiler: gcc-6

Did you recompile dlib against the new cuda toolkit after installing the new cuda toolkit?

Affirmative. I performed a completely fresh build of dlib.

export CC=/usr/bin/gcc-6; cmake .. -DUSE_AVX_INSTRUCTIONS=1; cmake --build .;
python3 setup.py install --yes USE_AVX_INSTRUCTIONS

Those are the two commands I ran.

Don't do all that stuff.  Just python3 setup.py install --yes USE_AVX_INSTRUCTIONS.   There is all this nonsense on the internet about building dlib before running setup.py, you don't need to do that.
Anyway, this isn't a bug in dlib.  There is something wrong with your cuda runtime install.  I would try reinstalling cuda.


python311Packages.mypy-boto3-*: updates

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 297107 run on x86_64-linux 1

2 packages marked as broken and skipped:

python311Packages.dependency-injector
python311Packages.dependency-injector.dist

44 packages built:

aws-sam-cli
aws-sam-cli.dist
pacu
pacu.dist
python311Packages.boto3-stubs
python311Packages.boto3-stubs.dist
python311Packages.botocore-stubs
python311Packages.botocore-stubs.dist
python311Packages.dsnap
python311Packages.dsnap.dist
python311Packages.mypy-boto3-cloudformation
python311Packages.mypy-boto3-cloudformation.dist
python311Packages.mypy-boto3-kms
python311Packages.mypy-boto3-kms.dist
python311Packages.mypy-boto3-mediatailor
python311Packages.mypy-boto3-mediatailor.dist
python311Packages.mypy-boto3-rds
python311Packages.mypy-boto3-rds.dist
python311Packages.mypy-boto3-s3
python311Packages.mypy-boto3-s3.dist
python311Packages.mypy-boto3-timestream-query
python311Packages.mypy-boto3-timestream-query.dist
python311Packages.types-aiobotocore
python311Packages.types-aiobotocore.dist
python312Packages.boto3-stubs
python312Packages.boto3-stubs.dist
python312Packages.botocore-stubs
python312Packages.botocore-stubs.dist
python312Packages.dsnap
python312Packages.dsnap.dist
python312Packages.mypy-boto3-cloudformation
python312Packages.mypy-boto3-cloudformation.dist
python312Packages.mypy-boto3-kms
python312Packages.mypy-boto3-kms.dist
python312Packages.mypy-boto3-mediatailor
python312Packages.mypy-boto3-mediatailor.dist
python312Packages.mypy-boto3-rds
python312Packages.mypy-boto3-rds.dist
python312Packages.mypy-boto3-s3
python312Packages.mypy-boto3-s3.dist
python312Packages.mypy-boto3-timestream-query
python312Packages.mypy-boto3-timestream-query.dist
python312Packages.types-aiobotocore
python312Packages.types-aiobotocore.dist


Negative health

Monsters sometimes die but most of the time just go into negative health as seen here

fixed. There is no longer negative health.


fix usage of path instead of filepath

Windows volume guid paths (ex: "\?\Volume{26a21bda-a627-11d7-9931-806e6f6e6963}\tmp\k3s") can get tripped up if you mix slash and backslash.
When dealing with files, filepath should be used.

This addresses issue https://github.com/rancher/k3s/issues/1687


[Event Request] Table 36 "Sales Header" - OnBeforeUpdateBillToCont

Hi, would it be possible to get an OnBeforeUpdateBillToCont event in table 36 (Sales Header), like this:
    procedure UpdateBillToCont(CustomerNo: Code[20])
    var
        ContBusRel: Record "Contact Business Relation";
        Cust: Record Customer;
        Contact: Record Contact;
        IsHandled: Boolean;
    begin
        // New Event begin
        IsHandled := false;
        OnBeforeUpdateBillToCont(Rec, CustomerNo, SkipBillToContact, IsHandled);
        if IsHandled then
            exit;
        // New Event end

        if Cust.Get(CustomerNo) then begin
            if Cust."Primary Contact No." <> '' then
                "Bill-to Contact No." := Cust."Primary Contact No."
            else begin
                ContBusRel.Reset();
                ContBusRel.SetCurrentKey("Link to Table", "No.");
                ContBusRel.SetRange("Link to Table", ContBusRel."Link to Table"::Customer);
                ContBusRel.SetRange("No.", "Bill-to Customer No.");
                if ContBusRel.FindFirst then
                    "Bill-to Contact No." := ContBusRel."Contact No."
                else
                    "Bill-to Contact No." := '';
            end;
            "Bill-to Contact" := Cust.Contact;
        end;
        if "Bill-to Contact No." <> '' then
            if Contact.Get("Bill-to Contact No.") then
                Contact.CheckIfPrivacyBlockedGeneric;

        OnAfterUpdateBillToCont(Rec, Cust, Contact);
    end;

    [IntegrationEvent(false, false)]
    local procedure OnBeforeUpdateBillToCont(var SalesHeader: Record "Sales Header"; CustomerNo: Code[20]; var SkipBillToContact: Boolean; var IsHandled: Boolean)
    begin
    end;

Thanks!

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.