Support Vue Mastery

Checklist

[x] I'm reporting a new site support request
[x] I've verified that I'm running youtube-dl version 2020.03.08
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that none of provided URLs violate any copyrights
[x] I've searched the bugtracker for similar site support requests including closed ones

Example URLs

Single video: https://www.vuemastery.com/courses/intro-to-vue-js/vue-instance
Single video: https://www.vuemastery.com/courses/advanced-components/the-introduction
Single video: https://www.vuemastery.com/courses/advanced-components/evan-you-on-mounting-process

Description

They're using Vimeo as their video provider

https://www.vuemastery.com/courses/intro-to-vue-js/vue-instance => https://player.vimeo.com/video/258707456
https://www.vuemastery.com/courses/advanced-components/the-introduction => https://player.vimeo.com/video/263589430
https://www.vuemastery.com/courses/advanced-components/evan-you-on-mounting-process => https://player.vimeo.com/video/263589430

You can see the whole playlist next to each video, but there's no page with only a listing of all course videos

I am looking to download the videos from VueMastery. Any update?

@bythckr it's no great solution, but you can look at the Network tab in your Developer Tools. Filter by XHR and you'll see an iFrame in the (only) response that you can extract the Vimeo link out of. It's a pain, but it half-works. I've found it difficult to do quickly but over a period of time has been okay.

@vSanjo Actually the main page's source code seems to directly have the vimeo URL if in authorised state. I found it in the following selector path (there were 2 other entries as well but I think it's enough to extract the URL from this one), and pass it to the vimeo download method of youtube-dl to download it:
#vimeo-player-1 > iframe
So one could purchase a premium plan for a month, extract all the vimeo URLs and then publish their videos if one is so inclined.


NVM (node module) not honoring default node version

Description
Since https://github.com/sorin-ionescu/prezto/commit/af46875c5e2c7088b25d7d16e50b6955926b44a4, node module no longer honor nvm default NodeJS version.
Expected behavior
node module should honor nvm default version when opening a new terminal / session.
Actual behavior
NodeJS version in new opened terminal sessions is always system.
Steps to Reproduce

Install nvm (curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash).
Install a couple different versions of Node (nvm install 12, nvm install 14)
Install NodeJS using package manager (ie: apt install nodejs)
Enable node zprezto module in .zpreztorc
Set one of the nvm NodeJS versions as default nvm alias default 12
Open a new session and check the currently selected Node version nvm ls, it will be system instead of the previously setup default version.

Already tested nvm in isolation outside of zprezto and works as expected.
Versions

Prezto commit: 166cbe2fca25319db2551f0cc74a86c93259017d
ZSH version: 5.8
OS information: Ubuntu 20.04, MacOS Big Sur

