Enum maps in swagger.g.dart are missing 'enums.' prefix to correctly point at imported enums

api_name.swagger.dart file contains these lines:
import 'lasso.enums.swagger.dart' as enums;
export 'lasso.enums.swagger.dart';

and when referencing an enum in this same file (notice the preceding enums.):
@JsonKey(name: 'my_enum')
final enums.MyEnum? myEnum;

but the part file api_name.swagger.g.dart attempts to access them this way:
const _$MyEnum = {
  MyEnum.swaggerGeneratedUnknown: 'swaggerGeneratedUnknown',
  MyEnum.hourly: 'hourly',
  MyEnum.daily: 'daily',
  MyEnum.weekly: 'weekly',
};

This gives the following errors:

Const variables must be initialized with a constant value.
Try changing the initializer to be a constant expression.dartconst_initialized_with_non_constant_value
Undefined name 'MyEnum'.
Try correcting the name to one that is defined, or defining the name.

By manually adding enums. preceding each MyEnum reference, the errors are corrected. Am I missing a build option / flag or is this incorrectly generated the swagger.g.dart enum map code?
My working code looks like this:
const _$MyEnum = {
  enums.MyEnum.swaggerGeneratedUnknown: 'swaggerGeneratedUnknown',
  enums.MyEnum.hourly: 'hourly',
  enums.MyEnum.daily: 'daily',
  enums.MyEnum.weekly: 'weekly',
};

Unfortunately, there are far too many references for me to do this by hand. And besides, if this is a real bug, we should fix it at the source. Thanks in advance!

Hi @point-source ,
json_serializable file with .g postfix should not know about enums.
We add @JsonKey(fromJson: customMethod) for enum properties. If it not happend - please share swagger file with error and I will fix generator.

Here is the swagger file: https://gist.github.com/point-source/06bf4559145ecd01a2d806df61895b81

I'm having a similar issue where enums defined in the swagger file are mentioned the *.swagger.dart file, but the correspondent enum is not generated in *.enums.swagger.dart file.
In this example, I have a schema model with a property icon, which has a string property called name and an enum property called kind:
{
  "openapi": "3.0.1",
  "info": {
    "title": "API V1",
    "version": "v1"
  },
  "components": {
    "schemas": {
      "model": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string",
            "nullable": true
          },
          "icon": {
            "type": "object",
            "properties": {
              "kind": {
                "type": "string",
                "enum": [
                  "icon",
                  "image"
                ]
              },
              "name": {
                "type": "string"
              }
            }
          }
        }
      }
    }
  }
}

The *.swagger.dart will mention enums.Model$IconKind but the *.enums.swagger.dart file is not generated.
When a new schema is created for icon and referenced as in model, then the enum is properly generated:
{
  "openapi": "3.0.1",
  "info": {
    "title": "API V1",
    "version": "v1"
  },
  "components": {
    "schemas": {
      "icon": {
        "type": "object",
        "properties": {
          "kind": {
            "type": "string",
            "enum": [
              "icon",
              "image"
            ]
          },
          "name": {
            "type": "string"
          }
        }
      },
      "model": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string",
            "nullable": true
          },
          "icon": {
            "$ref": "#/components/schemas/icon"
          }
        }
      }
    }
  }
}

This could be a workaround for some cases, but it would be great if it could handle both cases.

This issue is affecting the Plaid spec as well: https://github.com/plaid/plaid-openapi/blob/master/2020-09-14.yml
Tested with the 2.0.9 branch.

I will check it

@point-source could you please confirm that issue was reproduced with the latest 2.0.8 version?

@fryette Unfortunately, when I try to build with 2.0.8 I encounter this error:
[SEVERE] json_serializable:json_serializable on lib/generated/plaid_service.swagger.dart:

Could not generate `fromJson` code for `ytdEarnings`.
To support the type `Null` you can:
* Use `JsonConverter`
  https://pub.dev/documentation/json_annotation/latest/json_annotation/JsonConverter-class.html
* Use `JsonKey` fields `fromJson` and `toJson`
  https://pub.dev/documentation/json_annotation/latest/json_annotation/JsonKey/fromJson.html
  https://pub.dev/documentation/json_annotation/latest/json_annotation/JsonKey/toJson.html
package:dart_plaid/generated/plaid_service.swagger.dart:17364:15
      ╷
17364 │   final Null? ytdEarnings;
      │               ^^^^^^^^^^^
      ╵

which I believe is because 2.0.8 (at least) does not handle this type:
"ytd_earnings": {
                        "allOf": [
                            {
                                "$ref": "#/components/schemas/PaystubYTDDetails"
                            }
                        ]
                    }

So I manually removed that property as a test and it did build though the original enum related issue remains the same. Hopefully that helps. Let me know if there's anything else I can do.

Ok let me see. I've fixed next swagger file
https://github.com/plaid/plaid-openapi/blob/master/2020-09-14.yml
Anything else to fix in this issue?
@point-source  @miguelcmedeiros

Awesome! Thank you so much. I can test this in about an hour.

@point-source  test it from branch for now. Tomorrow I will release it to pub.dev. just need to test changes a bit

Yep, this appears fixed in the 2.0.8_plus branch. Thanks!


Not compiling on windows

Hello, this package doesn't seem's to compile on Windows:
CC: libzip_all
Error: execution of an external compiler program 'clang.exe -c  -w -DWIN32_LEAN_AND_MEAN -IC:\Users\roman\Documents\vcpkg/installed/x64-windows/include  -IC:\Users\roman\Desktop\nim-1.0.4\lib -IC:\Users\roman\CLionProjects\atomicDEX-QT\atomic_dex_desktop\tools -o C:\Users\roman\nimcache\dependencies_d\libzip_all.c.o C:\Users\roman\.nimble\pkgs\zip-0.2.1\zip\private\libzip_all.c' failed with exit code: 1

