Disabling harvester_activity_handler does not disable harvester checks

Even if the handler harvester_activity_handler is set to enable: false, a harvester is still expected: Your harvester appears to be offline! No events for the past 600 seconds.

For context, this instance of chiadog is monitoring a full_node that has been started with services="node farmer-only wallet", i.e. it's not running a harvester on purpose since there are no local plots.
Issue repeats with Chia log level set to DEBUG or INFO, have not tested other levels.

[2023-01-16 15:29:28] [    INFO] --- Starting Chiadog (unknown) (main.py:54)
[2023-01-16 15:29:28] [    INFO] --- Enabled local file log consumer. (log_consumer.py:60)
[2023-01-16 15:29:28] [    INFO] --- Using temporary directory /tmp/tmpwt8e5db5/debug.log.offset (log_consumer.py:63)
[2023-01-16 15:29:28] [    INFO] --- Enabled remote pinging to https://hc-ping.com/xxxxx (keep_alive_monitor.py:36)
[2023-01-16 15:29:28] [    INFO] --- Keep-alive check period: 300 seconds (keep_alive_monitor.py:45)
[2023-01-16 15:29:28] [    INFO] --- Initializing Pushover notifier. (pushover_notifier.py:13)
[2023-01-16 15:29:28] [    INFO] --- Enabled stats for daily notifications (stats_manager.py:48)
[2023-01-16 15:29:28] [    INFO] --- Summary notifications will be sent out every 24 hours starting from 12:00 (stats_manager.py:61)
[2023-01-16 15:29:28] [    INFO] --- Disabled handler: harvester_activity_handler (log_handler.py:63)
[2023-01-16 15:29:28] [    INFO] --- Initializing handler: partial_handler (__init__.py:28)
[2023-01-16 15:29:28] [    INFO] --- Enabled parser for partial submitting stats. (partial_parser.py:28)
[2023-01-16 15:29:28] [    INFO] --- Initializing handler: block_handler (__init__.py:28)
[2023-01-16 15:29:28] [    INFO] --- Enabled parser for block found stats. (block_parser.py:28)
[2023-01-16 15:29:28] [    INFO] --- Enabled check for found blocks. (found_blocks.py:15)
[2023-01-16 15:29:28] [    INFO] --- Initializing handler: finished_signage_point_handler (__init__.py:28)
[2023-01-16 15:29:28] [    INFO] --- Enabled parser for finished signage points. (finished_signage_point_parser.py:28)
[2023-01-16 15:29:28] [    INFO] --- Enabled check for finished signage points. (non_skipped_signage_points.py:19)
[2023-01-16 15:29:28] [    INFO] --- Initializing handler: wallet_added_coin_handler (__init__.py:28)
[2023-01-16 15:29:28] [    INFO] --- Enabled parser for wallet activity - added coins. (wallet_added_coin_parser.py:26)
[2023-01-16 15:29:28] [    INFO] --- Filtering transaction with mojos less than 5 (wallet_added_coin_handler.py:26)
[2023-01-16 15:39:29] [ WARNING] --- Your harvester appears to be offline! No events for the past 600 seconds. (keep_alive_monitor.py:83)
[2023-01-16 15:44:29] [ WARNING] --- Your harvester appears to be offline! No events for the past 901 seconds. (keep_alive_monitor.py:83)

Relevant config section:
handlers:
  wallet_added_coin_handler:
    enable: true
    min_mojos_amount:  5
  finished_signage_point_handler:
    enable: true
  block_handler:
    enable: true
  partial_handler:
    enable: true
  harvester_activity_handler:
    enable: false

Environment:

OS: ghcr.io/chia-network/chia:latest
Python version: N/A
PIP version: N/A
Chia version: 1.6.2
Chiadog version: v0.7.5 as present in sha256:4c19849657d2fc78c91257f1c18c8a18ac6a99d094e4d6c3e530300d3905a291
Harvester: No local harvester, connected to two remote harvesters.

Looking at the code, it seems the keep_alive_monitor is hardcoded to assume a harvester: https://github.com/martomi/chiadog/blob/main/src/notifier/keep_alive_monitor.py#L30

After a deeper peek, the root cause is a bit deeper. There's only one handler that emits KEEPALIVE events, which is harvester_activity_handler.py which in turn is keyed off seeing harvesters participate in challenges. Ergo, there is no keepalive for any other services except the harvester.
So the "proper" solution to this would be to add KEEPALIVE events to the other handlers when they see activity proving health for that service. However in scope of not spamming harvester being down when one doesn't exist on purpose, I'd say the keep_alive_monitor needs to be initialized empty instead of always assuming a harvester is present. That way the first keepalive seen from a service starts monitoring for it. I'll have a poke at making a PR.

You’re on the right path :) I added the config option for disabling handlers (relatively) recently in version 0.7.1 (here). And indeed, that config only applies to the actual log handlers but doesn’t affect the behavior of the keep_alive_monitor.
Note that there’s also a long-standing thread on this here: https://github.com/martomi/chiadog/issues/93
Happy to look into a PR if you come up with some proposal to solve this. I think KEEPALIVE events can only come from either the signage point handler or the harvester handler? And we should keep defaulting to the harvester since in many setups where chiadog is installed there’s only a harvester and no full node.

The way I'm looking at the keepalive setup, any service posting KEEPALIVE events would prime the system for that service. Relying on that fully however means that a service that was already down at the time of chiadog starting is never notified as down.
I'll have a go of just reading the enabled handlers from the config and prepopping based on that, which would mean that with a default config, all keepalives are expected. This of course means I'll need to ensure all services do have a keepalive event sender :D
Thanks for the thread context! I think it's plausible to manufacture keepalive signals for any service, as long as there's a log message we know of that proves it's functioning. For the wallet for example we could parse a message like:

2023-01-18T12:45:07.268 wallet chia.wallet.wallet_blockchain: INFO     Peak set to: 3123251 timestamp:<PHONE_NUMBER>
and check that the diff between the timestamp value and us reading the message is less than say 30 seconds, which gives a reasonable estimate that the wallet is healthy and up to speed.

Agreed!

@martomi:
Working on this I've come across a few architectural design choices that may need to be questioned and/or changed, so a handful of questions:

Handlers are currently standalone and not grouped by service.

I could just add a separate wallet_peak_handler but it gets unwieldy in both the config and in the code to keep expanding this pattern. Alternatively would it make sense in config to treat handlers per service instead of as individual handlers? What I mean is, have config items and the enable bit per service instead of per individual handler.
Keeping it per individual handler stands to explode the size of the config where I need to add new handlers, since every handler is enabled one by one and the current config system does not allow defaulting them to off or on.
The practical problem here is simple, setting keepalive values is assumed per service in the keepalive messaging system, so configuring them at the level of individual handlers will be confusing since they apply at the service level. The alternative would be to have a separate list of keepalives to enable and their values, but that's duplication with enabled handlers.
The most transparent & backwards compatible method I think would be to define in code a mapping of services to handlers and add the keepalive values per service to the keepalive config section. This mapping could also be used to init handlers to avoid having to touch handler init in redundant places.

The current config class is a bit "unhelpful" in that it strictly defines what is expected in the config and bails if that's not met.

This does not allow for defining default values and only overriding the ones the user wants, again contributing to config bloat. If enabling new keepalives across multiple releases, this means multiple times of people needing to amend their configs to get "full service". An alternative could be detecting from log output which handlers should be enabled instead of having it user configurable. But I imagine this would split opinions. (And could cause log format changes to silently disable keepalives.)
One solution is swapping this out for a YAML configuration library that can handle defaults, for example https://github.com/beetbox/confuse seems fitting for the job. I'd be happy to PR this change and only then layer the keepalive changes to take advantage of the more flexible config parsing. The alternative is continuing the current practice where folk's handler configs may become obsolete and incompatible with no fallback to sane defaults. This seems to be the "Chia Way" of doing configs, but it's just as shitty from them. :-)

No matter how the config is parsed, the current structure of handlers -> maps of individual handlers seems to become unwieldy. At a minimum I'd propose changing it to handlers -> {fullnode,harvester,farmer,wallet} -> maps of individual handlers

If you can share any insight into what matches the style of the project as the direction of evolution, I can then make more informed proposals. :-)

Thank you for the detailed write-up - really appreciate the thoughtfulness about the direction and future implications!
Handler Groupings
The mapping service -> [handler] makes sense to me.  I imagine a config in the future could look like (you might have better ideas):
monitored_services:
    - fullnode
    - harvester
    - farmer
    - wallet

handler_configs:
    wallet_added_coint_handler:
        min_mojos_amount: 5

Where enabled_services will implicitly enable all handlers linked to the specified service without ability for finer grain control on handlers (I don’t see a use-case). Also I think all services in that list should be monitored in the keep_alive_monitor without any additional config in that section, what do you think?
And handler_configs would be just for some extra optional config overrides. But that section would be completely optional as we’ll want to have sane defaults here.
We could also go for a more nested approach in the config as in services > handlers. My opinion isn’t strong here. It just feels cleaner to keep it flatter for some reason.
Config
I’m 100% onboard with handling the tech debt in the YAML configuration as a potential first step. In the past, we’ve been careful to maintain backwards compatibility for folks by adding optional configs with sane defaults. The problem is that those defaults are configured at the point of usage of the respective config values. It should really happen in the Config class which is quite useless in its current form.
Note that, already today, the config-example.yaml contains more than necessary for documentation purposes. A functional config out in the wild can be 80% smaller and still have everything enabled.
E.g. this should work
notification_title_prefix: 'Chia'
log_level: INFO
chia_logs:
  file_log_consumer:
    enable: true
    file_path: '~/.chia/mainnet/log/debug.log'