So find that the module is calling nvm with --no-use option (https://github.com/sorin-ionescu/prezto/blob/master/modules/node/init.zsh#L26), which basically forces you to always have to call nvm use node when you open a new session.
Is there is any reason behind this behaviour? or was an intended change?

I think the goal was to make nvm loading lazy - it's pretty slow to start up without --no-use. @indrajitr could you weigh in?

Bump - this is still an issue for me.

This bit me on a new install and took awhile to figure out where the issue was.
I think it's worth exploring how to make nvm/node load faster but I'd revert the --no-use in the meantime.

Orthogonally, I would suggest using fnm as it lightyears ahead of nvm in loading times and is API compatible

I put this at the end of .zshrc:
autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"

  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi
  elif [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

I think the goal was to make nvm loading lazy - it's pretty slow to start up without --no-use. @indrajitr could you weigh in?

This pretty much sums up the reason behind the change. This was part of a series of changes back then to optimize startup time as much as possible. While I don't have the benchmark data available at this moment, for this specific change in isolation the overall reduction in startup time was significant.
I agree the change is an irritant and did consider adding an inline warning to alert users. But I couldn't figure out a way to do it in a way without nagging users every time a new shell is opened.
Suggestions, or even better, a PR is very welcome.

I put this at the end of .zshrc:
autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"

  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi
  elif [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

⚠ For folks arriving at this solution via search: while this will probably work, this implementation is adding in a chpwd hook that introduces a non-trivial load-nvmrc() which will be invoked every single time you are changing directory.
See docs for more and please exercise caution before throwing this into .zshrc.


Add missing .min-h-100-m (fixed typo)

Fixes a typo on one of the heights helpers. 😛
This effectively "adds" .min-h-100-m to Tachyons (building on top of work done in d98f06f6d608dc27cfe8811aae9299bdd0e65fef). AFAIK usage of  .min-h-100-ns will not be affected, since it's still defined in the @media (--breakpoint-not-small) section.
Love Tachyons btw. I'm using it in a new app at Drift and it's been a great experience! 👍

@mrmrs let me know if I can do anything else to help here. I wasn't sure if I needed to run the build process or not, so I did that in a separate commit 3854ab6. :)

Thanks!


New devops url structure

Since azure devops introduced the new url scheme, is it possible to adjust this app to use the new devops uri's ?
so not "organisation".visualstudio.com/defaultcollection
but dev.azure.com/"organisation"/
Thx !

Any news about this issue?


_is not defined

I ran with the error : _is not defined, when i used defineManyPermissions...
PermissionStore.defineManyPermissions(permissions, function (permissionName) {
	  return _.contains(permissions, permissionName);
	});

so i discovered that i needed to put underscore dependency in my project scripts. https://cdnjs.com/libraries/underscore.js/
If angular-permission need it, would be nice put this on documentation.

I got it, thanks.


server/api: remove unused static route

Good catch! LGTM.

LGTM

Do we need to remove event.go now?

	router.Handle("/api/v1/events", newEventsHandler(svr, rd)).Methods("GET")
	router.Handle("/api/v1/feed", newFeedHandler(svr, rd)).Methods("GET")

The event was used for the web shows, but seem useless now.
/cc @disksing

We don't need web interface now?

Maybe yes, we may supply another web interface, but not only in PD.  /cc @iamxy

We will separate frontend resource from this repo.
LGTM


Mention zstd-jni dependency

It wasn't obvious to me what was causing this failure at first,
java.lang.NoClassDefFoundError: com/github/luben/zstd/ZstdInputStream
    at net.iakovlev.timeshape.TimeZoneEngine.initialize(TimeZoneEngine.java:129)
    at net.iakovlev.timeshape.TimeZoneEngine.initialize(TimeZoneEngine.java:116)

I eventually realized it was due to zstd-jni not resolving to a platform-specific dependency. Gradle will not resolve this classifier for you, so I added the following to my build to fix the issue:
"com.github.luben:zstd-jni:${versions.zstd}-3:${env.os.equals('macosx') ? 'darwin_x86_64' : (env.os + '_amd64')}",

where env.os was already defined as
env = [
  os: System.getProperty('os.name').replaceAll(' ', '').toLowerCase(),
]

Hi, thanks for reporting this! I'm not sure why Gradle behaves in such a way, but I'll try to reproduce it with build system other than sbt and see if it works.

I've finally come around to check what's going on with this issue, and it seems I cannot reproduce it. I've created a new Gradle project (using Gradle 5.2.1), so that my build.gradle.kts file looks like this:
plugins {
    java
}

group = "net.iakovlev"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

dependencies {
    testCompile("junit", "junit", "4.12")
    compile("net.iakovlev", "timeshape", "2019b.7")
}

configure<JavaPluginConvention> {
    sourceCompatibility = JavaVersion.VERSION_1_8
}

And then in the main method I initialize Timeshape and make a call to it:
import net.iakovlev.timeshape.TimeZoneEngine;

import java.time.ZoneId;
import java.util.Optional;

public class Main {
    public static void main(String[] args) {
        TimeZoneEngine engine = TimeZoneEngine.initialize();
        final Optional<ZoneId> query = engine.query(51.12, 13.41);
        System.out.println(query);
    }
}

I ran it on Windows and Linux (WSL, Ubuntu Xenial), and it works in both cases. I see you have done it on Mac, so maybe there's something going on there, but I can't test on Mac easily.
I'd appreciate if you'd be able to have another look at the issue. Maybe it's caused by something else, not Timeshape configuration? It you still encounter this problem with Timeshape 2019b.7, it would be great to have a minimal reproducible build.

Sorry, but I haven't thought much about this in almost a year. Going back to that commit, it seems that I was on Gradle 5.0. Can you check against that version to see if maybe Gradle added support as it seemed to be their issue?
When I run ./gradlew dependencies with and without my added dependency, the output looks identical.
Removing the addition and running the server, it seems to work nicely.
INFO  [2019-10-27 18:31:12,967] [net.iakovlev.timeshape.Index] Initialized index with 439 time zones

So I think this can be closed as won't fix as Gradle must have added support?

Thanks a lot for your quick reply! I've tested on Gradle 5.0 as well, and it also worked with my simple example. Maybe some Heisenbug? Anyway, closing this issue now, and, if this happens again, please feel free to open another one.


Packagecloud apt key rotation not applied

The packagecloud_repo repo only pulls the GPG key during deployment; and does not detect in any way that the key might have been rotated.
To properly solve this, the resource needs to keep the downloaded key, and be able to compare it back against the server copy for updates.

Wow, dead ticket resurrect here.
Do you consider remote_file resource properties use_conditional_get / use_etag / use_last_modified to be sufficiently idempotent?
To use it, you'd have to wire up gpg_url to produce a file that stays on disk after it's imported into the keyring.

hah yeah, wading through lost repositories now we've adopted them!
I haven't considered that yet. Are you still using the cookbook? If so, do you fancy giving that a go?


Avoid linking

Create first npm package

Any reason we need the prepublish.sh instead of just listing that babel command directly in package.json?

No reason, it's just in case we end up having to run more stuff.
On Tue, Apr 5, 2016 at 4:46 PM, Sashko Stubailo<EMAIL_ADDRESS>wrote:

Any reason we need the prepublish.sh instead of just listing that babel
command directly in package.json?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/apollostack/apollo-server/pull/11#issuecomment-206038384

Not sure if Windows compatibility is a goal, but relying on Bash scripts may make this harder (at least until the Windows 10 Bash integration ships, but even then we may still want to support earlier versions).

Would removing the one bash script and putting it in the package.json fix
the problem? If so, I think we should do it until we have a real need for a
prepublish script.
On Wed, Apr 6, 2016 at 2:08 AM, Martijn Walraven<EMAIL_ADDRESS>wrote:

Not sure if Windows compatibility is a goal, but relying on Bash scripts
may make this harder (at least until the Windows 10 Bash integration ships,
but even then we may still want to support earlier versions).
—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/apollostack/apollo-server/pull/11#issuecomment-206241876

Yes it would!

Fixed as part of PR https://github.com/apollostack/apollo-server/pull/12


Fix shield sample build issue for x_nucleo_iks01a2

samples/shields/x_nucleo_iks01a2/sample.shields.x_nucleo_iks01a2 fails to build on a number of boards because they lack arduino_header in their dts.  Make the sample depend on arduino_header and update various boards to say they support this.

what about arm/stm32mp157c_dk2?
It includes arduino_r3_connector.dtsi where arduino_header is defined, but it does not
specify it as supported in the yaml file. Isn't it?

Missed it, now fixed.

@erwango Going to merge this and handle fixing up stm32mp157c_dk2 as a post PR.


Scenario documentation api

this PR adds:

/scenarios/{id}/info REST API
default/execution scenario settings parameter for /scenarios/{id} REST API

When it comes to point number 3, I don't see how this is modelled in the proposed API spec.

it can be done using the get method /scenarios/{id}:

when amoc is in idle state (no scenario is running yet and scenario is loaded) settings field contains default values
when amoc is running the scenario, settings field contains current (execution) values

Right, thanks for the clarification. I somehow missed the change ScenarioInfo. Would it be possible for you to provide some real examples who the response body will look like?

Would it be possible for you to provide some real examples who the response body will look like?

here you can find swagger ui example, with 2 parameters it would look like this:
{
  "edoc": "scenario description",
  "configuration_parameter1": {
    "module": "module_name",
    "description": "parameter description",
    "default_value": "default value",
    "verification_fn": "MFA or the list of the valid values",
    "update_fn": "MFA or readonly"
  },
  "configuration_parameter2": {
    "module": "module_name",
    "description": "parameter description",
    "default_value": "default value",
    "verification_fn": "MFA or the list of the valid values",
    "update_fn": "MFA or readonly"
  }
}

Thanks, do I understand it correctly that in the copy&past case I need to take this part
"configuration_parameter1": {
    "module": "module_name",
    "description": "parameter description",
    "default_value": "default value",
    "verification_fn": "MFA or the list of the valid values",
    "update_fn": "MFA or readonly"
  },
  "configuration_parameter2": {
    "module": "module_name",
    "description": "parameter description",
    "default_value": "default value",
    "verification_fn": "MFA or the list of the valid values",
    "update_fn": "MFA or readonly"
  }

And can use it without any changes when starting the scenario (PATCH /scenario/{id})?

Now it's clear to me. Thanks!


mouse-over summary ?

Show QuickInfoDocumentation popup when mouse is over a function or variable.
Visual studio implements this feature.
I don't know if it's is possible or not, from what i have seen in sublime documentation
that might not be supported (or at least not documented).

Right now, Sublime does not support hover events or contextual mouse click events.

Per @steveluc , this is a Sublime limitation, and not something we can change.


Translation to Spanish

PLEASE CAN YOU PUBLISH SPANISH TRANSLATION ??
Millions of people around the world using this language,
thanks!!
Roger

Sorry didn't see this pull request. I am on top of this and will merge once reviewed.

thanks !!
Missatge de Abhijith Chatra @.***> del dia dc., 7 de
des. 2022 a les 18:30:

Sorry didn't see this pull request. I am on top of this and will merge
once reviewed.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/pxt-neopixel/pull/64#issuecomment-1341321831,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKLNZRYA7LR4SV3AB2OHHNTWMDCURANCNFSM6AAAAAARECV3ZQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


testnet / mainnet options

Right now the default is mainnet localhost http. need a way to switch between via argument. Something like: --testnet overrides mainnet default.

https://github.com/slasheks/lisk-api/commit/c85b65df1a7f59b37c1c43f32ac5982d6d286a5c


Self-managed node groups missing desired_capacity_type input variable.

Is your request related to a new offering from AWS?
Is this functionality available in the AWS provider for Terraform? See CHANGELOG.md, too.

Yes ✅: v4.49.0 - https://github.com/hashicorp/terraform-provider-aws/milestone/292?closed=1

Is your request related to a problem? Please describe.

When used with aws provider 4.67.0, omitting this parameter gives on occasion:
│ Error: updating Auto Scaling Group (mygroup-2023041010452696410000007e): InvalidParameter: 1 validation error(s) found.
│ - minimum field size of 1, UpdateAutoScalingGroupInput.DesiredCapacityType.

Issue appears when you do manually change AWS ASG desired nodes configuration in console for ad-hoc operation.
But when specifying this parameter manually in terraform module source, it causes forever drift when v4.67.0 is used.
Describe the solution you'd like.
I would still like an option to specify this parameter value for self-managed node group
Describe alternatives you've considered.

For time-being workaround, added in self-managed-node-group main.tf:

resource "aws_autoscaling_group" "this" {
 ...
  lifecycle {
    create_before_destroy = true
    ignore_changes = [
      desired_capacity, desired_capacity_type
    ]
  }
 ...
}

Thinking about ditching ASG based nodegroups entirely and move to Karpenter

Additional context
Since some of our other modules specify currently AWS provider dependency ~4.0, I cannot yet test this with AWS 5.x providers.

Thinking about ditching ASG based nodegroups entirely and move to Karpenter

This would be my recommendation, it does an amazing job managing your data plane compute and not just scaling - the overall lifecycle, making upgrades easier, etc.
Otherwise, you will want to look at https://github.com/bryantbiggs/eks-desired-size-hack for details on the desired capacity issue and one hacky work around

I have run into this issue as well. What has happened for us:

We set up a node group using only the self-managed-node-group sub-module
The configuration included a schedule definition
Re-applying the node-group worked without issues
When trying to re-apply the next day, terraform now wants to set desired_capacity_type from units to null. I am guessing something about the nightly scale-down has caused drift in an unexpected way.

Error: updating Auto Scaling Group (xxx-xxxxxxxxxxxx): InvalidParameter: 1 validation error(s) found.
- minimum field size of 1, UpdateAutoScalingGroupInput.DesiredCapacityType.

The setup for schedules:
    schedules = {
      scale-up = {
        min_size     = 1
        max_size     = "-1" # Retains current max size
        desired_size = 1
        time_zone    = "Europe/Berlin"
        recurrence   = "0 7 * * 1,2,3,4,5"
      },
      scale-down = {
        min_size     = 0
        max_size     = "-1" # Retains current max size
        desired_size = 0
        time_zone    = "Europe/Berlin"
        recurrence   = "0 21 * * 1,2,3,4,5"
      }
    }

I am not sure how the hack can help with this. It's not about that the desired_size being ignored by default, it's about Terraform wanting to change a field to null which can not be changed to null due to some weird drift issue.
As mentioned, setting the desired_capacity_type value to units explicitly helps in terms of being able to run the apply successfully, but the drift remains. How about adding desired_capacity_type to the ignored changes?


Update imports.lock less frequently

This patch reduces the frequency that imports.lock updates by doing a
few things:

Imports are only updated when necessary for the vet to pass. If vet
would successfully pass without the new audits, only changes to
notes, criteria descriptions, revoked audits, and violations will be
pulled.

Some commands, such as suggest, will always run against the live
copy when not --locked, providing the most accurate results possible.

Only audits for crates in your crate graph will be imported.

When an update is required, all new audits for the given crate will
be fetched and locked, to batch updates as much as possible.

This required doing some changes to how imports are handled under the
hood, as well as a number of changes to the resolver in order to track
whether fresh imports are required with sufficient accuracy. Imports are
also now fetched in more APIs in order to have the most up-to-date
information.
The changes to the resolver involved piping through "caveats" which are
determined when solving paths. This is an expansion on the existing
"needs_exemption"/"fully_audited" flags which were being used to
generate stats after a successful vet to also handle freshly imported
audits which should only be used when necessary.
Special handling was also needed to make sure that audits for unused
criteria are not counted by tracking caveats on a per-criteria basis and
bubbling them out.
Fixes #272

Gankra gave this the thumbs-up.


Expand groups by default

Hi @tannerlinsley,
react-table is great! I have been using it in various projects.  On one of my projects I have a initialstate.groupby and no ability to ungroup. I would however like to have the rows expanded by default.
I was reading an earlier post: https://github.com/tannerlinsley/react-table/issues/1494 but cannot figure out how to implement it.
I would be very grateful if you provide some pointers on this?
Thanks!
Mark

@mpriem I've been experiencing the same issue.  The expanded: true doesn't seem to work when you use both useGroupBy and useExpanded.  I traced this in the code to the fact that grouped rows don't have an 'original' property on them, where the code looks for the expanded attribute.  This kind of makes sense because they're grouped rows, just not clear in the docs.
Anyways..  To fix this you have two options, you can create an 'expanded' object that has true for every row Id that is in your group.  How do you know your row id?  Well currently its the group by attribute followed by the pivot value.   It's definitely not easy.  The much easier way is to use some of the hooks that are present:
  const {
//... other props from useTable
toggleAllRowsExpanded,
    isAllRowsExpanded
 } = useTable(/**/)
// run an effect that expands all the rows and keeps them that way.
  useEffect(() => {
    toggleAllRowsExpanded(true);
  }, [isAllRowsExpanded]);

This isn't a perfect solution, but it got me what I needed.  You can edit the dependencies or the interior of the useEffect to change the behavior as you see fit.  Hope that helps!

Hey @mmacaula . Thanks for the response. I literally had the same solution in place. It works fine and also still have the ability to collapse rows. Thank again!

This worked for me, thanks for your help!
React.useEffect(() => toggleAllRowsExpanded(true), [toggleAllRowsExpanded]);

I was not able to get useEffect to work as described here, as a prop of useTable, but it does work when I use React.useEffect
However I see a warning so I wonder if I am doing it wrong:
React Hook React.useEffect has a missing dependency: 'toggleAllRowsExpanded'. Either include it or remove the dependency array

@stahlmanDesign nailed it :)

Im trying to implement the above to have grouped rows expanded by default, however they are still closed unless manually triggered.  Whats interesting is that 'isAllRowsExpanded' is always false even when opening th grouped rows/columns..

Something is still wrong, using toggleAllRowsExpanded won't expand groups for me.
@tannerlinsley we have a method to open expand row on click via row.getToggleRowExpandedProps() why not having a method to expand groups in the table instance?

For anyone that finds this via a Google search, what you actually want to do is to set expanded: true in the initialState of the options. Also consider setting autoResetExpanded to false so your rows don't collapse once the user starts changing the state of the table.

For anyone that finds this via a Google search, what you actually want to do is to set expanded: true in the initialState of the options. Also consider setting autoResetExpanded to false so your rows don't collapse once the user starts changing the state of the table.

Hey @zeorin , can you clarify there exactly should the expanded: true go? Maybe a small code snippet? Thanks!

Works perfectly, thank you!

@zeorin expanded initial state requires expanded: Record<IdType<D>, boolean>; and still doesn't work if you ignore the TS error

@zeorin expanded initial state requires expanded: Record<IdType<D>, boolean>; and still doesn't work if you ignore the TS error

If you are on V8, there should be no error. That's exactly how you are supposed to do it.


Rsbuild !!!

startup 3 -> ~2s
build 3 -> ~2.5s
rebuild 3-5s -> 0.2-0.5s
reload 3s -> 0.5s (total reload ~6s -> 1s)
hmr now possible
new build overlay
and a lot of other replaced stuff

/deploy


Added a "to_dict" to MSTrack

MSTrack already has a content attribute, I just created a "to_dict" that would return MSTrack.content!

Coverage decreased (-0.06%) to 57.13% when pulling 30f08948436a93c069c96872d668c17f440b4052 on JetDeveloping:patch-2 into 3e748806ea2a6c7713ceade6f18dd966f5751216 on SoCo:master.

This PR might be modding the wrong class. Waiting for clarification in #740.

Sounds good, @KennethNielsen!


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter frigate for common errors and appropiate suggestions to keep this adapter up to date.
This check is based the current head revisions (master / main  branch) of the adapter repository
Please see the result of the check below.
ioBroker.frigate
   -
ERRORS:

[ ] :heavy_exclamation_mark: [E162] js-controller 3.3.22 listed as dependency but 4.0.24 is required as minimum, 5.0.19 is recommended. Please update dependency at io-package.json.

WARNINGS:

[ ] :eyes: [W040] "keywords" within package.json should contain "ioBroker"
[ ] :eyes: [W184] "common.main" is deprecated and ignored. Please remove from io-package.json. Use "main" at package.json instead.
[ ] :eyes: [W505] setTimeout found in "main.js", but no clearTimeout detected
[ ] :eyes: [W515] Why did you decide to disable i18n support?

:thumbsup: No suggestions found
Please review issues reported and consider fixing them as soon as appropiate.
Errors reported by repository checker should be fixed as soon as possible. Some of them require a new release to be considered as fixed. Please note that errors reported by checker might be considered as blocking point for future updates at stable repository.
Warnings reported by repository checker should be reviewed. While some warnings can be ignored due to good reasons or a dedicated decision of the developer, most warnings should be fixed as soon as appropiate.
You may start a new check at any time by adding the following comment to this issue:
@iobroker-bot recheck
Please note that I (and the server at GitHub) have always plenty of work to do. So it may last up to 30 minutes until you see a reaction. I will drop a comment here as soon as I start processing.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@mcm1957 for evidence
Last update at Fri, 06 Sep 2024 07:51:05 GMT

Issue outdated due to RECREATE request. Follow up issue #52 has been created.
This issue will be closed.
your
ioBroker Check and Service Bot


Python cleanup v2

Resubmit some initial cleanup patches on top of the rewritten codebase.

Fantastic!! Many thanks for the nice code and cleanups.


Add Bernards Township School District

@connorslade-school Thank you for your patience while waiting for a review and processing your request.
Pull request merged. Thank you!


Create student.txt

Please help me check the school, thank you

@kurko1rg I am sorry, the domain cmich.edu is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Pack at https://education.github.com/discount_requests/application. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


Hooks should be a per container resource

From @sameo on January 31, 2017 11:34
Hooks are specifically designed for OCI containers, and there could be a set of hooks per container, not per pod.
Copied from original issue: containers/virtcontainers#104

@egernst @amshinde Was this resolved by moving the OCI hooks out of virtcontainers and into the CLI?

Current OCI hook implementation in Kata is per container. However as per my understanding the hooks will run for all the containers in a pod.
@egernst @jodh-intel can this issue be closed ?


ConditionKeyMap

ConditionKeyMap is a Map of set of strings.
"Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": false
                }
            }