C:\Users\roman\.nimble\pkgs\zip-0.2.1\zip\private\libzip_all.c:193:17: error: function cannot return function type 'int (void *, void *, size_t, enum zip_source_cmd)' (aka 'int (void *, void *, unsigned long long, enum zip_source_cmd)')
typedef ssize_t (*zip_source_callback)(void *state, void *data,
                ^
C:\Users\roman\.nimble\pkgs\zip-0.2.1\zip\private\libzip_all.c:226:29: error: function cannot return function type 'ssize_t' (aka 'int (int *)')
ZIP_EXTERN ssize_t zip_fread(struct zip_file *, void *, size_t);
                            ^
C:\Users\roman\.nimble\pkgs\zip-0.2.1\zip\private\libzip_all.c:505:5: error: unknown type name 'zip_source_callback'
    zip_source_callback f;
    ^
C:\Users\roman\.nimble\pkgs\zip-0.2.1\zip\private\libzip_all.c:719:9: error: use of undeclared identifier 'pid_t'
        pid_t pid;
        ^
C:\Users\roman\.nimble\pkgs\zip-0.2.1\zip\private\libzip_all.c:727:9: error: use of undeclared identifier 'pid'
        pid = getpid();

Compiler: clang-9
Nim Compiler: 1.0.4
Windows 10.
Usage:
when defined(windows):
    {.passC: "-I"  & os.getEnv("VCPKG_ROOT") & "/installed/x64-windows/include"}
    {.passL: "-L"  & os.getEnv("VCPKG_ROOT") & "/installed/x64-windows-static/lib -lzlib -lz"}
import zip/zipfiles

Having this problem as well.  I would expect the nim install zip to also install any required .dll files and understand their required linking.

Allright - so I've installed zlib:
PS C:\Users\bubth\Development\vcpkg> .\vcpkg.exe install zlib:x64-windows
Computing installation plan...
The following packages are already installed:
    zlib[core]:x64-windows
Package zlib:x64-windows is already installed

Total elapsed time: 393.1 us

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

PS C:\Users\bubth\Development\vcpkg>

My nim file adds the windows import information:
import os

when defined(windows):
  {.passC: "-I"  & os.getEnv("VCPKG_ROOT") & "/installed/x64-windows/include"}
  {.passL: "-L"  & os.getEnv("VCPKG_ROOT") & "/installed/x64-windows-static/lib -lzlib -lz"}

import zip/gzipfiles

block:
  let vcf = newGzFileStream("test.txt.gz")  # Open gzip file
  var line: string  # Declare line variable

  # Loop over each line in the file
  while not vcf.atEnd():
    line = vcf.readLine()
    echo line

And I'm still getting errors when running but not when compiling:
PS C:\Users\bubth\Development\nim> nim c .\read_gzip.nim
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: read_gzip [Processing]
Hint: os [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: macros [Processing]
Hint: algorithm [Processing]
Hint: unicode [Processing]
Hint: pathnorm [Processing]
Hint: osseps [Processing]
Hint: winlean [Processing]
Hint: dynlib [Processing]
Hint: times [Processing]
Hint: options [Processing]
Hint: typetraits [Processing]
Hint: time_t [Processing]
Hint: gzipfiles [Processing]
Hint: zlib [Processing]
Hint: streams [Processing]
Hint:  [Link]
Hint: operation successful (37187 lines compiled; 1.185 sec total; 46.895MiB peakmem; Debug Build) [SuccessX]
PS C:\Users\bubth\Development\nim> .\read_gzip.exe
could not load: zlib1.dll
PS C:\Users\bubth\Development\nim>

It looks like the package assumes that you have zlib1.dll in your path already.  For linux, this is true, but for windows this is only the case if you've installed and configured vscode or something similar already.  For a bare install of windows you'll have to download the dll from somewhere (I used vcpkg) and make sure it's added to your path.
It seems more reasonable to include the dll, so, etc files in the nim package and then choose which one to use based on OS, rather than assuming that the OS has it installed.

I have a different problem:
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x117): undefined reference to `zError'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x2dcb): undefined reference to `crc32'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x2e71): undefined reference to `deflateInit2_'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x2f1c): undefined reference to `deflateEnd'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x2f8a): undefined reference to `crc32'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x2fb4): undefined reference to `deflate'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x30bc): undefined reference to `deflateEnd'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x3997): undefined reference to `zError'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x3a4a): undefined reference to `inflateEnd'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x3ba9): undefined reference to `crc32'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x3c9d): undefined reference to `crc32'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x4251): undefined reference to `inflateInit2_'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x453f): undefined reference to `crc32'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x6cfe): undefined reference to `crc32'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x6d69): undefined reference to `inflate'
C:\...\nim_builder_d\libzip_all.c.o:libzip_all.c:(.text+0x6df5): undefined reference to `crc32'

Any ideas what's missing?

I also have the same issue as @matkuki. This is compiling a file with only the line: import zip/zipfiles on windows 10, nim 1.4, gcc 8.1.0 (also tried to nimble install zip@#head).

Hey @pietroppeter, do you think you could maybe create a PR that you mentioned here? It seems like this issue will haunt zip library for eternity, and if it's possible to fix this, I'd absolutely appreciate anything that can help with it.

Hi @Toma400, sorry but I do not have a windows machine anymore so I do not think I would be able to test a PR (honestly also in this period I really do not have bandwidth to contribute here). IIRC there was already some working code somewhere and the effort was just to package into it a PR and test it locally before sending for approval


Hds 392 - Remove 'Use shipping as billing address' on credit card form in accounts tab

On Hold until HDS-461 is merged
Description
For Reference: HDS-392

[x] I have updated the acceptance criteria on the task so that it can be tested

Can you pull in the most recent changes from dev? Its hard to see what changed beause its including changes from updating angular

yup! it was on Draft until the angular 11 got merged. i'll go back and update now.

There are conflicts on this

resolved. until any other PR is merged in, that is 😬


electron{,-bin}: add passthru.dist attribute and use treewide

Description of changes
Now that I have more experience with packaging electron apps on Darwin, I think it would be useful to have a common interface between the platforms for accessing the electron files.
Previously you'd something like electron + (if stdenv.isDarwin then "/Applications" else "/libexec/electron") if you wanted to get the electron directory that's expected by electron-builder or electron-packager.
With this PR, you'll be able to just write electron.dist to access the directory.
I implemented this using passthru, but an extra "dist" output would essentially be the same, though that would require a rebuild.
@yayayayaka what do you think of this?

Things done

Built on platform(s)

[x] 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 run on x86_64-linux 1

24 packages built:

bitwarden-desktop
bitwarden-directory-connector
blockbench
bruno
drawio
drawio-headless
feishin
jitsi-meet-electron
koodo-reader
kuro
pandoc-drawio-filter
pandoc-drawio-filter.dist
podman-desktop
python311Packages.mkdocs-drawio-exporter
python311Packages.mkdocs-drawio-exporter.dist
python312Packages.mkdocs-drawio-exporter
python312Packages.mkdocs-drawio-exporter.dist
redisinsight
ride
siyuan
teams-for-linux
vesktop
whalebird
youtube-music

@yayayayaka Not sure if this is expected, but I didn't get any builds on x86_64 at least.
Result of nixpkgs-review pr 313442 run on x86_64-darwin 1

3 packages marked as broken and skipped:

electron-fiddle
ride
teams-for-linux

@yayayayaka Not sure if this is expected, but I didn't get any builds on x86_64 at least.
Result of nixpkgs-review pr 313442 run on x86_64-darwin 1

3 packages marked as broken and skipped:

electron-fiddle
ride
teams-for-linux

This is exected since darwin doesn't have an extra layer of indirection, since it uses electron-bin as the electron package.
Linux only has rebuilds because packages are now using electron-unwrapped's directory instead of the wrapped electron's directory (which is just a symlink to the directory of unwrapped)

Result of nixpkgs-review pr 313442 run on aarch64-darwin 1

3 packages marked as broken and skipped:

electron-fiddle
ride
teams-for-linux

Okay, so this probably is out of the scope of this PR, but I think we should decide on what is preferred of dealing with Linux when also supporting Darwin:
having extra logic in place to avoid creating a local copy of the electron dist directory on linux, since we don't need a writable directory there
or
to have it always be copied
Maybe I could start a tracking issue about Darwin support for electron apps and discuss there.

This feels reasonable to me.

The main issus is that if we want to support Darwin, the directory used must be writable... In the case of bruno, it didn't care about building on Darwin, that's why it just used electron.dist directly.

The main issue is that if we want to support Darwin, the directory used must be writable... In the case of bruno the original script didn't care about building on Darwin, that's why it just used electron.dist directly.

I'm not sure we are talking about the same thing quite. bruno's package uses the pattern seen in a few other packages you modified in this PR: For Darwin, it copies electron to its writable build directory. I was suggesting the same change for bruno as seen for feishin where the Darwin specific code changes from ${electron}/Applications/... to ${electron.dist}/.... Not a big deal, just seemed like something you were aiming to do.

The main issue is that if we want to support Darwin, the directory used must be writable... In the case of bruno the original script didn't care about building on Darwin, that's why it just used electron.dist directly.

I'm not sure we are talking about the same thing quite. bruno's package uses the pattern seen in a few other packages you modified in this PR: For Darwin, it copies electron to its writable build directory. I was suggesting the same change for bruno as seen for feishin where the Darwin specific code changes from ${electron}/Applications/... to ${electron.dist}/.... Not a big deal, just seemed like something you were aiming to do.

Yeah, sorry I misunderstood, since the preview was too small to see the darwin-secific code.

Any reason this hasn't been merged yet?


LC0044: Records 'Recipe Planning Entry PTE' and 'A104 Production Batch Line' have conflicting fields with the same ID

It seams that enum types are not correctly checked:
RecipePlanningEntry.TransferFields(ProdBatchLine, false);
[{
"resource": "/d:/DevOps/Customers/TenCateFabrics-BC23-NL/Source/src/RecipePlanningEntry.Table.al",
"owner": "generated_diagnostic_collection_name#2",
"code": {
"value": "LC0044",
"target": {
"$mid": 1,
"path": "/StefanMaron/BusinessCentral.LinterCop/wiki/LC0044",
"scheme": "https",
"authority": "github.com"
}
},
"severity": 4,
"message": "Conflicting ID, Name or Type with Table 'A104 Production Batch Line'",
"source": "AL",
"startLineNumber": 33,
"startColumn": 9,
"endLineNumber": 37,
"endColumn": 10
}]

Might be related to https://github.com/StefanMaron/BusinessCentral.LinterCop/issues/473
Could you update our LinterCop


[material-ui][Stepper] Convert to support CSS extraction

[X] I have followed (at least) the PR section of the contributing guide.

I'm not able to start the dev server due to this error in the StepLabel component, @siriwatknp do you know what could this mean? I've only changed the ownerState which shouldn't cause much issues.

However if I do this with a normal pnpm run build && pnpm run preview it starts up the page.

I'm aware of this error, it's related to wyw-in-js shaker. I will push a fix soon.


The WinUI 3 Blank App template doesn't create an App.xaml.cs as suggested.

[Enter feedback here]
The text in the Examples section states:
The following code example shows an abridged version (except for the C++/WinRT version, which lists the full function) of the OnLaunched method override generated for the Blank App template in Visual Studio.
However the WinUI 3 Blank App template doesn't create an App.xaml.cs with any reference to frames, just a MainWindow.

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

ID: e5c220e6-124a-09df-1b63-442657a9796b
Version Independent ID: 6849a14f-ed3e-308f-ea41-66cf223f64c4
Content: Page Class (Microsoft.UI.Xaml.Controls) - WinUI
Content Source: winui-api-build/xml/Microsoft.UI.Xaml.Controls/Page.xml
Product: reunion
Technology: winui-reference
GitHub Login: @jwmsft
Microsoft Alias: jimwalk

Thanks, @AlanPBourke, I've updated that Examples section for WinUI 3 (previously it still had the UWP info and code in there). There's also a bit of information about the difference between the WinUI 3 and UWP project templates, with respect to navigation, in Do I need to implement page navigation?.
-Steve


Buttons don't update on line changes

Issue summary
When the lines shift you've got to move mouse off of a segment and back onto it to expose the add/hide/mark as viewed buttons.
Expected behavior
When a line shifts the relevant options should still display instead of having to move on and off to see them.
Actual behavior
Buttons don't appear.
Steps to Reproduce the Problem

Put mouse over "hide" and click
Try to click hide again for the next hit on the list.
Move mouse off of the line and back onto it

Specifications

Mturk Engine version:  1.4.3
Are you using the Lite version? No
Browser: Chrome Version 63.0.3239.132 (Official Build) (64-bit)

This issue should be fixed as of 1.8.0. Feel free to re-open this issue if it persists after updating.


When I use video2dataset to download videos from youtube recently, I got a confirm error.How can I resolve the problem?

ERROR: [youtube] 2FhTjG_94L8: Sign in to confirm you’re not a bot. This helps protect our community. Learn more

https://www.reddit.com/r/LocalLLaMA/comments/1dd8c62/google_is_testing_a_ban_on_watching_videos/#lightbox


Update package.json dependencies

Please makes sure these boxes are checked before submitting your PR, thank you!

[ ] Make sure you follow Element's Contributing Guide.
[ ] Rebase before creating a PR to keep commit history clear.
[ ] Add some descriptions and refer relative issues for you PR.

oopsy...


SEGV in Function write_element

I used clang 6.0 and AddressSanitizer  to build mxml 2.12, this file can cause SEGV in function write_element in mxmldoc.c when executing this command:
./testmxml $crash 1.xml

This is the ASAN information:
==29979==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000038 (pc 0x0000004095a0 bp 0x60800000bf20 sp 0x7ffcc2981e20 T0)
    #0 0x40959f in write_element /home/fouzhe/my_fuzz/mxml/mxmldoc.c:3796
    #1 0x40cf4e in write_html_body /home/fouzhe/my_fuzz/mxml/mxmldoc.c:4790
    #2 0x40e9cb in write_html /home/fouzhe/my_fuzz/mxml/mxmldoc.c:4551
    #3 0x402e35 in main /home/fouzhe/my_fuzz/mxml/mxmldoc.c:602
    #4 0x7f361bffe82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #5 0x402ff8 in _start (/home/fouzhe/my_fuzz/mxml/mxmldoc+0x402ff8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/fouzhe/my_fuzz/mxml/mxmldoc.c:3796 write_element

@fouzhe I'm sorry, but I really don't know what to do with this. The backtrace is for mxmldoc, but the command you've provided is the unit test program. The referenced file is garbage.

Looking at the backtrace, the most I could do here is add a NULL check, but this isn't something that will occur with a valid input file...


How to get suggested profiles for any username?

Before submitting an issue, make sure you have:

[X] Updated to the lastest version v1.6.0
[X] Read the README and docs
[X] Searched the bugtracker for similar issues including closed ones
[X] Reviewed the sample code in tests and examples

Which client are you using?

[X] app (instagram_private_api/)
[ ] web (instagram_web_api/)

Describe your Feature Request:
I want to fetch Related/Similar/Suggested accounts for a particular Instagram username.
I have tried following methods, but it doesn't give the suggested users
from instagram_private_api import Client
api = Client(username, password)

api.user_info(userid)
api.username_info(target_username)
api.username_detail_info(userid)

I have found that with given URL
https://www.instagram.com/{username}/?__a=1

we can get the suggested profiles like this
import requests
user_agent =  'Chrome'
url = 'https://www.instagram.com/{username}/?__a=1'

res = requests.get(url, headers={'user-agent':user_agent})
data = res.json()
data2 = data['graphql']['user']['edge_related_profiles']['edges']

len(data2)
>>>80

Somehow I am not able to use web_api. But I have found that user_info2 uses the same URL to get the info about the username. It always returns JSONDecodeError.  Is there any other method in` private or web api to get suggested profiles?