notifier:
  pushover:
    enable: true
    credentials:
      api_token: 'dummy_token'
      user_key: 'dummy_key'

Direction of Evolution
You may have noticed that the project is mostly in a feature-freeze for the past 1+ year. I’ve been lurking around and making sure we’re merging and releasing bugfixes to not degrade the existing experience.
In general I’m happy to discuss and support community-driven evolution as long as the changes are thoughtful and (most importantly) don’t increase the maintenance burden. 😄
It should also be noted that Chia Network itself is investing resources into an official chia farming monitoring tools (video from JM). Which means that the long-term usefulness of chiadog is potentially limited.
Trying to be maximally transparent so you can calibrate how much you would like to invest in the architecture & extensibility here. Otherwise, I’m happy to move in the proposed direction!

Thanks for the details and disclosure. I think there's enough here for me to continue. It sounds like we're pretty aligned so I'll start working on the config migration first with an emphasis on as much backwards compatibility as sane.

Note to self I learned the hard way during testing: Also need a keepalive check for checking that the logfile itself is still flowing. Hooking up to a log file that isn't updating at all creates a very eerie scenario and while it does trigger keepalives, that can be misleading if instead it's not really a service not working, and actually that logging itself has "failed".


typing: error when using 'Union' / 'Optional'.

Hi there!
I just started using hug a couple of days ago and I like it a lot. It feels very intuitive and the docs are nice to read. Kudos! :)
I get an error when I use Union or Optional from the typing module like this:
from typing import Optional