The above condition would fail.

https://github.com/minio/minio-go/blob/709d63facd42bb185bd5481decc31ad2d521c962/pkg/policy/bucket-policy-condition.go#L22

@ryanmurf - can you provide instructions on how to reproduce this issue? at the time it was the assumption that each conditions are strings only.
Since looks like new dynamic nature has been added to bucket policy conditions, we have to address this and handle.
// cc @balamurugana

I also ran into this bug. I'm using the AWS Java client and in our normal S3 calls we have:
(Client is just the java s3 client)
client.setBucketPolicy(new SetBucketPolicyRequest(bucketName, S3_BUCKET_ENCRYPTION_POLICY.replaceAll("<bucket_name>", bucketName)));

The policy is: (note the boolean on the server side encryption line)
{
     "Version": "2012-10-17",
     "Id": "PutObjPolicy",
     "Statement": [
           {
                "Sid": "DenyIncorrectEncryptionHeader",
                "Effect": "Deny",
                "Principal": "*",
                "Action": "s3:PutObject",
                "Resource": "arn:aws:s3:::<bucket_name>/*",
                "Condition": {
                        "StringNotEquals": {
                               "s3:x-amz-server-side-encryption": [
                                       "AES256",
                                       "aws:kms"
                                ]
                         },
                        "Null": {
                               "s3:x-amz-server-side-encryption": true
                        }
                }
           }
     ]
 }