api.discover_chaining(userid)


Docker support

I added a Dockerfile and related files to enable building the MediaWiki server with AbstractText included. It took about an hour to run on my laptop, so it's not speedy, but once you have it built you can restart a fresh instance in seconds.

note I added an additional change to update npm in the Dockerfile, the version you get from Debian apt-get is old.


No documentation on in-room controls for MTR.

It'd be cool if you documented on how we go about adding or developing in-room controls on a MTR system. We'd like to add features for controlling lighting, HVAC, etc. I really hope that is available and open rather than being locked down to vendor's hardware. Where can I find it if it exists?

Hello @LanaChin can you help us here to understand if there will be such a documentation ?

Hello @LanaChin Lana 👍 can you help us here ? Thanks

Looking into this, thanks.

Hi @jamesbayliss. The extensions are only available through OEMs.  If you'd like this feature, you can submit a feature request on User Voice at https://microsoftteams.uservoice.com/forums/555103-public?category_id=324151.


fix wrong database column type of paymentInstance->createdAt

changed doctrine annotation database column type of created_at to datetime to match the model type.

I'm not sure why the test failed. Looks like it still uses date instead of datetime. Can someone look into this please? :smiley:
     [exec] PHP Fatal error:  Uncaught exception 'Doctrine\DBAL\Types\ConversionException' with message 'Could not convert database value "2016-04-14" to Doctrine Type datetime. Expected format: Y-m-d H:i:s' in /home/travis/build/shopware/shopware/vendor/doctrine/dbal/lib/Doctrine/DBAL/Types/ConversionException.php:63

Hi,
the database tables are not created from the doctrine schema but from an SQL base image + the migrations. For this kind of change you probably need to add a delta, which also changes the field type in the table s_core_payment_instance.

Thanks @larsbo.
We decided to close this PR because the change is incomplete. If this change is still important to you, feel free to create a new pull request or create an issue on https://issues.shopware.com.


Rework metrics examples

I lost track of the fact that I had already submitted the histogram example. So anyway, this updates it a little bit to include custom buckets. I'm not stoked on the cast required in the bucket example, but I think it's all we have right now. Happy to remove it if we think it's premature.
I also changed the other examples to use the autoconfigured SDK so that folks can actually run them in their IDE without getting the noop implementations.

Happy to remove it if we think it's premature.