@hug.get('/images/{filename}', output=hug.output_format.file)
def get_image(filename: str, w: Optional[str] = None):
    """
    ...

Parameter w is optional, so it should be None by default or a str if provided, rigth?

Hug currently does not support much of python new typing module but you should be able to specify an optional url parameter by just setting the default value like you did above. Just use w: str = None instead of w: optional[str] = None.
This weekend I am hoping to make changes that will allow hug to start using at least some of the new typing module features.

Thanks for your reply!

This weekend I am hoping to make changes that will allow hug to start using at least some of the new typing module features.

This is cool! I really love the new typing module, would be great if hug supports it.

Hi @BrandonHoffman,
hug is just great! I just wanted to check out if there are any news here?
May I help somehow?
Greetings

This is still an issue as of Hug 2.4.1

Hug still does not seem to support typing.
My static type checker warns me about:
import hug
       ^^^
       Stub file not found for "hug"

@hug.get(urls=
^^^^^^^^
Untyped function decorator obscures type of function; ignoring decorator


[JS/TS] Inconsistent highlighting when Ctrl + hovering on functions

Issue Type: Bug
When you hold ctrl and hover over a function, it gives you a preview of the first few lines of that said function, however, if you have constants in that part of the code, they become light blue when they're not followed by the word "const", instead of the usual darker blue. This is also the case with other special highlightings such as using constructors on a class.

The hover only does syntax highlighting, while the editor also does semantic highlighting.
That's expected. There are no plans to bring semantic highlighting also to the hover.


Elasticsearch

Migrating from algolia to elastic

[ ] first version of querying ES from GO
[ ] send data to elasticsearch
[ ] build elastic search index

started briefly on tihs

nice. Can you create a draft PR so I can follow the progress?

nice. Can you create a draft PR so I can follow the progress?

https://github.com/bcc-code/bcc-media-platform/compare/feat/elasticsearch

@fredrikvedvik aka mr elastic, do you have any tips for implementation?

or lmk if you just want to do it 😏

from my point of view, you don't need to implement everything. I just need a good starting point. That means a way to get the data into elastic search and a way to run integration tests against elastic search. The actual search indexes, I can build myself.
In the BMM API you can see an example on what the tests could look like.

Next: extend the capability of elastic search + phrase roll out

The flag is elastic-search-enabled.
All active backend flags are defined in https://github.com/bcc-code/bcc-media-platform/blob/master/backend/unleash/flags.go if you need to find/check the other ones.

For search terms like

Da jeg var barn
kampen
Det store

Where terms are from the title of a show,
There is no result relevant result (results from the serie) both on show and episode level

Created #1043 to address search quality


HTTP Response Vary header uses X-Forwarded-Protocol instead of X-Forwarded-Proto

As far as I can tell from online research, X-Forwarded-Proto is the more standard way of forwarding the protocol; some older versions of Django use X-Forwarded-Protocol, but most everything else does not.
One possible solution: just add X-Forwarded-Proto as another Vary option
Better solution:  Make the Vary header configurable (noting that TODO on the above lines about only using User-Agent when necessary).

The vary header is already configurable. You can update HTTP.vary config via yaml to override the default.
https://github.com/silverstripe/silverstripe-framework/blob/3/_config/config.yml#L19
I'd happily accept a PR to change the X-Forwarded-Protocol to X-Forwarded-Proto though.

fixed by #7522


Composable Architecture References

Feature Request
Some patterns do not supply all the details for a given node within an architecture and indeed the node may be implemented in different ways by different pattern instantiations.
Description of Problem:
It would be good to provide a mechanism for a pattern instantiations to supply the implementation detail in additional CALM files. This could be something like:
{
  "interfaces": [
    {
      "unique-id": "producer-ingress",
      "host": "{{ INGRESS_HOST }}",
      "port": -1
    }
  ],
  "node-type": "system",
  "name": "General API Producer",
  "description": "The API Producer serving content",
  "unique-id": "api-producer",
  "detailed-architecture": {
       "$ref": "api-producer.json"
   }
},

Having this feature (with interfaces) will enable us to create composable patterns within CALM.
@rocketstack-matt

I really like this idea, it gives us the ability to drill in and out of architectures and provides the mechanism we wanted to enable us to represent what would be different levels in C4 without polluting a single model.

After a discussion with @rocketstack-matt I have created a proposed schema change in #132. This is a nice way of defining the additional node, however it comes with one architectural sticking point that the pattern and detailed-architecture node would need to use the same schema version. This could become problematic.
We will need to review how we might approach this with a view to make the detailed-architecture support a different version of the CALM schema

What is it we actually want to achieve with this reference?
I think what we're trying to achieve is to enable different systems (or indeed subsystems within a complex system) to be linked so we can split what would be an unmanageable documentation process into something that provides 'right sized' views and enables the consumer (human or tool) to be able to navigate from one to the other.
If this is the case do we need to do anything other than specify the URI of an implementation? Ideally we would be able to provide a reusable repository mechanism for organisations to store their architecture implementations (and patterns) but assuming the referenced URI is findable then the human or tool could navigate and continue their journey.
Could we therefore simply make this a string?

In #132 we created a PR with a self referential schema validation, this could potentially cause multiple issues:

It could pin the version of the calm together with the further detailed-architecture. This had the potential to be awkward to maintain pattern instantiations and the linked more detailed architectures
Referenced architectures might not be available in all situations

Instead we will create a soft reference, which for the purpose of this issue will be a string property. Our tooling can then add a flag to understand the optional detailed-architecture node and follow the reference and validate independently against that version of the calm schema. Given the nature of calm, this might require a fork to execute a different context and command.


PDF generation failing

No error message being reported, crash in Mn2Pdf, failing on blank documents and on test documents

Please provide:

xml source
full log of mn2pdf execution

@opoudjis is the issue still have?

Issue appears to have gone away.


Update setup.py

Only python3.10 is compatiple with current use of @staticmethod as discussed in https://github.com/scottcwang/openssh_key_parser/issues/1. Too avoid auto update issues, with python <3.10

Thank you very much! I've just built and released 0.0.3 with your patch.


Git not opening in Windows 10 PowerShell

Hi, I am able to open git bash in terminal but not opening in Windows 10 PowerShell.
Any idea. as of now i am using 2 terminal to replicate as 2 users. please suggest. what might be the issue in opening git in powershell

I will suggest to install power shell 7 on your windows 10. After that try to open git in power shell 7.
Refer here for installation: https://github.com/PowerShell/PowerShell/releases

Hi Satya, Still facing the same issue after installing power shell 7.
[image: image.png]
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Tue, May 5, 2020 at 5:35 PM Satya-Sahoo<EMAIL_ADDRESS>wrote:

I will suggest to install power shell 7 on your windows 10. After that try
to open git in power shell 7.
Refer here for installation:
https://github.com/PowerShell/PowerShell/releases
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/848#issuecomment-624015398,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMGNFFP3IY2JP4HOJPIP2LRP76KDANCNFSM4MZJZLEA
.

--
Thanks and Regards,
Rajesh08074502593

pleas a screen shot of an error you faced.

[image: image.png]
On Tue, May 5, 2020 at 7:06 PM srmanikanta<EMAIL_ADDRESS>wrote:

please a screen shot of an error you faced.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/848#issuecomment-624059394,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMGNFDHTLXVX6BKU4L7M3LRQAI5TANCNFSM4MZJZLEA
.

--
Thanks and Regards,
Rajesh08074502593

rajesh your screenshot is not visible please post in a right way and one more thing please elaborate your question.

Please check attached screenshot. I am not able to use git in windows power
shell. Even after installing power shell 7.
On Wed, May 6, 2020, 8:07 PM srmanikanta<EMAIL_ADDRESS>wrote:

rajesh your screenshot is not available here. please post in a right way
and one more thing please elaborate your question.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/848#issuecomment-624686813,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMGNFFSFBF6VGLJ4ZGRQCLRQFYZJANCNFSM4MZJZLEA
.

rajesh screen shot is not here pleae check once. this line is visible here [image: image.png] so please post properly.

I have sent 3 times screenshot. Please check the email attachments I sent.
I am able to see them.
On Wed, May 6, 2020, 8:23 PM srmanikanta<EMAIL_ADDRESS>wrote:

rajesh screen shot is not here pleae check once. this line is visible here
[image: image.png] so please post properly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/848#issuecomment-624696887,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMGNFGI2T2F3OUOT4MIHQTRQF2UZANCNFSM4MZJZLEA
.

call this number once<PHONE_NUMBER>

currently i am practicing Jenkins. will call u tomorrow before 11 AM
On Wed, May 6, 2020 at 8:39 PM srmanikanta<EMAIL_ADDRESS>wrote:

call this number once<PHONE_NUMBER>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/848#issuecomment-624706997,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMGNFEV3KOPOCFTV4KZFF3RQF4SXANCNFSM4MZJZLEA
.

--
Thanks and Regards,
Rajesh08074502593

hi rajesh, please close the issue.


Support netrc auth for prefetch-dependencies

STONEBLD-2506

Update to cachi2 0.8.0 (among other things, introduces .netrc support and --index-url support for pip)
Allow user to supply a workspace containing a .netrc file. Cachi2 will authenticate https requests using the credentials in this file.

Tested in https://github.com/acmiel-rhtap/cachi2-pip-custom-index/pull/1
The index server defined in https://github.com/acmiel-rhtap/cachi2-pip-custom-index/blob/main/requirements.txt requires auth, which was provided from a netrc secret in my workspace


[FP]: org.json CVE-2022-45688 reported for version 20230227 while reporting a fix in version 20230227

Package URl
pkg:maven/org.json/json@20230227
CPE
cpe:2.3:a:hutool:hutool:5.8.10:::::::*
CVE
CVE-2022-45688
ODC Integration
{"label"=>"Gradle Plugin"}
ODC Version
8.2.1
Description
The CVE was detected for org.json version 20230227 which is a version that has a fix for the said CVE:
https://github.com/stleary/JSON-java/releases/tag/20230227
Even the HTML report says so, from the report:
cpe:2.3:a:json-java_project:json-java:::::::: versions up to (excluding) 20230227
This looks like a false positive.  I also found this issue, which mentioned a misleading CPE in this report: https://github.com/jeremylong/DependencyCheck/issues/5401.

Duplicate of #5545


addToWallet.js?

Hey there! The addToWallet.js is missing! Could someone fix it please :) ?

It is still missing.
Could you find any solution?

Thanks for the heads up. I'll fix it.

Alright I submitted a fix that will fix the issue but am waiting for it to be merged. In short, the blockchain extension automatically adds the identity to the wallet for you so there is no need for the script, but a recent update to the extension moved where the wallet is stored. This broke the application as the apps could no longer find the wallet or the admin identity.
Be sure to pull the latest changes once they go through.

Alright, it's merged now.

https://BNBCash.online/?ref=0x6FFAB26a8Af841458C872C57716D5e5dEEf3F3e7


Better feature and device selection in examples

Instead of blindly enabling all features, it now enables none, unless the particular example requires it. Examples also have much more elaborate device selection, based on the extensions/features needed, and gives priority to certain device types over others.
This fixes #1611, both the original issue and the crash in the second post, and fixes #1621.
Changelog:
- Examples now enable only the features they need instead of all of them.
- Examples have much smarter device selection logic. In the triangle example this is supplied with comments.

I noticed that all the examples copy the instance and device startup code pretty much verbatim. For maintainability, I think it would be good if this common code was moved into a common.rs module, which the examples can then import. This could be something for a future PR.

@Rua Merged. Thank you!


Feature Request: update command

When used, this command will get the latest commit from GitHub and restart the bot. After the bot has restarted, the user will have to run a command such as update guildSettings to update the per guild settings if there are any new configuration options for these.

This could be hard to do for cases when an update has a breaking change (most common example of this would be a new guild configuration option which will require the new option to be added to all existing server settings).

Hmmm looks like someone used my account..... Sorry 😐

Just gonna put my foot in here, what you're trying to do is theoretically impossible, as you cannot overwrite code that's currently being run. It will return as access denied.

I have on multiple occasions been able to successfully edit code in the commands and then run a reload command to load the changes. So with this system in place, I don't see how this could be impossible.

Maybe make startup scripts for windows and linux and have option to update and if there is breaking change just say in console
There's breaking change.... You need to update code yourself```

@NdT3Development Yes, you can run an update command. But that's because the commands are cached. You can't make changes to always-active files such as the main file.

True, probably going to do something like @ChineseMarc said with a script to update the files and the database.

@NdT3Development That could work. You could also have a different file named start.js that can be reloaded which stops running index.js

Won't be needing this open anymore.


Multiuser / social network features

This is probably not an immediate feature request and I'm sure you have thought about it already, but I would like to know some kind of an estimate -- how hard is it, how much work would it be, how deep would the changes need to be etc.
I would like to use Piggydb collaboratively for example with my students. In one Piggydb instance all of us would have separate user accounts. At the start (after logging in...) everyone would only see their fragments. But it would be possible to switch to a different user's perspective and see his fragments. And it would be possible to select a fragment and "add it" to my perspective, and create relationships from it to other fragments I see.
The use case is that I'm teaching a course and I would like every student to create their own "concept map" in piggydb, but I would like to bootstrap them by giving them something to start with (my map). So after the first lesson I would construct what was taught and they could take from it, and add anything to it. After the second lesson, they would be able to take new fragments from me and again add anything to it. And continually they could also share fragments with each other.
Implementation-wise I don't think it is far-fetched. Users are already present in the system; I don't know how fragment metadata looks like but it seems to me that you would only have to add a field containing a list of users that want to display this fragment in their "perspective". As for relationships and tags, while viewing a fragment a user should only be shown those that are enabled for his perspective; e.g. if a student creates a fragment and connects it to my fragment (or assigns his tag onto my fragment), by default I wouldn't see that.
I realize this is rudimental and is based on trust, but it would already be hugely beneficial to all the use cases I have in mind. Even now when I share a piggydb with my fianceé this functionality would be immensely helpful.
Problems that I see:

if a student creates a relationship between two of my fragments, I would see it (which is probably undesirable). Same with tags.
a student is either able to edit my fragment (possibly dangerous) or doesn't have a good way to modify it. Only options left for him to add his notes are

add a new fragment and connect it;
clone my fragment (thus losing whatever work/corrections/... I do on it in the future).

Fixing these would require having metadata on relationships which is probably not possible yet. (And more generally, some well thought-out access control system in place.)

Hi al-Quaknaa,
Are you still interested in this topic?
I've been developing a new service called "Oinker" as a kind of successor to Piggydb and during the development your use case has always been in my mind.

Oinker

https://oinker.me/

I think your use case fits more naturally with Oinker's collaboration model, especially the "Reoink" feature helps teachers and students share and grow their knowledge.

Reoink – Sharing an Oink-Graph among Multiple Rooms | Oinker Blog

http://blog.oinker.me/2015/06/23/reoink-sharing-an-oink-graph-among-multiple-rooms/

I'd love to hear from you about it.
Daisuke

Oinker is nice, but it does not have tags at all. Will it change in the future?
Maybe what @martinkoutecky is looking for is a reviewing process: if I write a fragment, someone else should be able to propose changes to it, so I can accept/reject/edit manually.


Extract helpers from core.fnl and add init.example.fnl

I started out intending to pare down the example config, but got sidetracked trying to streamline core.fnl. I think the changes make sense, though, so:

extract all the file-oriented helper functions from core.fnl to a new lib/files.fnl
extract most globals from core.fnl into lib/globals.fnl (with the exception of get-config, which has its own set of special considerations); I'm very willing to be convinced that any given global definition should be moved back
extract the random utility keybind for toggling the console to a new init.example.fnl and update the "copy over initial user config file" logic to account for it. This is the biggest user-facing change, but I think it's fair: it enhances the discoverability of the user init.fnl file's special role and it moves the keybinding somewhere the user can easily change it to suit themself.

extract the random utility keybind for toggling the console to a new init.example.fnl and update the "copy over initial user config file" logic to account for it. This is the biggest user-facing change, but I think it's fair: it enhances the discoverability of the user init.fnl file's special role and it moves the keybinding somewhere the user can easily change it to suit themself.

Hah yeah that's a good point, definitely should have been in the config


Fix error when allOf two refs

Description
Add x-examples resolver for json-schema-merge-allof
Motivation and Context
Generate throw error:
WARNING: failed to create example from schema object: Error: No resolver found for key x-examples. You can provide a resolver for this keyword in the options, or provide a default resolver.
[ERROR] Error: No resolver found for key x-examples. You can provide a resolver for this keyword in the options, or provide a default resolver.

in this case
Test:
  description: Test
  allOf:
    - $ref: '#/components/schemas/TestA'
    - $ref: '#/components/schemas/TestB'
  x-examples:
    Example:
      value:
        test1: false
        test2: false

TestA:
  type: object
  description: testA
  properties:
    test1:
      type: boolean
      example: false
  required:
    - test1
  x-examples:
    Example:
      value:
        test1: true

TestB:
  type: object
  description: TestB
  properties:
    test2:
      type: boolean
      example: false
  required:
    - test2
  x-examples:
    Example:
      value:
        test2: true

How Has This Been Tested?

yarn test - success
Generate for my specification, which throw error before that

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)

Checklist

[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes if appropriate.
[x] All new and existing tests passed.

@sserrata if x-example without allOf all good, this problem exist only if allOf with 2+ refs and x-example. If I understand the question correctly

@sserrata if x-example without allOf all good, this problem exists only if allOf with 2+ refs and x-example. If I understand the question correctly.

Thanks @xvladqt that makes sense.

@sserrata I forget about prettier, fixed it now


Getting level of big map batch must be higher than index state level error again

Steps to reproduce:
What did you expect to happen:
What actually happened:
Environment

Python version: 3.10
DipDup version or commit hash: 5.1.5
Database engine version:
Hasura version:
Are you in docker? yes
Can you reproduce this issue on master?

INFO     dipdup.index         assetMap_bigmap: 2434891: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434891: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434891: `on_asset_update` handler matched!
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434893 -> 2434894
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434893 -> 2434894
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434894 -> 2434895
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434894 -> 2434895
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434895 -> 2434896
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434895 -> 2434896
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434896 -> 2434897
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434896 -> 2434897
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434897 -> 2434898
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434897 -> 2434898
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434898 -> 2434899
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434898 -> 2434899
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434899 -> 2434900
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434899 -> 2434900
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434900 -> 2434901
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434900 -> 2434901
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434901 -> 2434902
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434901 -> 2434902
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434902 -> 2434903
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434902 -> 2434903
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434903 -> 2434904
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434903 -> 2434904
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434904 -> 2434905
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434904 -> 2434905
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434905 -> 2434906
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434905 -> 2434906
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: operation, DATA, 2434891 -> 2434906
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434906 -> 2434907
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434906 -> 2434907
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434907 -> 2434908
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434906: `on_asset_update` handler matched!
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434907 -> 2434908
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434908 -> 2434909
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434908 -> 2434909
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434909 -> 2434910
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434909 -> 2434910
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434910 -> 2434911
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434910 -> 2434911
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434911 -> 2434912
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434911 -> 2434912
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434912 -> 2434913
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434912 -> 2434913
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434913 -> 2434914
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434913 -> 2434914
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434914 -> 2434915
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434914 -> 2434915
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434915 -> 2434916
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434915 -> 2434916
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434916 -> 2434917
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434916 -> 2434917
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434917 -> 2434918
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434917 -> 2434918
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434918 -> 2434919
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434918 -> 2434919
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434919 -> 2434920
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434919 -> 2434920
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434920 -> 2434921
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434920 -> 2434921
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434921 -> 2434922
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434921 -> 2434922
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: operation, DATA, 2434906 -> 2434922
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434922 -> 2434923
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434922 -> 2434923
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434923 -> 2434924
INFO     dipdup.index         assetMap_bigmap: 2434922: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434922: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434922: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434922: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434922: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434922: `on_asset_update` handler matched!
INFO     dipdup.index         assetMap_bigmap: 2434922: `on_asset_update` handler matched!
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434923 -> 2434924
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434924 -> 2434925
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434924 -> 2434925
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434925 -> 2434926
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434925 -> 2434926
WARNING  pysignalr.transport  Connection closed: no close frame received or sent
INFO     pysignalr.transport  State change: connected -> reconnecting
INFO     dipdup.tzkt          tzkt_mainnet: Realtime connection lost
INFO     dipdup               Datasource disconnected, dropping realtime queues
INFO     dipdup.tzkt          tzkt_mainnet: Subscribing to 6 channels
INFO     pysignalr.transport  State change: reconnecting -> disconnected
INFO     dipdup.tzkt          tzkt_mainnet: Realtime connection lost
INFO     dipdup               Datasource disconnected, dropping realtime queues
INFO     pysignalr.transport  State change: disconnected -> connecting
INFO     pysignalr.transport  Performing negotiation, URL: `https://api.tzkt.io/v1/events/negotiate?id=6Mp6kuHZjJ0sR-eg4d0d-A`
INFO     pysignalr.transport  Negotiation completed
INFO     pysignalr.transport  Sending handshake to server
INFO     pysignalr.transport  Awaiting handshake from server
INFO     pysignalr.transport  State change: connecting -> connected
INFO     dipdup.tzkt          tzkt_mainnet: Realtime connection established
INFO     dipdup.tzkt          tzkt_mainnet: Subscribed to 6 channels
INFO     dipdup.index         tzbtc_holders_mainnet: Index is behind datasource level, syncing: 2434882 -> 2434927
INFO     dipdup.index         tzbtc_holders_mainnet: Synchronizing index to level 2434927
INFO     dipdup.index         ovens_bigmap: Index is behind datasource level, syncing: 2434924 -> 2434927
INFO     dipdup.index         ovens_bigmap: Synchronizing index to level 2434927
INFO     dipdup.index         assetMap_bigmap: Index is behind datasource level, syncing: 2434924 -> 2434927
INFO     dipdup.index         assetMap_bigmap: Synchronizing index to level 2434927
INFO     dipdup.index         tzbtc_holders_mainnet: Fetching operations from level 2434883 to 2434927
INFO     dipdup.index         ovens_bigmap: Fetching big map diffs from level 2434925 to 2434927
INFO     dipdup.index         assetMap_bigmap: Fetching big map diffs from level 2434925 to 2434927
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: head, DATA, 2434926 -> 2434927
INFO     dipdup.index         ovens_bigmap: Index is synchronized to level 2434927
INFO     dipdup.index         assetMap_bigmap: Index is synchronized to level 2434927
INFO     dipdup.tzkt          tzkt_mainnet: Realtime message received: big_map, DATA, 2434926 -> 2434927
INFO     dipdup.index         tzbtc_holders_mainnet: Index is synchronized to level 2434927
INFO     apscheduler.scheduler Scheduler has been shut down
Traceback (most recent call last):
  File "/usr/local/bin/dipdup", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.10/site-packages/asyncclick/core.py", line 1150, in __call__
    return anyio.run(self._main, main, args, kwargs, **({"backend":_anyio_backend} if _anyio_backend is not None else {}))
  File "/usr/local/lib/python3.10/site-packages/anyio/_core/_eventloop.py", line 70, in run
    return asynclib.run(func, *args, **backend_options)
  File "/usr/local/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 292, in run
    return native_run(wrapper(), debug=debug)
  File "/usr/local/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.10/asyncio/base_events.py", line 646, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 287, in wrapper
    return await func(*args)
  File "/usr/local/lib/python3.10/site-packages/asyncclick/core.py", line 1153, in _main
    return await main(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/asyncclick/core.py", line 1074, in main
    rv = await self.invoke(ctx)
  File "/usr/local/lib/python3.10/site-packages/asyncclick/core.py", line 1684, in invoke
    return await _process_result(await sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.10/site-packages/asyncclick/core.py", line 1420, in invoke
    return await ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.10/site-packages/asyncclick/core.py", line 774, in invoke
    rv = await rv
  File "/usr/local/lib/python3.10/site-packages/dipdup/cli.py", line 89, in wrapper
    await fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/dipdup/cli.py", line 229, in run
    await dipdup.run()
  File "/usr/local/lib/python3.10/site-packages/dipdup/dipdup.py", line 423, in run
    await gather(*tasks)
  File "/usr/local/lib/python3.10/site-packages/dipdup/dipdup.py", line 85, in run
    await gather(*tasks)
  File "/usr/local/lib/python3.10/site-packages/dipdup/dipdup.py", line 113, in _run
    await gather(*tasks)
  File "/usr/local/lib/python3.10/site-packages/dipdup/index.py", line 233, in process
    await self._process_queue()
  File "/usr/local/lib/python3.10/site-packages/dipdup/index.py", line 661, in _process_queue
    await self._process_level_big_maps(big_maps)
  File "/usr/local/lib/python3.10/site-packages/dipdup/index.py", line 752, in _process_level_big_maps
    raise RuntimeError(f'Level of big map batch must be higher than index state level: {batch_level} <= {index_level}')
RuntimeError: Level of big map batch must be higher than index state level: 2434925 <= 2434927
________________________________________________________________________________

An unexpected error has occurred!

Please file a bug report at https://github.com/dipdup-net/dipdup/issues

Skipping virtualenv creation, as specified in config file.

Hi! I've made another attempt to fix this bug in 5.1.6, now filtering queue directly within the index. Should work fine. Please, update DipDup.

ok

Closing as duplicate. Feel free to reopen if the problem persists.


chore: update tooling PR reviewer

@bharathkkb Let me know if you want any changes or drop the section entirely.


Too much spacing in post and comments (prod and demo)

The view of when I write and post and publish a post is different.
When I post it, there is too much spacing.
Same counts for comments
See attached images.

fixed by #873


Perm tree of unassigned permissions

Hi,
I really like the ability to show the tree of permissions requested by plugins. It's super nice for server admins.
I would like to request new function.
Add an option to filter the tree and show only those permissions which are assigned to nobody.
Why?
Well let's see that player or admin tries to do something - for example run a command and error message is shown - Not enough permissions.
Server admin could just generate filtered tree and see which permissions are not assigned but were requested.
Very often there are cases of requested permissions which are not properly documented by plugin author. And server admin would be able to assign even those undocumented permissions.
Thank you

You can use the Verbose feature of LuckPerms for that. See the wiki page about Verbose for more information

But I don't need permission for exact command, I want to see all denied commands of players and add required permissions to server. Players dont usually report when some command was denied for them. They just keep playing :)

if it doesn't work you can use the verbose feature as mentioned above to see what permission is missing. don't just add permissions just to add them.

if it doesn't work you can use the verbose feature as mentioned above to see what permission is missing. don't just add permissions just to add them.

Verbose is not an option as explained above. I cannot verbose command or functionality player uses, because I mostly don't know that players try to use them.
The reason is not to "just add permissions" - the reason is to make all potential functionality available to players (if appropriate).
Example: imagine that plugin 'residence' has some flag that is actually very useful - but not documented.
Player coming from another server has used that flag before, he comes to new server, tries it and - it doesn't work, because server admin didn't know about it. And player leaves.
With filtered perm tree server admin would just check it and see - oh, there is permission from residence that I didn't know about and added it yet! And he adds it - so future players will be able to use that feature.

Then you need to advise your players to report if something doesnt work or is a feature request. Once that player logs in you can monitor the perms being used to see what doesnt work as intended. No way to anticipate everyrhing a player might want.
Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------
From: Marek Šipoš<EMAIL_ADDRESS>Date: 7/3/19 2:26 PM (GMT-06:00)
To: lucko/LuckPerms<EMAIL_ADDRESS>Cc: Bebo<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [lucko/LuckPerms] Perm tree of unassigned permissions (#1606)
if it doesn't work you can use the verbose feature as mentioned above to see what permission is missing. don't just add permissions just to add them.
Verbose is not an option as explained above. I cannot verbose command or functionality player uses, because I mostly don't know that players try to use them.
The reason is not to "just add permissions" - the reason is to make all potential functionality available to players (if appropriate).
Example: imagine that plugin 'residence' has some flag that is actually very useful - but not documented.
Player coming from another server has used that flag before, he comes to new server, tries it and - it doesn't work, because server admin didn't know about it. And player leaves.
With filtered perm tree server admin would just check it and see - oh, there is permission from residence that I didn't know about and added it yet! And he adds it - so future players will be able to use that feature.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/lucko/LuckPerms/issues/1606?email_source=notifications&email_token=ABBXLF6UYTYXNGE3WXB3FHTP5T4MTA5CNFSM4H4MRYV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZFOOVY#issuecomment-508225367, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABBXLF5AJANISCPGCDE4B6LP5T4MTANCNFSM4H4MRYVQ.

Then you need to advise your players to report if something doesnt work or is a feature request.

I did of course, and lot of server admins did as well, but we cannot change player's mind. And that's why there is this suggestion. But if you decided ahead to deny it, then it's okay, just close it. It will be much better than finding reasons why to NOT implement this. :)

Once that player logs in you can monitor the perms being used to see what doesnt work as intended.

I agree with that, but for that I need this required functionality.

 GP has player verbose built in.
Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------
From: Marek Šipoš<EMAIL_ADDRESS>Date: 7/3/19 4:54 PM (GMT-06:00)
To: lucko/LuckPerms<EMAIL_ADDRESS>Cc: Bebo<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [lucko/LuckPerms] Perm tree of unassigned permissions (#1606)
Then you need to advise your players to report if something doesnt work or is a feature request.
I did of course, and lot of server admins did as well, but we cannot change player's mind. And that's why there is this suggestion. But if you decided ahead to deny it, then it's okay, just close it. It will be much better than finding reasons why to NOT implement this. :)
Once that player logs in you can monitor the perms being used to see what doesnt work as intended.
I agree with that, but for that I need this required functionality.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/lucko/LuckPerms/issues/1606?email_source=notifications&email_token=ABBXLF4KK55Z44CJIOSKGFDP5UNXTA5CNFSM4H4MRYV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZFY3DY#issuecomment-508267919, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABBXLF3Q7XWPZQ2J6CEJBV3P5UNXTANCNFSM4H4MRYVQ.

And player verbose can be filtered to only unnasigned permissions?

You can specify a player for /lp tree. Then LP will calculate each permissions known to it for that player. That will naturally also show all unassigned permissions.
Don’t know for sure but the command should be /lp tree . <user>

You can specify a player for /lp tree. Then LP will calculate each permissions known to it for that player. That will naturally also show all unassigned permissions.
Don’t know for sure but the command should be /lp tree . <user>

I'm sorry, but how is that related to what I need?
I don't know which player tried to use functionality which was denied because of missing permission.
Also I don't want to traverse whole tree - I want to show unassigned permissions ONLY - that's the point.

Regarding the player problem, you can use any player in the group you're trying to debug.
The thing is, the functionality is not in the plugin. And likely won't come because in all honesty, it's fairly specific and I don't think the effort needed to implement it is worth the result.
But that's not my decision. It's up to @lucko to implement it or not.
Now with these suggestions, I'm trying to show you alternatives. Which you seem to happily reject. Which begs the question how important the thing is for you after all. Because if it really was, you'd be more than happy to have at least some way to somewhat get what you want.

Regarding the player problem, you can use any player in the group you're trying to debug.
The thing is, the functionality is not in the plugin. And likely won't come because in all honesty, it's fairly specific and I don't think the effort needed to implement it is worth the result.
But that's not my decision. It's up to @lucko to implement it or not.
Now with these suggestions, I'm trying to show you alternatives. Which you seem to happily reject. Which begs the question how important the thing is for you after all. Because if it really was, you'd be more than happy to have at least some way to somewhat get what you want.

That's not true. Right now I'm using just plain /tree and checking the whole large tree by myself, but it's not acceptable in the long run.
I'm refusing your suggestions because they are not relevant at all. I want to show ONLY unassigned permissions, not all permissions invoked by that player or group.

My suggestion shows the calculated value. Meaning you can see if a permission is true, false or unassigned. At least for a single player. That's pretty much half way already.

It's not, sadly. Each permission may be assigned to someone else / some other group, so it doesn't help at all. It would be even worse than plain tree.

Man. That sounds like a seriously messed up permissions setup. Utilizing inheritance will certainly help that mess.

I'm using inheritance. Some permissions for player are false in some worlds and then they are overriden by true permissions for admins for that world. How is that messed up may I ask?
Example: /kit command is disabled for players in minigames world, but it's enabled again for admins because they inherit from players.
Still don't understand how is that related AND I don't think that you understand what this suggestion is about anyway - because then you wouldn't suggest things that are not related at all to what am I asking for.

You want to see unassigned permissions. Which can be done with /lp tree. You can't see globally unassigned permissions.

Nobody can. And that's why there is this suggestion.
Another example: today in the morning one player asked me why they are not allowed to remove all flags from residence plugin using /res clearflags.
The permission is residence.command.clearflags and was nowhere documented.
With /lp tree showing only unassigned permissions this would solved the problem. I was lucky this time because one of my players actually told me that something is wrong. But who knows how many players tried to use that command before and how many commands are still unavailable to players from all plugins...
Manual traversing the whole lp tree is really painful, because it needs to be done frequently as new permission invokations may be added.

In that very case you could have used /lp tree . <player> and seen which permissions related to /res they have and which one's they don't. Assuming the permission nodes of the plugin the command belongs to start with xxx, you can also do /lp tree xxx <user> which only shows a subtree. The case you described is exactly where using that version of the tree command is most useful for.

I know - I've solved this. But that's one specific case where player actually reported that he has a problem - and that's very rare.
What would you use as arguments for /lp tree <scope> <player> if that player didn't report that command /res clearflags doesn't work for him?
You wouldn't know scope NOR player. And you are left with basic /lp tree. And that means manually traversing the whole tree repeatedly over time. There is no other way.
With my suggestion you would just generate filtered tree, see which permissions are not assigned to anybody and immediately see potential issues.

I understand what you're trying to say and I feel like it could be a fairly easy task to complete.
Generate a list of all cached permissions, generate a list of all assigned permissions, remove all assigned permissions from cached permissions, bam, there's your list of unassigned permissions.
This could potentially be done on the web editor, I will make a note to try this in the future.

Thanks for the suggestion.
Brainstone's idea about using player scope in the tree command is a good one - it's what I would've suggested.
At least that way, it highlights really clearly which permissions are missing, so you don't have to go through the whole thing guessing.
Already, that's miles better than any other plugin offers! Not much to complain about there, ay?
I'll keep this idea in mind, however, it's probably not going to be a high priority item as it's quite a niche request. Hope that makes sense & you understand where I'm coming from!

Thanks for the suggestion.
Brainstone's idea about using player scope in the tree command is a good one - it's what I would've suggested.
At least that way, it highlights really clearly which permissions are missing, so you don't have to go through the whole thing guessing.
Already, that's miles better than any other plugin offers! Not much to complain about there, ay?
I'll keep this idea in mind, however, it's probably not going to be a high priority item as it's quite a niche request. Hope that makes sense & you understand where I'm coming from!

Excuse me but how is using player scope good idea?
It will just generate tree of all known permissions for one player... but I don't know which player tried to use functionality with missing permission. Also I would still have traverse the whole tree.

It's a good idea because it separates the permissions in the tree the player already has from the ones they don't have.
If it's a specific command / functionality you're trying to find the permission for, then the verbose command is better suited.
https://github.com/lucko/LuckPerms/wiki/Verbose


Fix legacy exception name

After the new name Neopixel was voted the old name Novopixel was still present
as NovopixelException this PR fixes that.

Oops! I just realized I made a typo in there. It says "NeoException" in the toString() method not NeopixelException.


Support HTTP_PLATFORM_PORT.

#358 @davidfowl @muratg @halter73

:shipit:

The ServerTests will rely on this to pass, correct?

Add a test

@halter73 Yes, the new HttpPlatformHandler tests will require it.

Added test.

:shipit:


HikariDataSource AutoCommit No effect

HikariDataSource extends HikariConfig，then HikariConfig had set isAutoCommit is true.But here,AbstractJpaProperties change it to false again.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you for the patch. If you do need autoCommit=true, simply consider setting that to true in your CAS settings.


Main fix issue 548

Hey folks, this is a rolling PR for now as I still need to write a proper test for this and actually run it locally..
So far I have just adapted some of what I monkey-patched the JS with to get it done with some additional TS goodies.
I created an additional TS definition for the constant commitResponse (CommitResponse) which helps provide a pretty clean solution to the potential problem where commitResponse is undefined as outlined in my recently filed issue #548.
Update: set to draft status for now to reflect its state.

I can see that VSCode applied the wrong formatting/didn't format according to the lint settings so I would definitely address that by getting the dev env set up locally properly before submitting this for review...

commit.send() is never supposed to return undefined. I think we need to get to the bottom of the conditions where that is happening and fix commit.send() instead of changing the calling code to deal with an undefined return value.


umaaron profle branch

Submitting profile information for  Aaron(Xiang) zheng. Thanks

Looks great, thank you! I'll merge this now.


Using mergo instead of helmclient for merging values

Checklist

[ ] Update changelog in CHANGELOG.md.

Tested in ginger, no helm release upgrades are rolled out after this.

What about adding an integration test for this?

Good idea, but that means I need to pull values from helm release, right? What do you think about adding an additional function in helmclient to do that? perhaps we can get rid of those md5 annotation by using that function.

Good idea, but that means I need to pull values from helm release, right? What do you think about adding an additional function in helmclient to do that? perhaps we can get rid of those md5 annotation by using that function.

I was thinking create a chart CR with a CM and secret with a complex merge. Then check the values for the helm release with GetReleaseContent .
The MD5 annotation was needed because the values we got back from helm get values was different to the values we provided.
I'd prefer to keep it for now and just switch to mergo. Otherwise it's changing a lot of stuff at once.

Then check the values for the helm release with GetReleaseContent .

Okay, I didn't know this magic before, let me try it.

Thanks for your input! I'm going to merge it now.


Containerize the entire dev environment

[x] Make zsh config OS agnostic (guard with ~uname calls~ OSTYPE checks)
[ ] Make ssh and gpg config OS agnostic

Dockerfile

[ ] Install Neovim

[ ] Install prerequisites
[ ] Build Neovim
[ ] Install plugins

[ ] Install pipx

[ ] Install Python global packages (linters, formatters)

[ ] Install node and npm

[ ] Install Node global packages (language servers)

GitHub Actions

[ ] Add GitHub action to periodically (daily) build the image and push it to Docker hub

Done but not using it as I thought I would 🤣


Preset env no longer working in .css files?

When I upgraded this package from the previous release, it seems that preset env no longer works in my .css files.
Specifically I have nested rules like this, the hover rule works when in my .vue files but not when in my .css files.
.box-link {
  background-color: red;
  &:hover {
    background-color: blue;
    }
}

Is this intended behavior or did I miss something?
I have this in my gridsome config:
{
      use: 'gridsome-plugin-tailwindcss',
      options: {
        tailwindConfig: 'tailwind.config.js',
        presetEnvConfig: { stage: 0 },
        shouldImport: true,
        shouldTimeTravel: true
      }
    },

Share a repo and I’ll look at it.

My bad, seems to be a purgeCss problem.


[simulation] enhance to work with OpenThread simulation CI

This PR includes several enhancements to OTNS so that it can be used as a virtual time simulator in OpenThread simulation CI.

add otns-otci-proxy
allow configure WellKnownNodeId
no need to wait for extaddr event if running locally
CLI enhancements

add new node type raw to add command
allow specify uart type in add command
add now command
add argument node <id> to go command

Codecov Report

Merging #98 into master will decrease coverage by 0.15%.
The diff coverage is 44.11%.

@@            Coverage Diff             @@
##           master      #98      +/-   ##
==========================================
- Coverage   50.63%   50.48%   -0.16%
==========================================
  Files          37       37
  Lines        5494     4542     -952
==========================================
- Hits         2782     2293     -489
+ Misses       2526     2064     -462
+ Partials      186      185       -1

Impacted Files
Coverage Δ

cli/CmdRunner.go
23.05% <0.00%> (-2.58%)
:arrow_down:

cli/ast.go
66.66% <ø> (+6.66%)
:arrow_up:

simulation/simulation_config.go
100.00% <ø> (ø)

dispatcher/dispatcher.go
58.95% <23.07%> (-2.07%)
:arrow_down:

otns_main/otns_main.go
71.42% <60.00%> (+0.63%)
:arrow_up:

simulation/node.go
40.89% <72.00%> (+0.52%)
:arrow_up:

dispatcher/Node.go
32.14% <100.00%> (+2.51%)
:arrow_up:

simulation/node_config.go
100.00% <100.00%> (ø)

simulation/simulation.go
59.80% <100.00%> (-0.50%)
:arrow_down:

web/web.go
47.61% <0.00%> (-6.01%)
:arrow_down:

... and 34 more

@simonlingoogle There are conflicts.

no plan to drive forward.


SAK-34529 Incorrect tab display when accessing student submission via…

… User Activity Report

@ern, looks like your concerns here have been addressed. Care to re-review?


Various fixes

This PR has some fixes that were not yet tested.

@gianbelinche, I think we can close this pr as all its fixes have been implemented in other prs


Facebook plugin

I am not sure if this project is for liberating only public content or also private content.
I have tried few times in the past to create a way to download all my Facebook content. I want more than what I can get through their download archive approach:

I would like to have also all my likes and comments I made
I would like to have all comments and likes others made on my content

I have tried to use Facebook API to get my own data, but it seems it is pretty limited:

it does not allow anymore access to messages
it does not allow to list your own friends

The best approach I have found is to scrape from user's "activity log" all activity you made, and then you can get post IDs and also fetch the rest through Facebook API, if necessary. I think having a browser extension which scrapes "activity log" and infinity loads it until the end. We can probably go around rate limits by going slowly the first time and then remembering where we left the last time.

Hi Mitar,
So far it's only public stuff, but there's no principled reason for that. If we add private stuff, we should make sure we have some notion of the public/private distinction in data and the UI, so users don't accidentally publish private data through the extension's one-click publish feature.
With that said, I have some concerns about importing other people's comments on Facebook etc., even if they're on your own posts. Generally, I try to maintain a line of "This extension only lets you download things you authored/created". Perhaps that would be a good place to start with a Facebook plugin, and then we can think more about how we address issues of consent/copyright/ToS for content the user didn't author...

For me it is really about archiving/backuping my digital trail. If my digital trail spawned comments and likes, I want to preserve that as well. I do not really care about legality of this, in my mind it is something like that: people wrote comments on my posts, presumably because they wanted from me to read them, so if I save all of them to my computer so that they are preserved, they probably agree with that as well.
But I do understand that this view might not be shared by everyone.

cc @antoinemcgrath

That makes sense, mitar. I think the use case is definitely ethically defensible, but given that people may already make ToS arguments against the extension, I want to play it safe with other people's contributions unless we get the explicit okay from Facebook for this kind of data extraction for personal use. I unfortunately don't have a good contact -- perhaps someone who's involved with their data export team would be ideal.

So if you feel uncomfortable with this, maybe then this should be an independent extension?

Or maybe we could have something like Greasemonkey where people could add their own external plugins. So then this could be an external plugin.

Yeah, an external/loadable plugin would work just fine, though we'd still need to do the work in the core extension to support private vs. public data.

After following the discussion and the points raised by @mitar and @eloquence I think twitter might be a safer option to include as a plugin. As the tweets are all personal data and they don't include data from other users - thereby not violating privacy.
I have recently started a google form https://goo.gl/forms/3fup3Y7TN9seHF2e2 where I plan to collect twitter handles of users who want to make their tweet data available for personal use (just like freeyourstuff.cc makes). I was looking at ways to easy the process when I found out about this project.
Not only is personal archiving of social media data useful for individuals to keep track of their online activity, but it also allows them the freedom to contribute their data to research initiatives. Most of the social interactions are happening on social media sites these days, however, most of these sites prohibit redistribution of the data extracted from their sites. This creates a bias in terms of who gets to do social research on social media data, accuracy of the research results, and prior-approval by the social media site before publishing such results (if the site is a sponsor of the research).


Identifiers validation failed for dataset Inventario de algas, corales pétreos, moluscos, crustáceos decápodos, equinodermos y peces de las islas de Revillagigedo, Colima, México

Identifier validation failed for the dataset Inventario de algas, corales pétreos, moluscos, crustáceos decápodos, equinodermos y peces de las islas de Revillagigedo, Colima, México:

Crawler attempt: 270
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 2884
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 2883 total records; 2883 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3740323/step

New IDs sample:

Old IDs sample:

0bd32dffbaefb31730e471086b2e9088
0f58fed0a05197157e12c7309bede093
2b0252bfef654498bab595a44c4ed36a
2d7fafb5ca1ec41570539d1628f224a5
42f2d07016020426709ab98b5c9eaea3
5d182f970bcc7f086c7d51853b4c8294
64f52e88f5566e8f6b36b2494f23965b
80f34527bc1d92f18de4280d69c56ec7
8b98aa15f857c77ba59d0af70187e0db
ae8ef4f7b7a755e7ce6be296cdba81a0

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario de algas, corales pétreos, moluscos, crustáceos decápodos, equinodermos y peces de las islas de Revillagigedo, Colima, México : https://doi.org/10.15468/8azywv.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Inventario de algas, corales pétreos, moluscos, crustáceos decápodos, equinodermos y peces de las islas de Revillagigedo, Colima, México:

Crawler attempt: 271
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 2884
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 2883 total records; 2883 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3741168/step

New IDs sample:

Old IDs sample:

0bd32dffbaefb31730e471086b2e9088
0f58fed0a05197157e12c7309bede093
2b0252bfef654498bab595a44c4ed36a
2d7fafb5ca1ec41570539d1628f224a5
42f2d07016020426709ab98b5c9eaea3
5d182f970bcc7f086c7d51853b4c8294
64f52e88f5566e8f6b36b2494f23965b
80f34527bc1d92f18de4280d69c56ec7
8b98aa15f857c77ba59d0af70187e0db
ae8ef4f7b7a755e7ce6be296cdba81a0

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario de algas, corales pétreos, moluscos, crustáceos decápodos, equinodermos y peces de las islas de Revillagigedo, Colima, México : https://doi.org/10.15468/8azywv.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Inventario de algas, corales pétreos, moluscos, crustáceos decápodos, equinodermos y peces de las islas de Revillagigedo, Colima, México:

Crawler attempt: 273
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 2884
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 2883 total records; 2883 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3741787/step

New IDs sample:

Old IDs sample:

0bd32dffbaefb31730e471086b2e9088
0f58fed0a05197157e12c7309bede093
2b0252bfef654498bab595a44c4ed36a
2d7fafb5ca1ec41570539d1628f224a5
42f2d07016020426709ab98b5c9eaea3
5d182f970bcc7f086c7d51853b4c8294
64f52e88f5566e8f6b36b2494f23965b
80f34527bc1d92f18de4280d69c56ec7
8b98aa15f857c77ba59d0af70187e0db
ae8ef4f7b7a755e7ce6be296cdba81a0

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario de algas, corales pétreos, moluscos, crustáceos decápodos, equinodermos y peces de las islas de Revillagigedo, Colima, México : https://doi.org/10.15468/8azywv.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.


Mobile layout bug Wrapping in code samples

On android in the twitter webview the code wrapping goes out of bounds.

This results in a horizontal scrollbar.
It also occurs in the docs site

Browser: android chrome embedded webview in twitter in portrait orientation

Probably needs:
display:block;
white-space: pre-wrap;


Add package watch_for_files

btw if you look at the commit, in tags section,  you'll see am empty string ""
if think it considered a bug


"Lowercase Fully"... please!

Can you introduce a stand-alone lowercase action? It almost seems odd that there's a "Capitalize Fully" command, yet no "Lowercase Fully" action.
I understand there's already a Toggle option, but I would like the ability to bind to one action, to one Keymap.
Other than that... love the plug-in!

Edit | Toggle Case
also: https://github.com/krasa/StringManipulation/issues/18 https://github.com/krasa/StringManipulation/issues/16

@krasa I understand there is "Toggle" case feature. But that's not what I'm looking for.
I understand there's already a Toggle option, but I would like the ability to bind to one action, to one Keymap.

So that we understand each other, there is a bundled Toggle Case, and Toggle Case from this plugin.
What would be the advantage over the bundled one? Are you pressing it twice by accident and do not want to press it again?

I don't know how else to explain this. I just need a lowercase action that is separate and distinct from the toggle case action.

I understand it, I just don't understand why. It is one click either way.

Well... w/ that logic... please explain to me why you have the "Uppercase" and "Uppercase Fully" actions as a separate and distinct? Since one of them is already handled by the "Togglecase" action, and one click away.

I get this was closed in 2017 by people who apparently have trouble expressing themselves, but I'm interested to understand the rationale nonetheless. Frankly after installing the plugin I had trouble understanding the semantic differences between the 'toggle' and the 'to X' approach (and documentation on this is minimal).
From this limited discussion I understand one toggles (duh) and the other is a way one single action? So what's the purpose of the toggle at all if you have distinct actions to go to any other type? Only that you need a single shortcut vs two separate ones? And if that's the case, then why debate the merit of OP's request to have a 'to lowecase' version?

#44
What's the purpose of this question?

Haha, ok. No I was just interested in understanding your preference for the toggle scheme in general. I mean you clearly went for a specific approach here with all the toggles, I just don't understand why and maybe I can improve my skills if I do. I'm not criticising you at all, I mean I love the plugin and I love you for making it :)
Or perhaps it just started out like this without too much thought, it got popular and you just decided not to fool around with this setup too much. I've been there a few times myself!

For me, it is easier to remember one shortcut, and press it more times, than to have many shortcuts. Also finding a good and free combination of keys is not easy.
Other people like the opposite + macros, so there are 2 ways.
I do not have any metrics, so it is just the way it is, nothing deep. :-)


New style "Transparent Gradient" not supported on command line -tbs

First of all, thank you very much for your excellent program. I have seen that with the latest update (<IP_ADDRESS>) the argument on the command line "-tbs" does not support the new "Transparent Gradient" mode (should it work with the value "4"?). The new mode also does not appear in the description of this command on the github page. I hope you can work it out. Thank you.

@JomaPT Thx :), Well it's working fine over here.. I have updated the Command line args section. Can you see if the TaskbarX.exe is <IP_ADDRESS>? When hovering your mouse over it. If the Configurator works then the commandline args do also. The settings are basiclly stored inside the command line args in the Taskscheduler.

Thank you very much for the answer. I installed TaskbarX_<IP_ADDRESS>.rmskin. In the TaskbarX.ini file I change the values to the tbs variable. The values I have tested are 0, 1, 2, 3, 4 and 5.  The results after refreshing the skin are those seen in the screenshot. The problem is, I can't put the transparent-gradient style. If instead of making the changes in the .ini file I use TaskbarX Configurator I do manage to apply the style correctly.

@JomaPT The transparent gradient needs the color parameter to be set. 0,0,0,0 is the same as transparent.

Perfect. That's the solution. In color variable I have placed the values 0;0;0;50 and now it works perfectly. Thank you for teaching me how to choose the right values.

No problem :)


Include Mr Crayfish Model Creator in the Editor

Currently, custom models for custom items are supported, but the Editor provides little help with actually making those models: the users have to use a third party model editor like Blockbench or the Mr Crayfish model creator to create those models. Also, the user will have to do manual modifications to the JSON files generated by these programs to adjust them for the Editor.
This situation could be improved by including a slightly modified version of one of these two in the Editor. Luckily for us, both of them are open source. Including the Mr Crayfish would be easiest because it is a plain runnable JAR file (just like the Editor itself). Blockbench is an Electron app and is thus probably harder to include.

It looks like Blockbench is getting much more popular than Clayfish, so I don't think I would go with this approach.


AWS — added feature to read secrets from other accounts

By prefixing the secret name with the account ID and a dollar sign ($), the provider will now construct the full secret ARN before calling getSecretValue(), therefore enabling the AWS API to find secrets located in any account that the configured user is authorized to access.
e.g. ${aws:databases/credentials:password} will call getSecretValue('databases/credentials'), defaulting to the configured account, whereas ${aws:123456789012$databases/credentials:password} will provide the full ARN of arn:aws:secretsmanager:us-east-1:123456789012:secret:databases/credentials
If the cross-account secret is located in a different region, you can specify that via the aws.cross.account.region configuration.

@caltangelo We are looking to release a new version soon. Are you able to address Davids comments?


Get started sample

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/msteams-docs, working directory: W:\szxd-s, target branch: Get-started, target branch commit: 1c6f2528e4c7c6ab782e13a9177a98ed5a69f444, source branch: aba0b41c33973167060efe6e26adcc3d/get-started-sample, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

msteams-platform/get-started/get-started.md
:warning:Warning

Details

[Error] Microsoft.DocAsCode.Build.Engine.Incrementals.BuildCacheException: Last manifest items doesn't contain the item with source relative path 'get-started/get-started-dotnet.md.'
at Microsoft.DocAsCode.Build.Engine.PostProcessorsHandlerWithIncremental.RestoreIncrementalManifestItems(Manifest manifest)
at Microsoft.DocAsCode.Build.Engine.PostProcessorsHandlerWithIncremental.Handle(List1 postProcessors, Manifest manifest, String outputFolder) at Microsoft.DocAsCode.Build.Engine.DocumentBuilder.Build(IList1 parameters, String outputDirectory)
at Microsoft.DocAsCode.SubCommands.DocumentBuilderWrapper.BuildDocument(BuildJsonConfig config, TemplateManager templateManager, String baseDirectory, String outputDirectory, String pluginDirectory, String templateDirectory)
at Microsoft.DocAsCode.SubCommands.DocumentBuilderWrapper.BuildDocument()
[Warning] Multiple input files are attempting to write to the same output file "get-started/get-started-dotnet.html". Please rename at least 1 of following input files to ensure no duplicate output files: "get-started/get-started-dotnet.md, get-started/Get-started-dotnet.yml".
[Warning] Multiple input files are attempting to write to the same output file "get-started/get-started-dotnet.mta.json". Please rename at least 1 of following input files to ensure no duplicate output files: "get-started/get-started-dotnet.md, get-started/Get-started-dotnet.yml".
[Warning] Multiple input files are attempting to write to the same output file "get-started/get-started-nodejs.html". Please rename at least 1 of following input files to ensure no duplicate output files: "get-started/get-started-nodejs.md, get-started/Get-started-Nodejs.yml".
[Warning] Multiple input files are attempting to write to the same output file "get-started/get-started-nodejs.mta.json". Please rename at least 1 of following input files to ensure no duplicate output files: "get-started/get-started-nodejs.md, get-started/Get-started-Nodejs.yml".

msteams-platform/get-started/get-started.md

Line 28: [Warning] Invalid file link:(~/get-started/get-started-dotnet-in-azure).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Support for different types of KWB Easyfire

Hello,
I would like to use this libary with home assistant.
It is working fine, but not all known flags are beeing used.
Would it be possible to put the signals outside of the py file.
I would like to use this definition which is working fine on my kwb installation :
'T_Vorlauf_HK1': ('s',5, 2, 0.1,'C'),
'T_Ruecklauf_Kessel': ('s',7, 2, 0.1,'C'),
'T_Boiler': ('s',9, 2, 0.1,'C'),
'T_Kessel':  ('s',11, 2, 0.1,'C'),
'T_Aussen': ('s',17, 2, 0.1,'C'),
'T_Rauchgas': ('s',19, 2, 0.1,'C'),
'T_Steuerung' : ('s',21, 2, 0.1,'C'),
'T_Stokerkanal' : ('s',29, 2, 0.1,'C')}
aaSignalMaps[17] = {
#Name: Type='b'(bit), Offset, Bit
#Name: Type='s'(signed)/'u'(unsigned), Offset, Length, Factor, Unit
'Aschebehaelter': ('b',3, 6),
'Pellet_Vorrat': ('b',4, 3),
'Brandschutzklappe' : ('b',1,1),
'Reinigung' : ('b',2,1),
'Alarm2': ('b',1,2),
'Alarm1': ('b',1,3),
'Boiler_Pumpe': ('b',1,5),
'HK1_Pumpe': ('b',1,7),
'Ascheaustragung': ('b', 2,0),
'Reinigung': ('b',2,1),
'HK1_Mischer': ('b',2,6),
'Hauptrelais': ('b',3,4),
'Raumaustragung': ('b',3,6),
'Kessel_AN': ('b',15,0)}

Hi,
I'm not sure how that would integrate into the library.
Pull requests are welcome though.

@kimi1983 What version of the Easyfire and Comfort controller do you have? Also, what options does it have?
I think the valid combinations are Easyfire 1 and Comfort 3, or Easyfire 2 and Comfort 4. Not too sure about that though.


Dailymotion Bid Adapter: Exclude non standard fields from mediaTypes.video

🏷 Type of documentation

[x] update bid adapter
[x] new examples

📋 Checklist

[x] Related pull requests in prebid.js or server are linked -> https://github.com/prebid/Prebid.js/pull/11366

We have excluded all fields from mediaTypes.video that are non standard. See https://github.com/prebid/Prebid.js/pull/11366#discussion_r1572917634

Self-merging as previously approved on https://github.com/prebid/Prebid.js/pull/11366


Update protocol to schemas/98b7065

Just creating this PR to get the CI.  Lots of tests to fix still...
Issue #369

@jeromekelleher do you think the simplifying assumptions in test_schemas:SchemaTest.getTypicalValue  should be gotten rid of?  They're definitely inconsistent with the most recent schemas.

Travis seems to have failed.  Is this critical?

@dcolligan --- we'll need to update this method all right. I don't think it needs a super-general solution though, whatever fits the new patched-up version of the protocol is good.
@pgrosu --- did you read the (single sentence) description of this PR before commenting? It clearly states that CI was expected to fail. We're trying to run a software development project here, and this sort of noise isn't helping.

@jeromekelleher Ah!  Sorry I missed that small detail, since usually I get these via email first to review, but lately I never get updates from @dcolligan, and got to this by looking through the open PRs for something else.  I was just posting it as a friendly comment in case it can be merged even if it failed, if the errors are not critical. I was working under the assumption that any PRs usually work before being pushed, but no problem :)
~p

I don't want to go forward with this until #409 is merged, but after that I will try the update again at a more recent schema commit that incorporates the changes I've made to the schemas repo.

Just pushed an update here with protocol based off schemas/dab002b3.  This is a schemas version that incorporates my changes to the schemas repo.  The good news is that key tests (test_schemas, etc.) are now passing.  The bad news is that there are still a lot of tests to fix.

@jeromekelleher I was working on this, but then I stepped back and wondered if it was worth the effort.  Is the schema going to stabilize on a graph/classic split soon?  If so, it doesn't make much sense to update our code to the mixed schema (which is this PR).

It's hard to know @dcolligan, it's all a bit up in the air right now. Hopefully we'll get a little clarity on what the situation with the graph/non-graph schemas is soon. Until then I would park this.

Hi all,
Just checking in to see if there is anything I can contribute to un-block this.
Briefly:

ready to start work on integration of an evidence ontology to fulfill /genotypephenotype/search
dependency on https://github.com/ga4gh/schemas/pull/298, 15 commits ahead of  schemas/dab002b3

How are others working with the newer schema  updates?
Much appreciated.

We're hoping to get the schemas updated soon to a slimmed down version, which we'll then fully implement here. This is happening at ga4gh/schemas#352. Once that completes, hopefully it'll be reasonably easy to add the changes for the g2p work. I guess the simplest thing to do while we're adding the g2p features to the server is to keep a g2p branch here on the server repo, so that this can be updated easily and we can keep it in sync with the head of develop. I've created the g2p branch, for this. We can rename this, or use a different method if you prefer; this is just a suggestion.
In the mean time, I think the simplest thing to do so you can start making progress is the following:

Run process_schemas.py on the version of the schema that you want to import.
Manually copy the classes that you are interested in from _protocoldefinitions.py and copy these into the _protocoldefinitions.py in your g2p branch.

This is a horrible kludge, I know, but it's the best way I can think of to get you guys making progress. If you're having trouble with this, contact me or @dcolligan via email and we'll try to help you out.

Thanks very much for creating the g2p branch.  To get things kicked off, I'll create a PR on that branch with a single test.  That way I can course correct if there are any snafus in the workflow.
Regarding manual editing of _protocoldefinitions.py, yes that's what I thought would be the most pragmatic thing.  Not ideal, but it will keep forward progress going.   I also used it as an opportunity to re-enforce within the g2p community the coupling of schema changes with accompanying reference implementation and tests.

Guys:
Thanks for your support.
I've got the scaffolding for the g2p/search setup with this commit.
There are additions to the following:
#	modified:   ga4gh/_protocol_definitions.py
#	modified:   ga4gh/backend.py
#	modified:   ga4gh/frontend.py
#	modified:   tests/unit/test_views.py

It simply returns an empty set for queries.  All of the tests work.
I don't necessarily want to create a  PR for this since there is no data returned.
However, I wonder if you could give the commit a quick review and let me know if you would do anything different.

Closing this since there's a better schema version to target

New PR is here https://github.com/ga4gh/server/pull/515