{
"Version": "2012-10-17",
"Id": "PutObjPolicy",
"Statement": [
{
"Sid": "DenyIncorrectEncryptionHeader",
"Effect": "Deny",
"Principal": "",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<bucket_name>/",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": [
"AES256",
"aws:kms"
]
},
"Null": {
"s3:x-amz-server-side-encryption": true
}
}
}
]
}

Understood thanks @checketts we will take a look.

http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Boolean
According to this document, boolean values have double quotes. But I tested with AWS S3 and it seems it accepts bool without quotes, however when I try to

@ryanmurf, @checketts, can you explain more your exact problem? is there anything that is not working for you?

$ aws s3api put-bucket-policy --bucket  vadmeste --policy file://policy.json
$

This is a successful operation,  policy.json contains the following json:
{
    "Version": "2012-10-17",
    "Id": "123",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::vadmeste/documents/*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": false
                }
            }
        }
    ]
}

Now, if I want to get the policy:
$ aws s3api get-bucket-policy --bucket vadmeste
{
    "Policy": "{\"Version\":\"2012-10-17\",\"Id\":\"123\",\"Statement\":[{\"Sid\":\"\",\"Effect\":\"Deny\",\"Principal\":\"*\",\"Action\":\"s3:*\",\"Resource\":\"arn:aws:s3:::vadmeste/documents/*\",\"Condition\":{\"BoolIfExists\":{\"aws:MultiFactorAuthPresent\":\"false\"}}}]}"
}

you can notice that double quote returned by AWS S3

@ryanmurf, @checketts, it looks like AWS S3 supports both boolean with and without quotes, for the moment I don't see how the current state is causing any problem. Could you elaborate why this is a problem for you ?

Closing this. Please reopen if you think this is not resolved.


Log fewer lines when making requests to titus-isolate

The Titus Isolate did not return code 200 message gets logged a lot, and can be potentially misleading.  Log it less.

Why is it happening so much? Why is it misleading?

Why is it happening so much? Why is it misleading?

titus-executor polls titus-isolate very quickly. The current logging looks
like there's something wrong when it's really by design behavior.
On Tue, Jan 19, 2021 at 5:25 PM Sargun Dhillon<EMAIL_ADDRESS>wrote:

Why is it happening so much? Why is it misleading?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/Netflix/titus-executor/pull/516#issuecomment-763259877,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEKORZ3L37XYOTKGZUSJPTS2YWG7ANCNFSM4WJXI6VA
.

titus-executor polls titus-isolate very quickly. The current logging looks
like there's something wrong when it's really by design behavior.
On Tue, Jan 19, 2021 at 5:25 PM Sargun Dhillon<EMAIL_ADDRESS>wrote:

Why is it happening so much? Why is it misleading?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/Netflix/titus-executor/pull/516#issuecomment-763259877,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEKORZ3L37XYOTKGZUSJPTS2YWG7ANCNFSM4WJXI6VA
.

Can we add a comment indicating that this poll loop is non-blocking on the titus isolate side?

Can we add a comment indicating that this poll loop is non-blocking on the titus isolate side?

@sargun - https://github.com/Netflix/titus-executor/pull/521

@sargun - https://github.com/Netflix/titus-executor/pull/521


[$500]  IOU/LHN - IOU not been pinned by default & pin option displayed in context menu

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.3.99-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:
Precondition: user should be signed in

Open app
Create IOU money request with any user
Navigate back to LHN
Observe the IOU report position in LHN and its icons
Navigate to the created IOU details page
Tap on 3 dots button (context menu)
Tap on "Pin" option
Repeat 3-4 steps
Create IOU money request from second device to the main device user
Open the created IOU details page
Tap on 3 dots button (context menu)

Expected Result:
Step 4: Transaction thread report is pinned by default
Step 7 and 11: Transaction thread report has pin no option
Actual Result:
Step 4: Transaction thread report isn't pinned by default
Step 7 and 11: Transaction thread report has pin option
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/02ee1e05-17a3-4d1d-b1e0-22c8751cdb10
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0159bd7d65d5681c02
Upwork Job ID:<PHONE_NUMBER>908154368
Last Price Increase: 2023-11-29

Test Rail: https://expensify.testrail.io/index.php?/tests/view/3974494&group_by=cases:section_id&group_order=asc&group_id=229063

Proposal
Please re-state the problem that we are trying to solve in this issue.
When requesting money in a conversation, the latter should be pinned.
What is the root cause of that problem?
IOU.requestMoney does not pin the report.
What changes do you think we should make in order to solve the problem?
I added the following line to IOU.requestMoney :
Report.notifyNewAction(chatReport.reportID, payeeAccountID);

[Please re-state the problem that we are trying to solve in this issue.]
The problem is that the IOU request is not automatically pinning the conversation after it is made
[What is the root cause of that problem?]
Essentially the togglePinnedState is not being called in the current IOU.js  RequestMoney function.
Report.togglePinnedState(chatReport.reportID, false);

[What changes do you think we should make in order to solve the problem?]
Incorporating a Report.TogglePin on the already existing IOU.RequsetMoney function should return this to normalcy
[What alternative solutions did you explore? (Optional)]
Alternatively the actual backend for the requestMoney could perform a similar action and just handle this but this may be this may not be the most simple, predictable and trackable solution in the current setup

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~014853d868137150b0

This looks like a backend issue. IOU details report should have isPinned: true when creating, but it isn't now

Few proposals ready for you to review @Santhosh-Sellavel

Sorry @bfitzexpensify Not sure how I missed this. I've unassigned newly assigned issues due to low bandwidth somehow missed it. If any C+ can review this immediately please Reassign. Otherwise I can look into this tomorrow.

All good! Tomorrow is fine.

Sorry again for the delay here
I'm confused here about Expected Result.

Step 4: created IOU report should be pinned by default in LHN as mentioned in the TestRail case steps

Are you referring to each IOU Request thread should be pinned.  Can you share me test rail link/ID

Steps 7 and 11: the pinned option should not be displayed in the context menu on IOU report details page

@Santhosh-Sellavel
Test Rail: https://expensify.testrail.io/index.php?/tests/view/3974494&group_by=cases:section_id&group_order=asc&group_id=229063

Thanks for the test rail. @lanitochka17 was this test passing earlier, when it got added.
@bfitzexpensify Can you check and provide us clear expected OP. From test rail I found this internal issue link https://github.com/Expensify/Expensify/issues/298942 but I don't have access to this was this a regression if so please provide more details from which issue this got added, thanks!

@Santhosh-Sellavel OK, these are the TestRail steps:

Create a IOU (or use an existing IOU conversation)
Verify that IOU conversations (reports) are always pinned by default in the LHN
Right-click on the IOU conversation (the one with a green dot) in the LHN
Verify that there is no pin option on the context Menu

So @dukenv0307's identified issues here are correct:

Transaction thread report isn't pinned by default
Transaction thread report has pin option

Does that help clarify things? I also updated the actual/expected behaviours in the OP.

Pinned always, so it shouldn't be possible to unpin

Sorry to come in with this now @Santhosh-Sellavel @dukenv0307 - after chatting in Slack, we've decided the following:

Transaction thread report should be pinned by default (this is the same)
Transaction thread should be unpinnable (this is new)

Basically, we need to fix only one of the two bugs here - the ability to unpin the IOU should remain as it is now (so we'll want to update Step 4 of the existing TestRail thread

Yeah, right!

Cool, so it sounds like we need both a BE and FE change. Does the order of those changes matter?

Sweet. OK, @neil-marcellini just tagging you so you're aware of the need for BE changes too - is that something you have the capacity to take on?

@bfitzexpensify thanks for the tag. I have 4 or 5 issues that are higher priority than this, but I can work it in if needed. Would you please help me out by updating the description with simple tests steps and the updated expected and actual results? I'm not really clear on it yet.

@neil-marcellini Should we wait for BE or let's go head test and merge FE?

Cool, then I too think the same @dukenv0307

I think we should wait for BE to complete the final testing.

@neil-marcellini When can we expect BE changes?

bump @neil-marcellini

@bfitzexpensify / @neil-marcellini  bump on the BE changes here

Any update @neil-marcellini / @bfitzexpensify

Hi guys, I finally checked my mentions lol. Sorry for the delay! I was never assigned, so I have been totally unaware of this until now. Please don't hesitate to DM me in the future. Any way, I'll take a look.

I'm checking on the priority of this issue in Slack here

Hey @lanitochka17 - can you clarify which test case this issue was identified from? After chatting in Slack, we don't believe this is actually an issue, and we'd like to update whichever test this is originating from.

@bfitzexpensify Hello
TR https://expensify.testrail.io/index.php?/tests/view/3974494&group_by=cases:section_id&group_order=asc&group_id=229063

@bfitzexpensify Before a hiring decision was made, these were the inputs we got here in https://github.com/Expensify/App/issues/31403#issuecomment-1836594930, not sure where got mixed was the testrail updated?

@Santhosh-Sellavel OK, these are the TestRail steps:

Create a IOU (or use an existing IOU conversation)
Verify that IOU conversations (reports) are always pinned by default in the LHN
Right-click on the IOU conversation (the one with a green dot) in the LHN
Verify that there is no pin option on the context Menu

So @dukenv0307's identified issues here are correct:

Transaction thread report isn't pinned by default
Transaction thread report has pin option

Does that help clarify things? I also updated the actual/expected behaviours in the OP.

I think this qualifies for payment, as most work is done.

@Santhosh-Sellavel I can't see the TestRail history but the current TR step, which is:

Verify that IOU conversations (reports) are NOT pinned by default in the LHN

Differs from step 2 I'd listed above in that comment:

Verify that IOU conversations (reports) are always pinned by default in the LHN

So, the expected behaviour was updated, and therefore this issue is no longer an issue.
Agree that this qualifies for partial payment (at 50%) due to the work already completed.

Payment summary:
Contributor: @dukenv0307 to be paid $250 via Upwork ✅
C+: @Santhosh-Sellavel to be paid $250 via manual request

Requested on ND

$250 approved for @Santhosh-Sellavel


Limited Number of accordions?

Thanks for posting this accessible accordion. I've been testing it and it's working. I've even styled it to match our organizations look and feel without any problems. However, now that I've done my tests, I've attempted to apply with actual content.
I've been using Voiceover on a Mac to test and everything works fine until I add more than 10 or 12 list items, and then things start to fall apart.
After that, the "Show/Hide" buttons open and close the accordion, but the "control/option/right arrow" starts to skip the "a11yaccordionHideArea" content and jumps to the "a11yAccordionItemHeader" - the only way I've been able to get it to work again is to surround my "a11yAccordionItemHeader" titles with h2 heading tags, and list them using the "control/option/u" command to list the headings and jumping to the heading I need. But even then the "Show/Hide" button doesn't work, I have to click on the h2 title to open the accordion.
Is there a limit on how many accordion items can be used?
Here something else that may also be a factor:
I am implementing this into a SharePoint Content Management System.
Is there a problem using this script with Content Management Systems?
Thank you for your help.

Hi @smc-pt ,
I'm glad to hear that my accordion could be of help in your project. I will try to reproduce the issue you've reported. Quiet honestly not sure why this issue happening to you since this accordion uses a pretty simple HTML structure which should work no matter how many items are within. I definitely did not notice any limitations on the number of items.
I wonder if you have some "problematic" content in one of the accordion items which causes this behavior. OR just like you've mentioned, there is something odd related to the CMS you are using. To be honest I have not tried to use my accordion in CMS before but I know other people who used accordion+CMS without a problem.

One of the good potential tests would be to increase number of items in the basic example I provided in the GitHub repo and see if it breaks accordion. I will do this test myself as well.

Another good test is to extend the basic example with the content you are using on your production and see if it breaks anything. Theoretically the example is pretty bare bones HTML and if you change accordion to be the same as in the project you are working with you should be able to observe the same error... if any.

Hi @anvk,
Thanks for the response.
I have a feeling it's a SharePoint issue. The code inside the "a11yAccordionHideArea" div is a simple paragraph. Nothing fancy. And I was adding list items one at a time. Everything worked fine until I added the 10th item. Then it all fell apart.
It seems to work locally, or on a separate server, although the show/hide items don't display.
I'll continue to experiment.


NFC: More Expr node tail allocations

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge

This is cool. Have you observed a memory usage decrease with this and your other changes?

Hi @slavapestov – I've been tracking build times, not total memory usage. Unless somebody at Apple has been committing nontrivial performance over the last week or so, my changes have more than halved the build time required for the stdlib on my Linux box. The gains are good but not as dramatic on my MacBook Pro. What if any performance changes have you guys noticed?
PS – What if anything do I need to do to get CI to retest this once the master branch is unbroken?
Here is another go:
@swift-ci please smoke test and merge

Trying again with #13553


feat: add VcIssuerMock.json (a testable mock issuer implementation)

Already tested that all vc2.0 tests passed.
The test target architecture and deployment settings are documented in: https://github.com/laysakura/vc-issuer-mock/blob/main/crates/vc-issuer-mock-core/tests-vc-api/README.md

this cool thanks

@laysakura I like your implementation, but you list it as a mock implementation. How is this a mock? As it is currently tagged it would end up the report here: https://w3c.github.io/vc-data-model-2.0-test-suite/
Are you ok with your implementation showing up in that report? Maybe you should mark it as a beta or an alpha if your implementation does actually really sign and verify 2.0 VCs.

@aljones15 Thank you for your feedback.
To clarify, this implementation is designed to provide a VC-API for Issuers that can be used in unit tests by those working with VCs (such as Issuer Coordinators or Holder Coordinators in VC-API terminology). It does actually sign VCs in accordance with VCDM v2.0 specifications.
I agree that labeling it as an alpha implementation would be more appropriate, and I will update it accordingly.
With these clarifications, I would be comfortable with this implementation appearing in the report you mentioned. If there are no further concerns, I hope it can be included.

@laysakura More than happy to have another implementation so feel free to merge, but do keep in mind mock implies a fake issuer, which might create misunderstandings about what is mocked with your issuer and verifier.

Thank you for building this, @laysakura! I think it's a great addition to the test suite results and a huge asset for folks wanting to wrap their implementations in VC-API for use with the test suites (or beyond).
In addition to adding it here, I hope to also promote it to other implementers who need this sort of wrapping approach--which should further lower the bar for implementers to get added to the test suite.
Much appreciated, @laysakura! 🙇


What changed in v0.27.1?

I empathize with the sentiment here, but it's really not helpful for users...

@agriffis see #3062, afaik nothing but the version number

https://github.com/ramda/ramda/compare/v0.27.0..v0.27.1

That's right, @semmel. We bungled v0.27.0, and corrected the mistake in v0.27.1. As for what changed in v0.27.0, I don't know as I'm no longer actively involved in Ramda's development.


Why is the Spring Authorization Server Release version used as serialVersionUID

In org.springframework.security.oauth2.server.authorization.util.SpringAuthorizationServerVersion the serialVersionUID is defined which is used across all spring authorization server classes which implement the Serializable interface. However I do not unterstand the intention for that.
Lets assume these classes are used within a session store. For example the OAuth2Authorization. With every new release we would invalide these sessions due to a changed serialVersionUID and the resulting InvalidClassException when trying to deserialize the objects stored in the current session.
Wouldn't it be a better practice to provide an own serialVersionUID for every class which implements Serializable and only change it when real incompatibilities like removed fields where introduced? And provide a changelog for these changes?
Another question would be how am I supposed to extend the OAuth2Authorization which should be possible due to the fact that the class is not declared as final? There's no all args ctor, the fields are private and not protected. With an extended OAuth2Authorization it would be possible to overcome the serialVersionUID issue and provide an easier access to information stored within the attributes through own getters.

@Chr3is Questions are better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it).
FYI, Spring Authorization Server follows how Spring Security assigns serialVersionUID using the release version. We consider the complete set of domain classes for a specific version not just one because compatibility needs to work as a whole for the specific version - not just it's smaller parts - if a change is made to one domain class only. You can consider JSON serialization instead of Java Object serialization for smoother upgrading between versions.

@jgrandja this is rather a discussion than a question. An enhancement could be to provide a "better" versioning for domain classes or at least to increment the serialVersionUID only if a real incompatibility was introduced. And this should not happen with a patch-release if you follow correct versioning. Spring Security Core (Release 5.8.2) has a serialVersionUID of 580L and not 582L.
One suggested enhancement is also to make org.springframework.security.oauth2.server.authorization.OAuth2Authorization better extendable with protected fields and a protected all args ctor. This class is used in one of the core interfaces e.g. OAuth2AuthorizationService and should be easy extendable for custom implementations. At the moment you're able to extend this class but you can't set the private fields like id, registeredClientId..

@Chr3is

this should not happen with a patch-release

Thanks for catching that! That was a mistake on our end. It has now been fixed and pushed to all 3 branches.
OAuth2Authorization is fully extendable. OAuth2Authorization and OAuth2Authorization.Builder provide protected constructors.

protected all args constructor

That is one approach but we went with the approach on users extending from OAuth2Authorization.Builder to provide their own custom attributes and they have full access to the existing attributes via the public and/or protected mutator methods - fields do not need to be protected.

@jgrandja Thanks for fixing that!
I have no clue how an extended OAuth2Authorization.Builder could work and how the private fields, coming from the OAuth2Authorization, should be set in my extended OAuth2Authorization. Could you provide an example? That would be great. (sidenote: we use lombok for builder generation to avoid to much boilerplate code, but this won't work here at all)
import org.springframework.security.oauth2.server.authorization.OAuth2Authorization;
import org.springframework.security.oauth2.server.authorization.client.RegisteredClient;
import org.springframework.util.Assert;

public class MyOwnAuthorization extends OAuth2Authorization {

    private final String myOwnField;

    public MyOwnAuthorization(String myOwnField) {
        this.myOwnField = myOwnField;
    }

    public static MyOwnAuthorizationBuilder withRegisteredClient(RegisteredClient registeredClient) {
        Assert.notNull(registeredClient, "registeredClient cannot be null");
        return new MyOwnAuthorizationBuilder(registeredClient.getId());
    }

    public static class MyOwnAuthorizationBuilder extends OAuth2Authorization.Builder {
        private String myOwnField;

        protected MyOwnAuthorizationBuilder(String registeredClientId) {
            super(registeredClientId);
        }

        public MyOwnAuthorizationBuilder myOwnField(String myOwnField) {
            this.myOwnField = myOwnField;
            return this;
        }

        @Override
        public OAuth2Authorization build() {
            OAuth2Authorization authorization = super.build();
            MyOwnAuthorization myOwnAuthorization = new MyOwnAuthorization(myOwnField);
            // myOwnAuthorization.id = this.id

            //no idea how this is intended
            return myOwnAuthorization; //missing all fields from parent OAuth2Authorization and no possibility to set them
        }
    }
}

@Chr3is Apologies but OAuth2Authorization requires some changes to be fully extendable. OAuth2Authorization would need protected setters and OAuth2Authorization.Builder would need protected getters.
Can you provide more details on the type of attributes you need in your extended model? Could you not use OAuth2Authorization.attributes.

@jgrandja No worries!
In our case we extended the authorization with additional information like authorizedClaims, authTime, our representation of the authorizerequest (containing additional information like nonce, prompt,..) and so on. We don't want to use a generic map but use an explicit typesafe & understandable model. And this should be no problem if the OAuth2Authorization is fully extendable.

@Chr3is Can you please log a new issue for "Allow OAuth2Authorization to be extensible". Would you be interested in submitting a PR for this?

@jgrandja I'm going to create a new issue for that and yeah I can try to provide a PR for this!


Set up an environment for acceptance end-to-tests based

We can use: https://owasp.org/www-project-juice-shop,
which is available in Docker: https://hub.docker.com/r/bkimminich/juice-shop.
It would be nice to have a base that can be executed as part of the CI checks, that we can extend over time.

One example we could use to start with is:
/rest/products/search?q=text, which is vulnerable to SQL Injection based on Status Code (see profile).
For instance:
GET /rest/products/search?q=text' HTTP/1.1
HTTP/1.1 500 Internal Server Error

GET /rest/products/search?q=text'' HTTP/1.1
HTTP/1.1 200 OK

GET /rest/products/search?q=text''' HTTP/1.1
HTTP/1.1 500 Internal Server Error


Don't break modular design

Removes Messages.fs and makes things modular again

@vaskir I already incorporated some of your slack critique points


Blog section

Implemet index page for blog - /blog. It should list all existing posts sorted by date - newest in the top.
Acceptance criteria

[x] route

[x] read all existing posts, parse frontmatter and pass to template
[x] sort posts so the newest in the top
[x] format and handle attributes such as date, author, path (so we can link)
[x] test

[x] implement template and styles

Analysis
For parsing frontmatter - https://github.com/dworthen/js-yaml-front-matter
---
title: My post
date: 2017-10-03
slug: my-post
author: Anu
gravatar: ???
---

FIXED in https://github.com/datahq/frontend/commit/34ef8fb14069aecbb3c86db8f2e80c9e89099b73