Could we wait for stabilizing it? There is already an issue in the spec about stabilizing it (https://github.com/open-telemetry/opentelemetry-specification/issues/3391), I think it should be done before the javaagent 2.0 release.

That's cool. Let's just sit on the PR then for a bit and if it gets too stale I'll update or recreate it. 👍🏻

Would it feel ok if the thing just had a big javadoc disclaimer about this feature not being stable yet?

Would it feel ok if the thing just had a big javadoc disclaimer about this feature not being stable yet?

Hmm, I think so? I think I would be okay with that as long as we're very clear that this is an incubating API, and not yet stable.


Med dstu2

Coverage remained the same at 100.0% when pulling 322a1af09a32811849b5b22e1c4be3fe8fd3b011 on medDSTU2 into 84e5ca8b13dd9b09a25e86ba8c65cc11ef4dc98a on master.


Uncomment the sitonly expected output for SiteOnlyVCFs

Small fix needed to this pipeline - this was commented out late into development, as I was considering dropping support for the scatter_count = 1 option.
This output isn't actually created or used except for when scatter_count = 1, which is not recommended. However it needs to be in the expected outputs for the VEP job to work.
See the error mode:
https://batch.hail.populationgenomics.org.au/batches/518674/jobs/1
Test run on this branch with this fix, using scatter_count = 3
https://batch.hail.populationgenomics.org.au/batches/518683/jobs/1

It feels like there's a neater solution here...

Oh yeah I'm familiar with this trash bag. It's nonsense that the VEP module requires so many different inputs... It either takes the separate VCFs, or one VCF, then contains a full code block for splitting into segments. It's just not relevant to running VEP and feels like terrible bloat.
I've tried grooming this out a few times, but it always ends up being a really invasive change


Few changes that i did

I added a vector in the hero.js as image and in the doctor card i added a learn more button !

If you approve kindly accept

Hi @shivah12, it's good that you showed up with some ideas of your, but I'm not satisfied with the changes. Next time, please create an issue on the repo for discussion whether the change is required or not. Don't just come up with a Pull Request randomly.


Make fork_ami prow-compatible so it can be triggered from a PR

It would be nice to /test fork_ami from a PR and have a fork AMI created w/o needing to navigate through Jenkins to start it. Eventually we could make the bot post back a link to the AMI or better yet the oct command to run in order to stand up the newly created AMI (depends on https://github.com/openshift/origin-ci-tool/issues/130)

cc @stevekuznetsov

/close

/reopen

/shrug


(Unofficial) 32-bit build of v2.14 release

There was a request in the UCP discord for a 32-bit build of the UnofficialCrusaderPatch. Using the same source as the release, I built the project targeting x86 so this should work. Did a test install against my steam installation and it appeared to work.
Note: I only recommend trying this if on a x86 platform and the release version doesn't work for you - I haven't fully tested that targeting x86 hasn't broken any UI elements (although I would think that if it builds successfully it shouldn't)
(Unofficial) UnofficialCrusaderPatch_v2.14-32bit.zip

Going forward, maybe we should consider just using VisualStudio's "AnyCPU" configuration, so the same build can be used for both x64 and x86?

It was set already to AnyCpu which apparently seemed to build for x64 (or maybe according to the devs platform?) as the release build did not work for the person who requested it.

Nikhil

On Apr 16, 2020, at 7:55 AM, Heroesflorian<EMAIL_ADDRESS>wrote:
Going forward, maybe we should consider just using VisualStudio's "AnyCPU" configuration, so the same build can be used for both x64 and x86?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


How to perform initial page migrations

Issue Summary
I have a page structure in mind that I want to implement in code without having to click around in the CMS interface. Preferably this is done as a migration right after the initial wagtail migration.
The use case is for developers that set up many similar sites quickly (e.g agencies).
I've tried using the workaround in https://gist.github.com/loicteixeira/9e20d78d91b518bcbee9642874760c20, but it seems to be outdated.

Django migrations are not suitable to write Wagtail data migrations. The models are not fully loaded, therefore threebeard isn't available. You can't programatically add a page. You can't do: parent_page.add_child(instance=some_page). Something that is possible when your application is fully loaded.
Alternatives are:

post migrate signal
management command
fixtures
Wagtail Factories might be useful too.

Wagtail itself creates a homepage and site object during migrations. Here are the paths and levels hardcoded into the migration. This can be done because these are the first entries into a new and empty database. But working like this is impossible you have existing project where you can't rely on the database to be in a certain state (pk increments).
If an initial data migration setting a homepage is required, Wagtails default homepage is in the way. You probably want to delete it. Sometimes I wish that initial data wasn't created at all. It would make setting up own fixture data easier.
This issue tracker purpose is to report bugs, submit feature requests, give suggestions to make Wagtail better. It is not intended for support queries and answers. Because I had the same requirement a couple of times. We might improve on the reproducible initial data story. So i'll leave this issue open for now.
Some questions:

Where in the documentation is initial data or data migrations described?
What can we do to improve the documentation?
What can we do to improve Wagtail? How to make initial data and data migrations easier?

We've been struggling with sort of the same issue the last weeks and I used wagtail factories to create a newly site with homepage and subpages which looks a bit like this:
if not Site.objects.filter(site_name="My customer website"):

    # the homepage will be created in the site factory
    site = factories.SiteFactory(site_name="My customer website", is_default_site=True)

    # "undefault" the wagtail added homepage
    Site.objects.exclude(site_name="My customer website").update(is_default_site=False)

    # create some newspages
    NewsPageFactory.create_batch(
        size=5, parent=site.root_page
    )
    ...

You will not need the factories though to do a similar thing with just the Django ORM, but the factories makes life a lot easier.

Sometimes I wish that initial data wasn't created at all. It would make setting up own fixture data easier.

I totally agree. Make it a separate management command or a manual interaction in the wagtail admin UI would have been much better. Especially with the hard coded id's in the current data migration.

What can we do to improve the documentation?

We should add a section which explains how the tree structure works (path and root nodes), the relationship between a site object and the selected root_page and some examples of scripts or snippets how to programmatically add new sites with pages with initial content.

What can we do to improve Wagtail? How to make initial data and data migrations easier?

I think using native Django migrations is the way to go. That way you ensure the local setup, tests and production all share the same structure. I know this is difficult due to the classes Django injects in migrations, but maybe we can have helper functions that can work with those classes specifically for the migration purposes. I don't think we should deviate from the "Django way" of setting up initial data.

Sometimes I wish that initial data wasn't created at all. It would make setting up own fixture data easier.

I agree, but it might make the initial learning curve for beginners steeper.

We should add a section which explains how the tree structure works (path and root nodes), the relationship between a site object and the selected root_page and some examples of scripts or snippets how to programmatically add new sites with pages with initial content.

:+1: :+1: :+1:


Refactored /templates and /resources into a single /themes folder.

Ok - this is working and resolved the LOCAL_BASE issue that I was having before.  I'm still concerned that issue could rise again in the future, but this solves that problem and is a solution for the other discussion on collapsing the resources / templates.
Rather than using "resources" I went with "themes", seemed appropriate.
So here is the new structure.
/themes/core/js/
/themes/core/css/
/themes/core/less/
/themes/core/templates/

And all the overrides fall neatly into place
/themes/daux-blue/
/themes/daux-green/
/themes/daux-navy/
/themes/daux-red/

The biggest issue I am running into with the codebase is with the Daux application and Config array.  IMHO we need to do some more refactoring so that the APP (Daux) is passed into ever subsequent layer of operation, and can be called upon for config, etc.

Very nice, I like that !
As said in the comment on the Daux.php file, I would not bundle the default templates with the themes, but keep them separated.
Can you please revert the part with the templates and merge the latest changes to the development branch?
Then I will merge your pull request.
After that I will change the default template to introduce the concept of "theme variants" We now have the four "daux-*" themes, but I would prefer to have only one and with a configuration value, it would define which of the version I want to show. So that would de-duplicate the resources. and avoid the _common directory

Did you have any chance to continue on that ?

Just pushed the update.  This is a pretty clean solution that allows for complete theme & template overloading.
Regarding the variant logic, maybe a more useful feature would be some theme class that can provide the theme parsing hooks for loading params or overloading - variant or otherwise.


Unary alternative to TraceSegmentReportService.collect

Why do you submit this issue?

[x] Feature request

Can we have a unary version of https://github.com/apache/skywalking-data-collect-protocol/blob/b2f381e63702bc43216ef5576637195102302c6e/language-agent/Tracing.proto#L31? Reason is to provide a simpler client-side implementation. An additional supporting argument, see https://buf.build/docs/style-guide/#recommendations at the very end of that section.
rpc ReportSegments(ReportSegmentsRequest) returns (ReportSegmentsResponse) {}

message ReportSegmentsRequest {
  repeated SegmentObjects segments = 1;
}

message ReportSegmentResponse {
  Commands commands = 1;
}

cc. @ZackButcher

I could add this implement as an option, you want this in the Envoy side? I guess it is more friendly for the resource releasing?

@dio Default and recommended in streaming, because it could provide a little better performance, especially when you have a lot of segment(in some agent, 1-2k per stream). So, if this is not a concern at Envoy's side, I could help with this.

@dio what's the performance improvement you're looking into for this? You should be able to use current streaming interface as batch (i.e. send gRPC frames in batch), there will be a little of performance penalty to do so.

This is discussed with @ZackButcher this morning. Probably not only Envoy but other clients. While in Envoy's side it will be simpler in terms of code complexity and in line with other existing tracers.
I think it will not hurt to have alternatives.

From the SkyWalking perspective, the side effect is very limited. But envoy should be more sensitive. The bigger the segment collection is, the more memory and network latency will cost. Sending a large set of package is not good, especially in unstable network status.
@lizan @dio I would follow envoy side preference. But the performance issue will be there.

Even with the message having repeated, I'd still suggest have stream in RPC signature, just like Envoy ALS does. Unary is just a specialized (N=1) stream. You should be able to use as it is unary.

Even with the message having repeated, I'd still suggest have stream in RPC signature

Yes. From my understanding, when you use repeated, the server-side has to begin processing after received the whole collection, rather than streaming to process an entity once it has been received.

@dio @ZackButcher Could you confirm whether we still recommend the client side, including envoy, to use the stream mode?

From an implementation perspective, and the lines of codes involved, I'll be grateful if SkyWalking (for trace data collecting) has a unary interface since I think tracing is a best-effort task.

@dio This is very easy on the SkyWalking side.
But like I and Lizan mentioned, it will cost more memory and CPU on the Envoy side. @lizan Please be sure this is acceptable. That is why I keep confirming the recommendation. I just don't want the SkyWalking's envoy tracing having performance issues.

In the 3k op/s envoy, there would be 3k segments, including 6k spans. And in this kind of case, you will have a large list, rather than processing it in a stream mode. This large list will have to waste more memory to cache the data to wait until the whole list sent completed.

Why would I need to buffer that big? I can always send it right away if I want.

I think you will only have one channel and one stub for sending this.
My understanding, this is no real one-way call, as unary, you need to wait for the previous list sent completed.
My experience is for the agent case, streaming could perform better in a large data set. So, depending on the Envoy team.

Seems like there is a slight misunderstanding on this. I can always send a set of traces, periodically and the size of the buffer is controlled client-side (e.g. envoy).
Since this issue is a feature request, I don't expect this to be a blocker or even to be implemented server-side. OTOH, it seems like I can start with https://github.com/apache/skywalking/blob/master/docs/en/protocols/HTTP-API-Protocol.md, sorry that I missed this doc, too lazy to dig. The unary gRPC one will help since it uses HTTP/2.

If you want the unary, I will. You don't need to deal with HTTP, and SkyWalking backend has better performance in gRPC than HTTP/1.
My argument is only related to unary VS stream performance.
@dio I will add this gRPC service in this weekend. I will chase my Tesla tomorrow :)

I think there's a little confusion here:

Primary purpose for this is not performance, but to make the client code easier in Envoy to forward data to skywalking

As I understand it, using a stream greatly complicates the code due to Envoy's threading model; @dio and @lizan know better than I how that works

Like Lizan says, unary is just a special case of stream

unary is a stream that has exactly 1 message sent and received; stream can be n message sent m message received
Because of this, unary can have slightly worse performance than stream in many/most cases

Like Sheng says, there is no one-way (i.e. "fire and forget") calls in gRPC - unary gRPC requires a response (even if the response is empty)

This can affect throughput in some cases, depending on how exactly the client and server are pooling threads that handle gRPC requests
If SW collector can receive unary data, push the request processing to an executor (thread pool), then return a response, you would not see any blocking/queueing on the gRPC stream (though you might see queueing of tasks to be done in your thread pool if agent is outpacing collector). For example, in golang gRPC creates goroutine per unary request to avoid this.
In general, gRPC avoids head of line blocking (@lizan can keep me honest here)

Like Dhi points out in the document he links, SW collector use case is not really one that's intended for streaming gRPC (though in practice it performs better, so it makes sense to use it for most agents).

I think you will only have one channel and one stub for sending this.
My understanding, this is no real one-way call, as unary, you need to wait for the previous list sent completed.
My experience is for the agent case, streaming could perform better in a large data set. So, depending on the Envoy team.

I think this is the key confusion - @dio can correct me - but I believe we'd have a stub per Envoy-worker-process, not just a single stub. This is part of what results in the simplification in code on Envoy side. Further, multiple unary RPCs with the same stub won't block each other. gRPC uses H2 multiplexing here; when it comes to literally writing the bytes to the wire, it uses a round-robin strategy across pending requests so that small requests "flow past" large ones. (Again, @lizan please correct me if I got some of the gRPC internals wrong.)
Overall glad to see y'all are fine to add unary - thanks @wu-sheng!

Unary definitely works for me, no concern at the SkyWalking side.
@dio Have you separated the trace data into 2 spans?

I think there's a little confusion here:

Primary purpose for this is not performance, but to make the client code easier in Envoy to forward data to skywalking

As I understand it, using a stream greatly complicates the code due to Envoy's threading model; @dio and @lizan know better than I how that works

No it doesn't really complicates, that's why I'm saying even if we made that repeated the RPC signature should still be stream, Envoy doesn't use gPRC generated code, and the async client doesn't make specialization for unary. So it is pretty easy to use stream rpc as unary. Just use as it is an unary.

Like Lizan says, unary is just a special case of stream

unary is a stream that has exactly 1 message sent and received; stream can be n messages sent m messages received
Because of this, unary can have slightly worse performance than stream in many/most cases

Like Sheng says, there is no one-way (i.e. "fire and forget") calls in gRPC - unary gRPC requires a response (even if the response is empty)

This can affect throughput in some cases, depending on how exactly the client and server are pooling threads that handle gRPC requests

While gRPC requires a response, it doesn't block the stream, i.e. you don't have to wait any response before sending next batch. The only caveats is H2 flow control, that depends on how server applies that to the stream.
So based on that I don't see a point of adding an unary, it doesn't make performance better or implementation easier.

Envoy doesn't use gPRC generated code, and the async client doesn't make specialization for unary.

@dio Please talk with Lizan. I don't have understood the Envoy codes. :p

OK. Per my statement, it is a feature request. If we only care about Envoy that is fine per Lizan's comment. I'm thinking it will help the community as well since not everyone likes "streaming".


Change Order.CreatedDate to published Date

Currently the order.createdDate is set at the time of creation of order.
However an order really comes into existing when it is published and all time tracking happens from that time. Hence update the logic to set
Order.CreatedDate = published datetime (in EPOCH format)
This is also required to sequence the order's in chronological order for Case Bundle
@Taherabharmal @suresh12 @subhashini-egov FYI and comments, if any.

@atulgupta2024 can we just add another field called published date instead ? I am not sure about losing the audit field just for orders in the system

Hi @Ramu-kandimalla , the change is working fine in DPG -Dev , please find the reference.
https://jam.dev/c/7b856272-7bb1-4162-87ca-abff170b639f
Test Cases:

Created an order with draft stage , verify the Date Added field is displaying as empty
Create an Order with draft stage, verify the crate date field in API is displaying as 0
Create an Order and publish the Order , verify the date is field is displayed with current date
Create an Order with draft stage and publish the order after one day the date field is displayed with current date.

Hi @atulgupta2024 , the change is implemented in UAT environment
https://jam.dev/c/5ab91c10-7a7a-409a-8c09-0364dca62b0f

signed off


chore(gh-integration): Updating Github integration plugin docs

Resolves Jira: CDSH-629
deploy preview: https://deploy-preview-2236--armory-docs.netlify.app/plugins/github-integration/
1 Dec 2023

Refactor "use.md" to folder with included images (moved images out of static directory); images should be in same dir as file for better image compression and loading times
Create "overview" page and move github-integration-plugin/_index.md content to overview; this is the pattern we use in CDaaS docs.
Add new features to overview; add links to features list

do not merge until I'm done with style guide updates

Kyle's comments https://cloud-armory.slack.com/archives/CH4RVCCTS/p1700677176880459
But will also note them here
I would like a separate page for each feature
So 1 for Authorization (AuthZ)
1 for Validate GitHub Access
1 for Configure GitHub Commit Status Echo notifications
The Overview page should be updated to include references to these new features as additional use cases so there is a single list of all the "sub features" of the GitHub Integration Plugin in one place
The three features above need more information added to either the Overview Page or the indvidual configuration pages explaining why the feature is useful and what benefit it will bring (or drawback of leaving it off)

@aimeeu Do you think that this PR is ready to be merged? Or is anything else needed in terms of styling, content etc?

This looks good from my perspective.  Thanks for making all those changes @aimeeu.


CardFilter.Visible -  invalid value for filter

Hello,
looks like CardFilter.Visible is not a valid filter, at least now.
Open and All filters are working fine.
Trello reported an error: 'invalid value for filter'
************** Texte de l'exception **************
System.Net.Http.HttpRequestException: Trello reported an error: 'invalid value for filter'
at Manatee.Trello.Internal.ExceptionHandling.DebugLog.Error(Exception e, Boolean shouldThrow) in C:\Users\gregd\Desktop\Manatee.Trello\Manatee.Trello\Internal\ExceptionHandling\DebugLog.cs:line 26
at Manatee.Trello.Internal.DataAccess.JsonRepository.ValidateResponse(IRestRequest request) in C:\Users\gregd\Desktop\Manatee.Trello\Manatee.Trello\Internal\DataAccess\JsonRepository.cs:line 64
at Manatee.Trello.Internal.DataAccess.JsonRepository.Execute[T](TrelloAuthorization auth, Endpoint endpoint, IDictionary2 parameters) in C:\Users\gregd\Desktop\Manatee.Trello\Manatee.Trello\Internal\DataAccess\JsonRepository.cs:line 29    at Manatee.Trello.ReadOnlyCardCollection.Update() in C:\Users\gregd\Desktop\Manatee.Trello\Manatee.Trello\CardCollection.cs:line 64    at Manatee.Trello.ReadOnlyCollection1.GetEnumerator() in C:\Users\gregd\Desktop\Manatee.Trello\Manatee.Trello\ReadOnlyCollection.cs:line 59
at System.Linq.Enumerable.Count[TSource](IEnumerable1 source, Func2 predicate)

just My fault I guess, need more tests

Cannot work around.
To reproduce : var temp= list.Cards.Filter(CardFilter.Visible).Count();

Thank you for the report. I'll look into this.

The API says it's still supported.  I can't imagine they'd discontinue support without bumping the API version.
https://developers.trello.com/reference#cards-nested-resource (search for "filter")

@mathieuchateau I've been able to replicate the error.  I'm looking into it further.

The docs say that visible is the default.  Is there a reason you're trying to filter explicitly?

@gregsdennis :
wasn't sure if default was visible or open. I am dumping cards in separate works based on this filter, and so in source code is easier to read if explicit.
While it stays default, your code should then just strip it when doing the call ?
Often, when making default value explicit and so not useful, Jetbrains change color, so it's easy to know being explicit is alreay default. There it's not detecting that visible is already default value.

The code doesn't track which parameters are default in the API (except when a selection of properties isn't quite what I want).  I did to keep up with changes if Trello decides to change it.
Regarding default values on enums (which would be picked up by R#), all of the enums have a None value that is the "default" value.  This is a common practice with enums to avoid incorrectly setting a valid value.

From Trello support:

We support the filter filter=visible for cards only when it is a nested resource in specific other resources. For instance, the filter works if you are getting cards as a nested resource from the board object (/1/boards/{boardID}/cards?filter=visible). However, the list object is not one that supports that. I'm going to update our documentation to explicitly outline which objects do support that filter.
I believe that you could use filter=open instead and get the same expected outcome. Let me know if that doesn't do the trick for you!

It seems odd to me that they'd support visible on boards but not lists.  I'll have to update to catch this special case.

When I asked about the inconsistent behavior, they replied:

Unfortunately, I don't have a good answer as to why we've ended up with inconsistent behavior. However, I've added this to our backlog and hopefully we'll get it fixed sometime in the future. Going forward, we'll likely lean into cards=open. Sorry for the confusion!


81 accessibility focus state flow

Issue
Resolves 81
What was done

[x] Meet accessibility standards for the top level of individual space pages

How to test

Tab through a space page and ensure the order is logical
Ensure that a space page can be understood and navigated using the screen reader

Hide icon name for the following:
local_offer (My Tags icon)
assignment_ind (My Roles icon)
Add Add person (Add person button)
Add add product (Add product button)
supervisor_account (Unassigned icon)
inbox (Archived products icon)
how_to_reg (Reassigned icon)
Change name if possible for the following instead of hiding:
Assign a person (Currently it says person underscore add) --> Assign a person button
Ellipsis icon ( more underscore vert) --> Product Menu button
Ellipsis icon ( more underscore vert) --> Person Menu button
At least ‘menu button’ for now

Hide icon name for the following:
local_offer (My Tags icon)
assignment_ind (My Roles icon)
Add Add person (Add person button)
Add add product (Add product button)
supervisor_account (Unassigned icon)
inbox (Archived products icon)
how_to_reg (Reassigned icon)
Change name if possible for the following instead of hiding:
Assign a person (Currently it says person underscore add) --> Assign a person button
Ellipsis icon ( more underscore vert) --> Product Menu button
Ellipsis icon ( more underscore vert) --> Person Menu button
At least ‘menu button’ for now

Hide icon name for the following:

local_offer (My Tags icon)
assignment_ind (My Roles icon)
Add Add person (Add person button)
Add add product (Add product button)
supervisor_account (Unassigned icon)

inbox (Archived products icon)
how_to_reg (Reassigned icon)

Change name if possible for the following instead of hiding:

Assign a person (Currently it says person underscore add) --> Assign a person button
Ellipsis icon ( more underscore vert) --> Product Menu button
Ellipsis icon ( more underscore vert) --> Person Menu button
At least ‘menu button’ for now

Hide icon name for the following:

local_offer (My Tags icon)
assignment_ind (My Roles icon)
Add Add person (Add person button)
Add add product (Add product button)
supervisor_account (Unassigned icon)

inbox (Archived products icon)
how_to_reg (Reassigned icon)

Change name if possible for the following instead of hiding:

Assign a person (Currently it says person underscore add) --> Assign a person button
Ellipsis icon ( more underscore vert) --> Product Menu button
Ellipsis icon ( more underscore vert) --> Person Menu button
At least ‘menu button’ for now


Messages not sending

Messages on the Osmium and the Devy chalice aren’t showing up when sent. Browser is chrome for ipad. Messages were sending just fine last night on chrome for desktop. Maybe issue between running locally and hosting on glitch?

same issue on ipad safari and iphone chrome.

Idiot here. I forgot to reinstall the node modules when I synced the glitch site with this repo. This meant that the server basically couldn’t do anything at all. It should work just fine now.


credits to data

Q: if a researcher uses this beautiful tool, how would he/she give credit to the tool and the data which comes with it? (by Andrea Scharnhorst)

Tool: would http://ceur-ws.org/Vol-2695/paper6.pdf work?
Data: I think it'd be nice if there was some reference that included everyone's contributions including the archives and volunteers, like on https://wiki.openstreetmap.org/wiki/Researcher_Information#Citation_requirements

ps: the data idea will be adopted by HSNDB, which provides the LINKS data.


[PDI-15706] fixed HTTPPOST RequestEntity wrong length

http://jira.pentaho.com/browse/PDI-15706

Hello, This is an automated comment from our build system. Since this pull request originated from a user  not in the Pentaho organization, we will not proceed  with automatic validation of the pull request.  However, rest assured that it will be reviewed manually as soon  as we get the chance. Thanks for your contribution!

Hello, This is an automated comment from our build system. Since this pull request originated from a user  not in the Pentaho organization, we will not proceed  with automatic validation of the pull request.  However, rest assured that it will be reviewed manually as soon  as we get the chance. Thanks for your contribution!

Hello, This is an automated comment from our build system. Since this pull request originated from a user  not in the Pentaho organization, we will not proceed  with automatic validation of the pull request.  However, rest assured that it will be reviewed manually as soon  as we get the chance. Thanks for your contribution!


make popover work for ipads

@alexagr  resolves #534 finally !!
@mariobehling please review

Current coverage is 34.31% (diff: 100%)

Merging #903 into development will not change coverage

@@           development       #903   diff @@
=============================================
  Files                7          7
  Lines              985        985
  Methods            125        125
  Messages             0          0
  Branches           153        153
=============================================
  Hits               338        338
  Misses             647        647
  Partials             0          0

Powered by Codecov. Last update b6d7398...5f20161


Fail requests with incomplete line ends

To be RFC compliant, trafficserver should reject requests that use \n instead of \r\n.  This required updating a number of our test files.

[approve ci]

[approve ci clang-format]

[approve ci clang-format]

Lots of files changed, but only one file is core. One file for unit tests.  And the rest are updates where are autests were relying on newline only line endings.

This may be slightly different from the original issue, but would you add these tests and update the parser while you are at it?
{"GET /index.html HTTP/1.0\r\na\rb\n", PARSE_RESULT_ERROR, 30},
{"GET /index.html HTTP/1.0\r\nUser-Agent: foobar\r \n", PARSE_RESULT_ERROR, 47},

Also, I noticed that the test case below is untestable because it causes a crash, regardless of this change. It's probably because the request string is static. I couldn't reproduce the crash if I send the request over network (to traffic_server by nc command).
{"GET /index.html HTTP/1.0\r\nUser-Agent: foobar\r\n \r\n", PARSE_RESULT_ERROR, 49},

Pushed new commit adding the tests @maskit.  Plus fixing the issues these tests introduced.

[approve ci Clang-Analyzer]
[approve ci autest]

It seems like Autest fails due to file name mismatch. "test-0rtt-s_client.py" probably need to be updated.

[approve ci autest]

I'm going to remove this from 9.1.x project, since we have a better patch soon to replace this.


Tls handshake failed after calling WalletConnect.Connect()

Hello, trying to use moralis unity sdk to perform authentication through metamask. Testing on device and getting this error after calling AuthenticationKit.Connect: "System.Net.WebSockets.WebSocketException (0x80004005): Unable to connect to the remote server ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> Mono.Security.Interface.TlsException: Handshake failed - error code: UNITYTLS_INTERNAL_ERROR, verify result:<PHONE_NUMBER>".
After some deep diving i saw they are using WalletConnect and error happens trying to reach uri "wss://n.bridge.walletconnect.org/" in NativeWebsocketTransport._socketOpen that calls WebSocket.Connect that call s System.Net.WebSockets.ClientWeSocket.ConnectAsync. I tried to set RemoteCertificateValidationCallback on ClientWebSocketOptions and ServerCertificateValidationCallback globally but to no avail - they are not being called and not exposed by api. But even if they were it would be temporary solution.
How can i resolve this?
Is there a way to temporarily disable certificate exception handling?

closed due to v1 depreciation


#5813 move js dir to top, second PR

i am getting a directory "js/js/lab/lib" seems that should just be "js/lab/lib".


Add Test for Health RPC Call in full_client_test.go

Description
Currently, there is no explicit test for the Health RPC call in full_client_test.go. The Health RPC call is crucial for monitoring the status of the node and ensuring its proper functioning.
Expected Behavior
A test should be added to full_client_test.go that calls the Health RPC and asserts that the response is as expected. The test should check for an empty response, which indicates that the node is healthy.
Additional Context
According to the CometBFT RPC documentation, the Health RPC call doesn't have any parameters and returns an empty response if the node is healthy.

@nashqueue i would like to work on this issue

Thank you for your contributions! I think @chandiniv1 already took this one up. So I will assign it to her.


Can i use c++ client to invoke the dubbo service?

We don't have official support for C++ client. Currently, you can export a service with hessian/http protocol on server side, and then invoke this service using C++ client, but you cannot use the Service Discovery and LoadBalance feature provided by Dubbo.

Can i export a service with thrift protocol on server side and then invoke this service using c++ client by Apache Thrift? Or in other words, is dubbo thrift protocal compatible with the Apache Thrift?

It is compatible with Apache Thrift. But i recommend use hessian instead of thrift. First, this part is in urgent need to upgrade; Secondly, this part don't have enough test experiences in production.

#1095


Update Sha2Crypt.java

The old regular expression is incorrect.
If you want to match [a-zA-Z0-9./] and limit the length to 16, I think it should be the following expression： "^\$([56])\$(rounds=(\d+)\$)?([\.\/a-zA-Z0-9]{1,16})$")

@kangxy
There are no tests in this PR.
You'll want a test that fails if there are no changes to the main directory.

The proposed RE does not work because it does not allow for truncating the salt after 16 characters, as per the following test failures:
Sha256CryptTest.testSha256CryptStrings:63 » IllegalArgument Invalid salt value: $5$1234567890123456789 Sha512CryptTest.testSha512CryptStrings:98 » IllegalArgument Invalid salt value: $6$1234567890123456789
There needs to be further work before the RE can be made stricter.

Both of the above salt values are wrong. We need the salt to be 16 bytes or less


Revise static result example

Using aria-describedby on elements like <div> or <p> is not broadly supported in screen readers.
VoiceOver and NVDA do not recognize the connection when a non-form field, button, link or landmark use aria-describeby to point to another element.
JAWS does reveal the connection, but requires a user to press JAWS key + ALT + R to read the descriptive text. (JAWS auto-reads descriptive text when used on one of the mentioned supported elements).
As the example isn’t well supported, and isn’t truly necessary if a  document is setup appropriately, the revised pattern changes the movie name text to be within an <h3>, adds a line of dummy info text, and places the rating to be within a <p>, with additional “Rated:” text to provide context for why someone would be hearing “3 stars”.
Let me know if there's any questions about this PR, or if there's anything else you'd like to see done with the updated example.
Thanks!

Hi @scottaohara, thank you for your help. That update makes perfect sense. Could you just change the id to „starability-result1”? I don’t want someone to have a name conflict by accident.
My only concern about this update is that someone might add several examples with the same id on one page. I will probably write a line about in in README.

Hi @szynszyliszys,
I'm not sure I follow.  There is no id in the updated example, my updates removed the need for one.  I did retain the starability-result class though.

Oh sorry @scottaohara, I checked that on mobile while on move and must have misread something. I can merge it, but I don't feel that adding the dummy text  element is necessary. When removed, I can merge the pull request.

Np, @szynszyliszys.
Removed the extra text, and also updated the readme file to update the reference there as well.

In README there is a  element while in the index file we have . Also I pushed the changes for the accessibility outline, so it would be best if you merged current master branch into yours before PR. If that's too much work I can fix these.

@szynszyliszys I didn't originally change the p to an h3 as the h3 made sense in the document structure of the index.html file, but may not always make sense as a global example.
Per your request, I updated it in the readme, but I'd likely recommend adding a comment like:
<!-- make sure to use an appropriate tag for your document -->

or whatever language you deem fit.
I attempted to pull down the changes you had made as well, but it resulted in a bunch of strange merge conflicts (definitely an error on my part).  According to GitHub, there shouldn't be any conflicts on your end if you merge my changes from this branch, so I'd appreciate it if you wouldn't mind handling the rest of the merge.
Thanks


Revamp input handling

As shown in https://github.com/veeenu/hudhook/issues/36#issuecomment-1519061031, I have found a way to block all input in most games by studying OSS Reshade and a bunch of forums.
Current issues;

When should_block_messages  is set to true for longer periods of time (?), game input stops being received altogether in some games. Seems to be of a greater issue in games that use Raw input. ALT + TAB may fix it.
Some games still catch mouse hover actions - no clue why as of right now.
The in-game cursor will still follow the IMGUI cursor in a lot of newer games. I'm not confident that this is something we can solve.
We are currently not blocking games that use DirectInput, but this should be easily solved by hooking into it.
All hooks, especially all new hooks that aren't SetWindowsHookEx need to be heavily tested & some may be completely unnecessary (most likely Post/Get/Peek-Message).
Make my code idiomatic! 🥇

Any questions, help or thoughts on this is very much appreciated. I'm just a noob brute-forcing my way to success.

When should_block_messages  is set to true for longer periods of time (?), game input stops being received altogether in some games. Seems to be of a greater issue in games that use Raw input. ALT + TAB may fix it.

I have with great confidence tracked this down to being relevant only to games that use Raw input now. Should be able to fix this soon.

Thank you for doing this work! I feel like this is going in the right direction, though I would address a few architectural shortcomings:

having many instances of OnceCell and std::mem::transmute -- there are probably better patterns to achieve the same results, like putting everything into a single struct and working better with types; transmute should in general be the absolute last resort and heavily scrutinized and contained when used.
passing pointers into functions: I'd rather have one single spot for each pointer where it gets validated and turned into a reference with .as_ref(), this improves dramatically code readability, does not require unsafe for functions, naturally guides you into better structuring and subdividing your code.
I'd also like to reduce hooking to the absolute minimum -- we should investigate whether we can just find other HWNDs of the game and set our wnd proc there instead of the current solution of hooking into the existing wnd proc. Hooking into an existing function works, of course, but it's more undefined behavior we have to support that I'd avoid like the plague unless we're absolutely, positively, 100% sure there is no better way possible at all. The maintenance burden with the current hooks, which are absolutely necessary for the library to function, is already pretty bad due to voluntarily stepping into undefined behavior; and it is bound to grow exponentially with every single hook added. So I'd like to do the absolute best possible to avoid ever adding a new hook again. Honestly, I'd happily choose to go with fewer features over adding more hooks.

Overall, the input handling code looks good and way more nuanced than what we have currently, so I'd gladly integrate this once it gets in a good state.
Thank you again!

having many instances of OnceCell and std::mem::transmute -- there are probably better patterns to achieve the same results, like putting everything into a single struct and working better with types; transmute should in general be the absolute last resort and heavily scrutinized and contained when used.

I agree fully and will sort this out shortly.

passing pointers into functions: I'd rather have one single spot for each pointer where it gets validated and turned into a reference with .as_ref(), this improves dramatically code readability, does not require unsafe for functions, naturally guides you into better structuring and subdividing your code.

Sure thing, I'll study some of the hudhook code already in place and adjust.

I'd also like to reduce hooking to the absolute minimum -- we should investigate whether we can just find other HWNDs of the game and set our wnd proc there instead of the current solution of hooking into the existing wnd proc.

Hmm. I'm not sure what you mean here. I believe that the only way to successfully block all game input is to hook into the message handlers being used one way or another.

The maintenance burden with the current hooks, which are absolutely necessary for the library to function, is already pretty bad due to voluntarily stepping into undefined behavior; and it is bound to grow exponentially with every single hook added. So I'd like to do the absolute best possible to avoid ever adding a new hook again. Honestly, I'd happily choose to go with fewer features rather than adding more hooks if those were the only two options possible.

Oof.
Unfortunately, there seems to be a huge issue with mouse raw input suddenly dying after continuously blocking. I'm not 100% sure that it is because we're using SetWindowsHookEx yet. However, I think I have figured out how Reshade manages to hook into all the functions needed to successfully block. We could go down that approach, but it would require us to use all the hooks in this PR (the hooks aren't complete, nor are most of them even used currently) and then some.
I understand that you want to be cautious with this but I'm starting to doubt that this mouse raw input issue is going to be fixed without hooking into the specific functions. I've been at it for two days now without any progress. At some point the game just decides to stop receiving any mouse input.
I wouldn't have any issue if you don't want to take that direction, besides, games that don't use raw input for the mouse would work just fine with just this one hook and currently Hudhook doesn't even have raw input handling.
I'll make another post soon about what I've tried and where I believe it crashes (?).

Overall, the input handling code looks good and way more nuanced than what we have currently, so I'd gladly integrate this once it gets in a good state.
Thank you again!

Thank you!

So.
The input freeze seems to be a fairly documented issue, granted that it is the same one that we are suffering currently.
Some threads about the problem(s);
WH_MOUSE_LL
WH_KEYBOARD_LL
WH_MOUSE
WH_MOUSE_LL
The ones with _LL at the end are desktop global hooks, however, they seem to be suffering from the same issues nonetheless.

Solutions seem to have ranged from extending the timeout on a registry key called LowLevelHooksTimeout;

MSDN

Create a new thread, hook from there and then create a message loop to keep pumping out messages and keep thread alive;

{
    MSG msg;

    _hMouseLLHook = SetWindowsHookEx( WH_MOUSE_LL, .....);

    while(GetMessage(&msg, NULL, 0, 0) != FALSE)
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return 0;
}

More on that from MSDN (only specifies _LL here) and StackOverflow

Rehooking every so often to not get timed out;

StackOverflow

Seems irrelevant to Rust but here's someone talking about garbage collection;

StackOverflow

I tried all solutions above and there's likely more that I have forgotten, but it seems that using SetWindowsHookEx is less than ideal in some cases..
I also tried;

Only hooking into the thread that uses raw input
Use CallNextHookEx in various ways
Hooking from DLL_PROCESS_ATTACH with and without a new thread

The issue has so far only popped up for me if we change raw mouse movement input to WM_NULL and then proceed to block it for 7-10 seconds while moving the cursor fast continuously (moving slow seems fine...)
As far as I know, WH_GETMESSAGE, WH_MOUSE etc get called before the message is sent to GetMessage and PeekMessage. Hence I believe that when we modify the raw mouse movement to WM_NULL we are somehow overloading or "destroying" the game's message loop. However, that theory falls flat since hooking into GetMessage/PeekMessage essentially would be no different, apart from the issues listed above.
I'm getting really tired of troubleshooting this. If no one knows something that could help, I suggest that we drop raw mouse input blocking until a solution is found - OR I delve into hooking the functions specifically and hope that the problem lies with the SetWindowsHookEx hooks.

having many instances of OnceCell -- there are probably better patterns to achieve the same results, like putting everything into a single struct

Fixed this to the best of my ability.
I assume Atomics inside of the Input struct isn't necessary at all, but I just stuck with them because the syntax is so nice. Not sure if it has any performance impact?

I tried hooking into Peek/Get/Post-Message properly without SetWindowsHookEx & WH_GETMESSAGE and there have so far been zero issues. Blocking input seems to work flawlessly and there is no longer any game input freezing happening.
SetWindowsHookEx just doesn't seem to quite cut it. It's 100% plausible that I've done something wrong when using it, but until we figure out what it is.. either we ignore raw input for hudhook or we go down the route of hooking to these functions individually. Either is fine by me, it won't add much work, if even any. If we go with the first option I'll just have a different local fork for the latter since it is absolutely essential for my app to work the way I want it to.

Man, that's a treasure trove of information 😄
Okay so I read a bit more about SetWindowsHookEx and it seems it's doing global hooking? Plus it also looks like the timeout behavior is deliberate, and designed to protect from hooks running too long, which makes sense. I'm not liking SetWindowsHookEx much either, having considered this.
Btw, I've gone back and checked the code a bit. I'm still very worried about the hooks -- mostly because they run on very fundamental bits of the windows event loop which are going to run a bazillion times per second... Ngl, the thought of adding overhead to every single one of those calls (even if it's just a call + ret) makes me uncomfortable. The render loop has a cozy 16.6ms to play with at every turn, whereas those might be fired super fast and delay in there is most likely going to mess with the games in unexpected manners -- see the above reason wrt SetWindowsHookEx.
Due to its usage in the practice tools, one of the core needs that I had while designing hudhook was to mess with the game as little as possible in order to not influence the underlying execution in any manner that could be unpredictable. This is already super hard to juggle as is. Integrating this PR in its current state would mean forgoing that design principle altogether.
Don't get me wrong, I think this is super useful and I'd be glad to integrate it in some capacity, but I think it would be worth it to change its design so that it is opt-in -- i.e. an extra set of hooks that you can add at the beginning if you so wish, and that leaves everything else the same.
It would be even better if we found a totally different way that didn't require hooking, or that drastically limited hooking; but I can work with the opt-in thing until we understand the problem space better and find something better.
This might tie in with the idea to expose some internals of the library in order to build external plugins. I want to allocate some cycles to designing that, but lately it's been quite hard for me to do any progress at all due to real life commitments (and the need to unwind a bit).
(as always, thank you so much for all this work!)

I assume Atomics inside of the Input struct isn't necessary at all, but I just stuck with them because the syntax is so nice. Not sure if it has any performance impact?

IIRC loads and stores should compile down to a single operation anyway on x86/x64, and their only usage is instruction reordering. Should be completely fine 😅

I tried hooking into Peek/Get/Post-Message properly without SetWindowsHookEx & WH_GETMESSAGE and there have so far been zero issues. Blocking input seems to work flawlessly and there is no longer any game input freezing happening.

Is there a chance that hooking only those could be enough to block the input?

Went and checked Reshade out of curiosity... Found this: https://github.com/crosire/reshade/blob/5ad47a818e919e25db08af94f31abe3744f0bbcc/res/exports.def#L452
So what I did overlook about Reshade is that it's actually a proxy DLL: hooking in that case might be a bit different because it happens at startup time. The address that the host application sees in the first place is the hooked function, so there's no altering of the control flow instructions iiuc. Just find the original function and call it. That's a bit different than what we (are forced to) have. I would still be a bit scared of going that way, honestly, but I can see how that might do the trick (then again maybe the design goals of Reshade are different).

having many instances of OnceCell and std::mem::transmute -- there are probably better patterns to achieve the same results, like putting everything into a single struct and working better with types; transmute should in general be the absolute last resort and heavily scrutinized and contained when used.

I tried alleviating this in the latest commit. However, I don't know if there is any safe way to do the same as transmute for function pointers at the moment?

I tried alleviating this in the latest commit. However, I don't know if there is any safe way to do the same as transmute for function pointers at the moment?

This looks already significantly better, thank you!
There are things from this PR that I'd like to integrate in isolation, because I think they can stand on their own. In particular, the handle_window_message function.
What I'd like to do is start a fresh branch with only that, make a few changes to it (e.g. pass a &mut Io to it, retain the wnd proc mechanism via SetWindowLong, have the window procs lock the renderers and invoke handle_window_message over the Io stored in the imgui context) and merge that in once we're satisfied.
Then, we can rebase this PR on main, which will reduce the size of the diff significantly and could pave the way to new ideas and approaches.
Let me know what you think! Would you like me to help with that, or would you prefer taking a crack at it yourself?

What I'd like to do is start a fresh branch with only that, make a few changes to it (e.g. pass a &mut Io to it, retain the wnd proc mechanism via SetWindowLong, have the window procs lock the renderers and invoke handle_window_message over the Io stored in the imgui context) and merge that in once we're satisfied.

Hmm, but wouldn't this approach make it really clunky to integrate the other hooks? Or do you mean that we would make two different functions like I suggested above, but only integrate the wnd_proc one to begin with?

Let me know what you think! Would you like me to help with that, or would you prefer taking a crack at it yourself?

I can do it when I understand 😆

Hmm, but wouldn't this approach make it really clunky to integrate the other hooks? Or do you mean that we would make two different functions like I suggested above, but only integrate the wnd_proc one to begin with?

I mean to integrate things gradually and have as much decoupling as possible so that both approaches can eventually coexist. I wouldn't want to use the multiple hooks approach myself, but I also think the work you have done on them is really valuable; figuring out a way of having them both would furthermore have the advantage of forcing us to rethink a cleaner and more modular API that plays well into the long term plan of extensibility.
This is not trivial, but I think it's the best course of action.

Understandable, however, I do not see the need to couple the current handle_window_message with wnd_proc. I believe it would be a lot easier and better for modularity to keep it separate and only pass umsg to it. Unless I'm missing something?

Oh, I didn't mean to do that. It's a good idea that the function stands on its own, I'm just going to keep using the current window proc approach (subclassing via SetWindowLong) with the new implementation. That function will be wrapped in a wnd proc so we can avoid straying too far from the current implementation all in one go, and test the new input functionality in isolation to make sure it doesn't break clients. Once we're confident of that, we can move on to figure out a solution for the multihooks thing, and simply invoke handle_window_message from the hook instead of from the wnd proc wrapper.

I finally had the time to test this branch against Dark Souls III and Elden Ring. I used the branch as-is. Unfortunately, the inputs that I receive are duplicated in both games for some reason, and two cursor are actually shown. The underlying input is indeed blocked, though, which is a great result.
I wish there was a way of doing this that didn't involve all these hooks -- I have a poor understanding of them and I'm afraid rerouting core Windows events functionality might result in unintended side effects like these.
I just want to thank you again and reiterate that the research and effort you put into this is amazing. Unfortunately we can't merge it currently, but I feel like if we push more and seek to understand the situation better, the day when we will crack will come sooner rather than later!
out.webm

I finally had the time to test this branch against Dark Souls III and Elden Ring. I used the branch as-is. Unfortunately, the inputs that I receive are duplicated in both games for some reason, and two cursor are actually shown. The underlying input is indeed blocked, though, which is a great result.

Interesting. The duplicated input is something I never experienced myself, but neither would I probably notice because it wouldn't make any difference on my app.. 😄
There are plenty of mentions of it and there are fixes for it in the Reshade codebase, but I never implemented any of it due to not noticing the issues and the fact that it seems fairly complicated.
As for the cursor, you have to put SetCursor(HCURSOR(0)) here and possibly also hook the SetCursor function, it depends on the game.
If any game you try likes to lock the cursor somewhere you can also put ClipCursor(std::ptr::null()) in there.

I just want to thank you again and reiterate that the research and effort you put into this is amazing. Unfortunately we can't merge it currently, but I feel like if we push more and seek to understand the situation better, the day when we will crack will come sooner rather than later!

Thank you very much! Don't worry about it, all the work I put in is also massively benefitting me in many ways. No shame in saying no, quite the opposite - I'm glad to be able to discuss this and get viewpoints from someone with far more experience. You've been very patient with me so far and I appreciate that tremendously.

Oh, and by the way - I found a way to fix this.
It works in all games but one that I have tried so far. It is Star Wars: Empire at War and I currently don't have the faintest idea how the game is registering where the mouse is hovering. It could be DirectInput, an internal input manager or something else. Don't know.


🎉 release: v4.1.0

:tada: This PR is included in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Adding konflux test tasks to pipeline

Description

Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Related Issue #
Closes #

Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] PR has passed all pre-merge test jobs.
[ ] If it is a core feature, I have added thorough tests.

Testing

Please provide detailed steps to perform tests related to this code change.
How were the fix/results from this change verified? Please provide relevant screenshots or results.

/retest

/lgtm

/lgtm

/lgtm
/approve


Notifications about cancelling projects shouldnt be public

This notification looks really bad. This is a project that was cancelled because it was fraudulent.
This notification makes it seem like peopledao violated t&c when it was someone who was impersonating them.

Maybe these notifications should not be public knowledge?

@mohammadranjbarz
Maybe we can delete this notification for now until we can remove this type of notification in the future?

@laurenluz can you suggest a new copy or we stop sending them?
As an owner, I want to know my project is cancelled and what it mean for me. If its not violating, we can simply say cancelled by admin and you cant see it or manage it.

I think I agree with you MoeNick... as a project owner, I would also want to know.
I personally emailed this project owner letting them know that their project was flagged for fraud and that they had a week to submit evidence that proved otherwise. There were mutliple members of PeopleDAO who said they knew nothing of this project or the wallet address attached to the project.
They never responded to the email so it was cancelled.
After it was cancelled, the project owner also received this email in autopilot informing them that their projects was cancelled.

It just really looks bad on the actual PeopleDAO project when they had nothing to do with the fraudulent project.

[ ] For starters, we should remove the notifications being sent to project supporters if a projec they supported was cancelled.

[ ] I think we still should show a notification to the project owner, because this would only be seen by the owner of the wallet address. I'm not sure of the current copy on it, but it could be simplified to something like:
"Your project [project name] has been cancelled by an admin. More information can be found in our [terms of service]."

[ ] We should change the copy in the email to include a case like when someone impersonates a real project, adds their email but uses a personal wallet address (which is what seems like happened here...). @WhyldWanderer - can you make an issue in comms there? I can suggest a rewrite if you tag me, and you can edit in autopilot.

https://github.com/Giveth/giveth-planning/issues/1314

[ ]   For starters, we should remove the notifications being sent to project supporters if a projec they supported was cancelled.
[ ]   I think we still should show a notification to the project owner, because this would only be seen by the owner of the wallet address. I'm not sure of the current copy on it, but it could be simplified to something like:
"Your project [project name] has been cancelled by an admin. More information can be found in our [terms of service]."
[ ]   We should change the copy in the email to include a case like when someone impersonates a real project, adds their email but uses a personal wallet address (which is what seems like happened here...). @WhyldWanderer - can you make an issue in comms there? I can suggest a rewrite if you tag me, and you can edit in autopilot.

@mohammadranjbarz can you take this one?

Cancelled for supporters: make it false and un-editable
Cancelled for project owners:
"Your project [project name] has been cancelled by an admin. More information can be found in our [terms of service]."
@WhyldWanderer are you happy with the copy here?

Yeah I can take it, but if we want to disable it, I think we should either separate it from other status or add new item for that in notification setting, WDYT?
I'm talking about this:

Sorry @laurenluz to avoid complexity on the dev side, let's make it simple with a copy change for web notif. In the case of canceling for BOTH supporters and owners:
Supporters: "[project name] which you supported, has been canceled by an admin."
Owner: "Your project [project name] has been canceled by an admin. More information can be found in our [terms of service]."

Sorry @laurenluz to avoid complexity on the dev side, let's make it simple with a copy change for web notif. In the case of canceling for BOTH supporters and owners:
Supporters: "[project name] which you supported, has been canceled by an admin." Owner: "Your project [project name] has been canceled by an admin. More information can be found in our [terms of service]."

@maryjaf  It's on staging, you can test it now

Thanks @mohammadranjbarz I checked and it passed
Supporter :testcelo0001 which you supported, has been canceled by an admin.
project owner: Your project testcelo0001 has been canceled by an admin. More information can be found in our terms of service .

I think that is sufficient enough... thanks for making the adjustment


Normalize API versions fields across the project.

They should be uint16_t and it's not necessary enforce a sub_api field.
This patch also add some API checks in some places.
Signed-off-by: Guilherme Iscaro<EMAIL_ADDRESS>

The sempahore is failing during the check style. However, it fails in parts that I did not touch.
I'm not generating a commit for those, since it's just a style issue.

LGTM

It must be fixed, sorry:

compile all files that you changed, I guess at least MAVLink wasn't
compile with and without C API version
do not mess memmap version with C API version
callbacks with data structures provided by us shouldn't be changed/checked. If we want the app/user to validate soletta version, then we can do it in another way that is much simpler (at opening time)
check with clang and strict compiler flags, I recall from @thiagomacieira comments before that uint16_t formatted as %u would cause warnings. This would happen as well since we call our defines simply the number, without a cast to type or size modifier. It works with GCC since all integers smaller than int are enlarged when used in varargs/va_list

@barbieri I'm really sorry for this I will fix the pointed problems.

@barbieri This is very strange, I compiled using static and shared and also the mqtt/mavlink files.
I don't know why it did not break the build.

On the %u/%hu warning: that's just clang being extra pedantic. The C standard requires all integers of rank lower than int to be converted to int or, failing that, to unsigned int, before any arithmethic operation. It's only really relevant when passing pointers (scanf, not printf).

@thiagomacieira I created a commit (which I'm about to open a PR) that changes all the places that prints api_versions to use PRIu16. Should we drop that then?

check #1421

@cabelitos the patch is required to silence Clang. Note that you should use PRIu16 if you used uint16_t; but you should use %hu if you used unsigned short. Don't mix the two.

@thiagomacieira Ok, it's safe to use PRIu16 since I changed all the api_Versions to be uint16_t :)