text:
[RFC] Represent monolithic applications as components

Status: Open for comments

Need
The existing catalog model is well suited to microservice architectures, particularly when the as-yet-unimplemented System, Domain and Resource kinds are added in. However, not all architectures fit this neatly. For example:

Monolithic backend applications are common in the industry
Mobile applications are typically shipped as single, feature-rich artifacts

The distinctive features that require modelling in this case are:

Common runtime. Monolithic applications are deployed as a single unit, and share runtime behaviours (for instance, observability instrumentation, database connection pools, etc).
Complex structure. There may be no one 'good' way to divide up a monolith conceptually. It may expose several APIs; it may have distinct subsystems that operate as layers rather than 'slices'; it may have features that are not easily expressed as APIs; etc.
Complex ownership. As companies scale, understanding what team is responsible for what functionality in a large application becomes important.

Proposal
Implement application as a new type of Component. Application is apparently a concept internally in Spotify:

An application is a bundle of components that is packaged, released and operated as one unit. Compared to a system, an application might host components that belong to different systems or are owned by different teams in addition to its own components. Typical examples would be our mobile applications or the Backstage frontend.

The crucial change to the Component model will be the addition of new relationships - a Component may be part of another; a Component may contain many others. So a YAML may look like:
---
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: acme-ios
spec:
  type: application
---
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: acme-ios-telemetry
spec:
  type: service # or whatever
  partOf:
    - component:acme-ios
    - system:foo-bar

I've proposed a many to many relation here so a Component may also belong to a System - the semantics of the relationship are substantially the same.
Alternatives
Implement Application as a separate Kind. Rejected because most of the actual functionality we want is common with other components - ie, runtime information like error reports, dashboards, etc. Implementing as a new Kind would increase the complexity of plugins that wanted to support all sorts of running software.
Model as a type of System. Rejected because it semantically overloads System too drastically. A monolithic application may contain many systems, and indeed may contain parts of systems. See discussion on #3765.
Risks
The risk is that it's not actually a good fit for the applications it proposes to model and it will be difficult to change as and when the wider ecosystem adopts it. I don't see how you can manage this risk except by maintaining a humane deprecation policy with clear migration paths if changes are necessary.

See for sure the continuing discussion in #3765 that may tip the scales in favor of an Application kind after all, if we make sure to understand the implications.

I'm easy either way, delta my specific point above. Just thought it would be good to have something concrete to talk about.

Thanks for writing this up @tragiclifestories. I haven't really thought about it too much at this point, but I'm not entirely convinced that a separate Kind for applications is a bad idea. Maybe I'd rather do it this way:

Have certain plugins that are attached to application kinds, like mobile releases
If you need those plugins, you need to add an entity of that kind to the catalog. If you also want to link other components to it (so you can traverse from a component to its application, or inline some plugins on the component page), you'd need to annotate the component with the application it belongs to.

It's true that it might make it more complex for plugins that need to work for both components and applications though. How coupled are those things in the code at the moment? Like, would it be difficult to write a plugin that works for any entity in the catalog that has a given annotation?

@mbruggmann For a small single purpose app / webpage, would you represent it as only an Application, or as both and Application and a Component?
Enabling features/plugins has been done a lot with annotations so far. It won't make an overly large difference to enable them for more than one kind.

@freben Not sure. But I think it'd be convenient if in most cases, it's only a Component until we want to share a plugin across components in different systems (say, mobile releases). In which case we'd add an additional Application entity, and associate the existing component with the new application? That would allow you to move certain annotations from the Component to the Application, and with it, the plugins that make more sense in that scope?

It sounds to me like both components and applications could be the same thing. Most of the scenarios described, just shift responsibility of plugin features from a more specific part to a grouping of parts. Could both of these not just be Component kinds? An Application in this case is just a Component that is made up of other components and has had some plugin features transferred to it (eg CI/CD, Releases, etc.).

The alternative then, would be to make it an Application from the start - that will suddenly become one of the most common kinds. And it stays that way; Components mostly come into play when you feel the need to add the detail of multiple features inside it.
But then, is an SDK an Application? :) Etc. But that classifying problem applies for types too.

@andrewthauer Yep that rhymes well with my initial take and @mbruggmann's latest edit. Just want to taste the other approach for a bit before we reject it :)
So let's say we are a user that wants to start making a trading website.
We use the scaffolder. It leads to a website Component right? We name it stonks. People link to it in docs, make browser favorites, there are refs to it in the catalog, it cements itself. Then it grows and sprawls and teams are spun off to manage different subsystems.
Here's the point where I feel it's important that the original entity stays and has a similar role in the world. Reclassifying established entities is an expensive operation in an org. Therefore I think we should NOT put the owners in a position where they need to (1) remove the entity, (2) change its kind, (3) change its name, (4) change its purpose so much that its original intent is lost which leads to everybody wanting to link to the other one instead.
Therefore I propose that we make the original classification of an app or website "robust" and unchanging, in the face of monorepoization.
If we make a monorepo an "application" TYPE, do we lose the ability to discern between the original types website and service?

@andrewthauer Read your comment again - maybe that's exactly aligned with what you said? (I edited my comment a bit if you missed that last paragraph)

@mbruggmann obviously i would love to hear your take on that thought, and whether that aligns poorly with what you had in mind for the internal model

An SDK seems more like a library, which could be associated to other entities. It could very well encompass multiple services and APIs.
I'm not sure I'm too keen on the term Application for this. For me it implies something that is for end users. But what we are talking about to here is how to enable/disable certain features within backstage based on the composition of arbitrary things. The problem is each organization can structure and conceptualize how these fit together in different ways.
Not sure if this is relevant to this discussion, but some examples we have are:

Various micro frontends and an older monolithic frontend app that composes these. All are different repos, but need to be deployed as a single unit.
Mobile apps that are split by feature/product category. These don't necessarily map 1 to 1 in the web version exactly.
Services that are broken down into multiple packages and deployed as a separate unit
An older monolith that contains remnants of features in newer microservices.

Having flexibility in the model and also being able to de-couple the conceptual and physical representations of these is key I think.

@andrewthauer Do you feel that the simple partOf relation is enough for those listed examples? I think for a human they may be. If it were meant to like drive a CI/CD system it wouldn't be detailed enough, but that's not the goal.

I think partOf could work with all of them actually. All the examples except the micro frontends are single repos now so most existing plugins work fine modelling them as a single component. If partOf were introduced we could further break down some of these if we chose to. This would also help with associating the micro frontends to their parent web app. However things like releases or deploys would only be applicable to the parent web app.

@freben Another approach to robustness would be to rely more on systems, and making those the primary entry point for techdocs, urls, search, APIs etc. Because components will likely evolve quicker over time.
@andrewthauer Agree that some flexibility in the model is crucial. Maybe we can be stricter about the core entities (Components, APIs and Resources), while leaving the classifications/groupings (Systems, Domains, Applications, ...) for each organization to define as they see fit?

@freben Another approach to robustness would be to rely more on systems, and making those the primary entry point for techdocs, urls, search, APIs etc. Because components will likely evolve quicker over time.

That's a valid point. There's a bit of a mind shift for me to think of Systems as a more central thing.
Hm but the concern of making the unit of deployment and monitoring etc stable (especially if others key into it) still stands I think.

@andrewthauer Agree that some flexibility in the model is crucial. Maybe we can be stricter about the core entities (Components, APIs and Resources), while leaving the classifications/groupings (Systems, Domains, Applications, ...) for each organization to define as they see fit?

Maybe. However we encode a lot of best practices in how we do things I think, such as how we create our default templates and how plugins by default look at deployment units etc.

I think the point about persistent linking between entities is a good one - it hadn't occurred to me. But it's a problem with this sort of ontology that they tend to capture particular moments and getting from one state to another is sort of undefined behaviour. We should definitely bear it in mind when defining these core types.
For my purposes, not having an explicitly supported application type in the core model is probably alright? Since a quick'n'dirty plugin would do the job of making my lovely monolith discoverable with minimal effort.
But I think it might still be worth considering, simply for 'exhaustiveness' - ie, the point of adding support for subcomponents is to support monolithic applications of one sort or another, so we need some value or set of values that we can put in the type field other than service and friends. Plugins might extend that with, say, an ios-app type or whatever, in the same way that you could maybe have variants of service with platform specific behaviours (or whatever else). But in the core model you would have the fallback of the ultra-abstract, unopinionated application type.

Too many high level "Kinds" would be IMHO, confusing. The way I would approach is to provide the minimum set of building blocks as Kinds and allow organizations/users to put them together to build the model as they see fit.
The way I see it, a monolithic runtime is still a component, that falls possibly under a system. Each runtime feature / library can be components that are children of that system , with the "application" component depending on the features/libraries.
As for "partOf" relation, I wonder if we can achieve the same relation with the existing  "dependsOn" and "dependencyOf" relationships.
In the example of micro-frontends to a frontend, we can model the frontend end has "dependsOn" relationship with the micro-frontends.
Similarly, while it might theoretically be possible to run a micro-frontend by itself, I am doubtful, if they are deployable by themselves (standalone). In such a case (deployable), we can have a one-way link "dependsOn" rather than a 2 way link ( a weak link) to convey that a micro-frontend is a part of a frontend. In the case it isnt, a 2 way relationship will imply that they both need each other to be run together.
As for SDKs, a SDK might  be used by a lot of applications so in such cases a dependencyOf relationship from the sdk to the other components might not even make sense as there might be too many (making it a Directed acyclicl graph).
I think we have sufficient primitives to allow users to model their software ecosystem as they see fit. Rather, the confusion might be on ideas of how to use these primitives to model their software ecosystem. Perhaps this can be addressed by having docs  (Examples, User Guides etc) for users on how to model their domain to fit into backstage, rather than introducing a new relation or a Kind ?

Too many high level Kinds would be IMHO, confusing. My approach is to provide the minimum set of building blocks as Kinds and allow organizations/users to put them together to build the model as they see fit.

This is a nice way of putting it!
With the caveat that we as makers of Backstage want to hit the just right level of opinionated, where we supply enough clarity and functionality out of the box to be immediately useful - even powerful - while also permitting extensions to that model. The main reason for that baseline need, is that we want plugins made by entirely different third parties to be able to work well together. The catalog is a form of universal "API" across several domains. Inventing one's own kinds and types and annotations etc is great - but sometimes undermines interoperability because others won't understand your semantics. It's all a tradeoff.

The way I see it, a monolithic runtime is still a component, that possibly falls under a system. Each runtime feature / library can be components (with type: library, feature, etc) that are children of that system , with the application component depending on the features/libraries.

Let's see.

Like that?

As for partOf relation, I wonder if we can achieve the same relation with the existing dependsOn and dependencyOf relationships. My reasoning behind this is that even if the claim is that a feature/sub-component that is not a part of the application, but is still run in the common runtime, is sort of a dependency, as your runtime will not function as expected if this sub-component is missing (a connection pool that is a partOf runtime A => A has some sort of dependency on the pool, otherwise doesn't make sense to have a partOf relationship).

It's a balancing act between not having too many relation types, and risking things becoming muddled or colliding. Have too few, and you'll either get it linguistically unclear, or start getting tempted to add a "subtype" field to the dependency because purposes start overlapping :)
I guess that essentially, one could argue that the existence of a relation in and of itself is saying "dependency", and the type of relation is, well, the type. Are you saying that "type" could be omitted?
Another angle: As a yaml file writer, would you like a spec to look like the first or second example?
# specific
spec:
  system: mySystem
  domain: myDomain
# generic
spec:

I have a few other examples for why dependency is sufficient.

Let's look for counter examples too!

In the example of micro-frontends to a frontend, we can model the frontend end has "dependsOn" relationship with the micro-frontends.  Similarly, while it might theoretically be possible to run a micro-frontend by itself, I am doubtful, if they are ever deployable by themselves (standalone). In such a case (deployable), we can have a one-way link "dependsOn" rather than a 2 way link ( a weak link) to convey that a micro-frontend is a part of a frontend. In the case it isnt, a 2 way relationship will imply that they both need each other to be run together.

Fair regarding how one might look at their interrelation. However, we have so far considered relations to be meant to be two-way to allow clear traversal both in the user interface and as an API consumer. Maybe this one-way idea could be a sign that the semantics are stretched a bit?

SDKs: Components or applications that use SDKs do depend on them. So in this case, a dependsOn relationship makes more sense.

Yep. But do you mean specifically a situation where the SDK is in the same monorepo as the main user? But others outside the repo use the SDK as well I presume? Does that mean that you can't discern the difference between depending on the SDK based on usage, and depending on the SDK based on it being part of your actual codebase?
Could it be that the inside-the-same-repo semantics could be TWO relations (both partOf and dependsOn), but the external user just dependsOn it? Is that richness useful?

Another example is a  "Shopping Cart" feature, that is ChildOf of the "WebStore" system, but  "Webstore Application" has a dependsOn relationship with "Shopping Cart".  Both "ShoppingCart" and "Webstore Application" are children of "Webstore". If you want to be more nuanced you can have a "Shopping cart Tab" micro-frontend and a  "Shopping Cart backend" that implement "Shopping Cart" (dependsOn -> Shopping cart tab, shopping cart backend). I dont think a Shopping Cart feature itself would make sense, outside the content of the Webstore, so you might end up modeling the "Shopping Cart" as childOf "Webstore"

I think this slices things differently to what I'd expect - but maybe I'm misreading it.
To be clear, a system is an entirely different grouping dimension than the usage "grouping".
I would expect that if there is a shoppingCart System, then it would be a grouping of some backend, several frontend features, some (e.g.) Cassandra storage resource, some pubsub topics, some batch data pipelines that are used for financial reporting, a realtime data pipeline for fraud detection etc. They would be partOf that system, not childOf. Note how extremely diverse these entities are. It will be important to users to be able to see them collected as a unit, to understand how they relate and are owned, and to know if alerts/problems spread among them. This is a type of "umbrella" that I think has big implications and we care a lot that it's distinct and useful.
I don't know if a webApp System would have any relation to the shoppingCart System. It would be a kind of transitive dependency and we haven't looked at modelling that yet.
However components under these systems may relate.

If the shopping cart has a micro-frontend component in it, then the webstore may have a dependency on that one.
If the shopping cart frontend parts are like a plugin in the webstore, and importantly, if responsibility for that part lies on the team that owns the webstore, then maybe that webstoreCart component is actually inside the webstore system and depends on the shopping cart backend
If the shopping cart frontend code is more integrated in the webstore and hasn't yet gotten its own component, then then webstore itself may have a dependency on the shopping cart backend.

So it kinda depends. But I think of it in terms of partOf for component<->system, and dependsOn for component<->component here. I think both feel important and distinct.

I think we have sufficient primitives to allow users to model their software ecosystem as they see fit. Rather, the confusion might be on how to use these primitives to model their software ecosystem. Perhaps this can be addressed by having docs (Examples, User Guides etc) for users on how to model their domain to fit into backstage, rather than introducing a new relation or a Kind ?

Oh yes, docs are definitely in need of fleshing out over time, and we will. But the extending the model article does address some of these nuances.

And just to get it cleared, I think custom "types" of "Components" are possible , right ? I recall adding Components with custom "types" to the database , but the only limitation seemed to be that they dont seem to show up in the UI, because the UI only queries for components of type Services ( which potentially can be customized in later versions of the frontend)

Yep this is mentioned in the extending the model as one of the most low hanging fruits on offer - we expect this extension possibility to happen frequently.
The catalog currently shows all Component kind entities (regardless of type). That will become richer and more fleshed out soon.

Like that?

Yes, that is what I had in mind.

I would expect that if there is a shoppingCart System, then it would be a grouping of some backend, several frontend features, some (e.g.) Cassandra storage resource, some pubsub topics, some batch data pipelines that are used for financial reporting, a realtime data pipeline for fraud detection etc. They would be partOf that system, not childOf. Note how extremely diverse these entities are. It will be important to users to be able to see them collected as a unit, to understand how they relate and are owned, and to know if alerts/problems spread among them. This is a type of "umbrella" that I think has big implications and we care a lot that it's distinct and useful.

This is where I am not sure of whether dependsOn or partsOf is a better approach. For a shopping system, what is the level to which it is coupled to the fraud detection data pipeline ? Is it a hard dependency (aka , pipeline down => system down ) OR a severe issue but not a down time ? Maybe I might model the first one as dependsOn and the latter as a partsOf.
But I think as a platform/library, rather than second-guessing how people might model the system, it perhaps is better to provide them with the tools to create a different type of link.
There is a lot of ambiguity between a dependsOn and a partOf relationship, but at this moment we do not know for sure when to use what.
As a pragmatic approach, we can perhaps generate a new type of relationship for users (partsOf) and allow them to use it as they see fit.
I guess the problem might occur when a core plugin or component uses one certain relationship for a certain functionality and latter it is decided that this relationship has to be moved to the other.  Perhaps this can be solved by not using partOf to provide any functionality in the core plugins ?

For me, using dependsOn would introduce potentially confusing overloading there. Real-ish life example: we have an intwernal Ruby gem that does structured logging according to our favoured samples. Our monolith also some related layers for logging request data, job data, etc. I'm not sure I want to see both types of 'dependency' listed in one place. Also, maybe it's just I need to finish this coffee next to me, but I don't feel like I have a good intuition for which direction the arrows go between (in your example) the micro-frontends and the 'host' application, whereas it's very obvious in the case of partOf/parts (or, for that matter, parent and child).

Perhaps this can be solved by not using partOf to provide any functionality in the core plugins ?

This might be a good idea. It would allow us all to get started modelling and see if we push in the same direction and then in a future version of the catalog more opinionated approaches to this problem might build on that.
I think we're agreed that we want partOf anyway for component->system relationships, and merely not forbidding component-(partOf)->component would be sufficient support for work to start in the wider ecosystem.

I second the confusion.
Still leaning towards the "not forbidding" part at least being strengthened to "encouraging", and probably even settling entirely. This may be one place where being opinionated may help long term, is my thinking.
Consider this from the maintainer point of view:
We will have to update the well-known relations page with examples and instructions. It'll be hard to do that in a useful and clear way without having some direction for the relations and their use.
We will also have to update the descriptor format page with the corresponding spec fields that ultimately generate the relations. How will we do that while saying "this may generate some form of relation (which is the way that we want everybody to consume this info), but not sure which one"? :)
We will also want to put the actual relation-generating code in the BuiltinKindsEntityProcessor. Whatever we put in there will be VERY cemented and, while you could replace the processor with your own, it would be a pretty big thing to do (and to evolve with as things are added to the core one).
Not sure about the ergonomics of leaving this flexible, if you think about it from the angle of the large masses of adopting orgs.

I wonder if there's a little crosstalk going on here - I didn't take @GoWind to mean that we wouldn't process the specs into relation records in the core plugin, merely that building actual user-facing functionality around it could be left out (maybe I misread it myself). I think the latter could be at least deferred until later on and we can experiment a bit in the wider ecosystem.
I think I agree with you that the minimum viable core support would be to update the docs you mention, add the field(s) to the component spec and process the relations in the BuiltInKindsEntityProcessor (I've started toying around with that here FWIW).

I wonder if there's a little crosstalk going on here - I didn't take @GoWind to mean that we wouldn't process the specs into relation records in the core plugin, merely that building actual user-facing functionality around it could be left out (maybe I misread it myself). I think the latter could be at least deferred until later on and we can experiment a bit in the wider ecosystem.
I think I agree with you that the minimum viable core support would be to update the docs you mention, add the field(s) to the component spec and process the relations in the BuiltInKindsEntityProcessor (I've started toying around with that here FWIW).

We will also want to put the actual relation-generating code in the BuiltinKindsEntityProcessor. Whatever we put in there will be VERY cemented and, while you could replace the processor with your own, it would be a pretty big thing to do (and to evolve with as things are added to the core one).

Getting this right (or keeping this flexible) would be very important. Currently, I run into a lot of limitations with generating relations when I try to emit them myself as the HigherOrderOperations prevents Location Processors from emitting any relations in the Entity.
@tragiclifestories
My question was more along the lines of what EXACTLY is the distinction. between partOf and dependsOf/dependsOn would be, as I am still not 100% sure of when I would use the former vs the latter and is the extra relationship in the model justified.
If a new relationship were to be added, some opinionated rules might be involved in deciding what relationship it is.
But I think, since we haven't reached 1.0 yet, maybe it does make sense to allow the new relationship, gather concrete examples of how to use one vs the other and then decide on retaining both or having just one.

We will also want to put the actual relation-generating code in the BuiltinKindsEntityProcessor. Whatever we put in there will be VERY cemented and, while you could replace the processor with your own, it would be a pretty big thing to do (and to evolve with as things are added to the core one).

Getting this right (or keeping this flexible) would be very important. Currently, I run into a lot of limitations with generating relations when I try to emit them myself as the HigherOrderOperations prevents Location Processors from emitting any relations in the Entity.
@tragiclifestories
My question was more along the lines of what EXACTLY is the distinction. between partOf and dependsOf/dependsOn would be, as I am still not 100% sure of when I would use the former vs the latter and is the extra relationship in the model justified.
If a new relationship were to be added, some opinionated rules might be involved in deciding what relationship it is.
But I think, since we haven't reached 1.0 yet, maybe it does make sense to allow the new relationship, gather concrete examples of how to use one vs the other and then decide on retaining both or having just one.

@GoWind sorry for delay, thought I'd already replied but obviously not!
For me, something is part of something else if its whole existence is enclosed by the larger aggregate, whereas a dependency implies some kind of 'independent' existence. Examples:

Service A depends on Library B, since if that link was broken, Library B could equally well be included in any number of other Services. (Although we have a distinct relation type for API dependencies, I think they are closely analogous and I think especially consumesApi could be replaced by dependsOn more easily than the part/whole relations proposed here.)
Service* A is part of Monolith B, since it has no possible runtime existence apart from the monolithic deployment.
Service A is part of System B, since its existence is entirely unnecessary apart from the feature implemented by System B.

In my head, partOf is one-to-one per kind, ie, a Component should be part of at most one Component and/or at most one System, etc. I'm sure organisations will find that these rules must be bent now and again as they iterate towards a more 'rational' model.
@freben don't know if you'd have any other thoughts. I'd like to get moving on this really (got an MVP to build for alpha users), so if we could decide which relation pair to use I can get a PR in at least for the catalog backend and model parts pretty quickly. Frankly I can see a use case for having both these relations supported in the Component spec, but obviously we still need to hash out the nuances of what the differences are.
* leaving aside whether 'service' is the appropriate type for this.

@GoWind sorry for delay, thought I'd already replied but obviously not!
For me, something is part of something else if its whole existence is enclosed by the larger aggregate, whereas a dependency implies some kind of 'independent' existence. Examples:

Service A depends on Library B, since if that link was broken, Library B could equally well be included in any number of other Services. (Although we have a distinct relation type for API dependencies, I think they are closely analogous and I think especially consumesApi could be replaced by dependsOn more easily than the part/whole relations proposed here.)
Service* A is part of Monolith B, since it has no possible runtime existence apart from the monolithic deployment.
Service A is part of System B, since its existence is entirely unnecessary apart from the feature implemented by System B.

In my head, partOf is one-to-one per kind, ie, a Component should be part of at most one Component and/or at most one System, etc. I'm sure organisations will find that these rules must be bent now and again as they iterate towards a more 'rational' model.
@freben don't know if you'd have any other thoughts. I'd like to get moving on this really (got an MVP to build for alpha users), so if we could decide which relation pair to use I can get a PR in at least for the catalog backend and model parts pretty quickly. Frankly I can see a use case for having both these relations supported in the Component spec, but obviously we still need to hash out the nuances of what the differences are.
* leaving aside whether 'service' is the appropriate type for this.

I'm good, and in the camp of using partOf, and hasPart as the inverse. I'd be happy to review a contribution for it.
We are now more and more, as was noted above, essentially making relations significant as a [type, target.kind] tuple. The target kind affects what the relation "means" in a technical sense, even though it commonly doesn't affect what it means from a high level human interpretation standpoint. I think this important realization is part of the basis for making this one distinct from dependsOn.
Do note that related work is happening in https://github.com/backstage/backstage/pull/3957, which settles the partOf and hasPart relations, but in terms of component<->system, and system<->domain. It is likely that that PR lands very very shortly.

I'm good, and in the camp of using partOf, and hasPart as the inverse. I'd be happy to review a contribution for it.
We are now more and more, as was noted above, essentially making relations significant as a [type, target.kind] tuple. The target kind affects what the relation "means" in a technical sense, even though it commonly doesn't affect what it means from a high level human interpretation standpoint. I think this important realization is part of the basis for making this one distinct from dependsOn.
Do note that related work is happening in https://github.com/backstage/backstage/pull/3957, which settles the partOf and hasPart relations, but in terms of component<->system, and system<->domain. It is likely that that PR lands very very shortly.

Awesome - my branch I think is more or less ready to go so I'll tidy up and make sure it fits around #3957.

Awesome - my branch I think is more or less ready to go so I'll tidy up and make sure it fits around #3957.

@tragiclifestories

For me, something is part of something else if its whole existence is enclosed by the larger aggregate, whereas a dependency implies some kind of 'independent' existence. Examples:

This makes a lot of things clearer. Yes, partOf signifies a sort of non-independent existence/.
Now that I see it from this perspective, I am inclined to add this type of relationship to Backstage as well :)
As for consumesAPI, i think it is ok to have it as a defined relationship type as APIs are first class .

@tragiclifestories

For me, something is part of something else if its whole existence is enclosed by the larger aggregate, whereas a dependency implies some kind of 'independent' existence. Examples:

This makes a lot of things clearer. Yes, partOf signifies a sort of non-independent existence/.
Now that I see it from this perspective, I am inclined to add this type of relationship to Backstage as well :)
As for consumesAPI, i think it is ok to have it as a defined relationship type as APIs are first class .

As for consumesAPI, i think it is ok to have it as a defined relationship type as APIs are first class .

For sure - was just drawing the analogy there really.

As for consumesAPI, i think it is ok to have it as a defined relationship type as APIs are first class .

For sure - was just drawing the analogy there really.

And now #3957 is merged!

And now #3957 is merged!

Thanks you @tragiclifestories and everyone else that contributed to the discussion! I feel that with #3957 and #4031 merged we're ready to close this, with any followup e.g. UI changes being handled in new issues.
Happy to close it?

Thanks you @tragiclifestories and everyone else that contributed to the discussion! I feel that with #3957 and #4031 merged we're ready to close this, with any followup e.g. UI changes being handled in new issues.
Happy to close it?

Sure thing - thanks everyone for sharpening this up!

Sure thing - thanks everyone for sharpening this up!

authors: GoWind Rugvip andrewthauer freben mbruggmann tragiclifestories


text:
backend-app-api: move over logger and config implementations from backend-common

Hey, I just made a Pull Request!
Work towards #13083. This moves over everything needed for the config and logging services. I moved both of these at once since they're very intertwined.
Most of the logging service implementation is wrapped up in the WinstonLogger class, which implements the RootLoggerService, and has static methods for creation and various winston log formats.
For config the loadBackendConfig method has been moved over with the same options, but it now returns an object with a config property, as that was a pain point of the old implementation. The secret extraction needed for the log redactions has been wrapped up in a createConfigSecretEnumerator helper that loads the config schema and can then be used to scan config instances for secrets.
In order to implement redactions I added a new addRedactions method to the RootLoggerService interface, since there would otherwise be a circular dependency. This does mean we won't be able to configure the logging through config without additional mutating methods or the like, but perhaps that's alright. Flipping it around would also be quite awkward, since the config loading wants to log events related to remote configuration loading, although it might be worth considering? I'll probably give it a shot before we merge this to see what it feels like.
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Tried flipping around the config/logger dependency in https://github.com/backstage/backstage/pull/15688/commits/a419d2d9b991afee92a68c7d721578719ede772d, gotta say it seems a lot nicer to be able to configure logging through config, and not add the extra method to the root logger service interface. Had to resort to some console to make it work, but I think that's alright.

One note - doesn't backend-test-utils need a changeset also?

@benjdlambert skipped it to piggyback on the existing one

source: gharchive/pull-request

authors: Rugvip benjdlambert

repo: backstage/backstage

license_type: permissive

license_source: github-api


text:
Gerrit readUrl: Use gitilies if available

Current implementation of the Gerrit readUrl only supports fetching files from the tip of a branch. There are plenty of use cases where we need to reference other files in a Backstage context. This is the first part of supporting the use case in #22053.
Just as previously was done with the "readTree" implementation this makes readUrl fetch the file content from Gitiles (if configured).
The file content of a Gitiles url can be fetch by appending "?format=TEXT" to the url making it easy to support any type of urls without any need to parse the url to get a git reference that can be used with the Gerrit API.
Using the Gerrit REST API to make the readUrl more flexible would be complicated. First the Gitiles url must be parsed to determine the type of git reference it points to. Then depending on the type we either need to query the "changes" or "projects" API. To support "tags" we would first have to query the "tag api" to get the revision the tag is pointing to and from there look up the content.
Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

[X] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[X] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[X] All your commits have a Signed-off-by line in the message. (more info)

This will not work with markdown files. Back to the drawing board for a bit.


text:
Added RCHLO and MIDWAY new adopters.

Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

Welcome and thanks for adding yourselves to the adopters file! I noticed that non of the two websites work and I'm presented with this error message 😱

authors: jhaals marcosborges


text:
plugin(nexus-repository-manager): clean up

Hey, I just made a Pull Request!

Fix all warnings reported in report.api.md
remove unnecessary files

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Hi @awanlin , I'd appreciate it if you could review the changes! In particular I just wanted to check if exporting NexusRepositoryManager from index.ts is fine. Maybe @christoph-jerolimov or @schultzp2020 could also take a look?

Oh, for sure it's just that I find it hard to review these when potentially others who have a bit more context are also going to be taking a look.

Hi @awanlin, could you review and merge this pls?

If the export is removed then the following warning shows up in the api-report:
// Warning: (ae-forgotten-export) The symbol "NexusRepositoryManager" needs to be exported by the entry point index.d.ts //
It's because of this I think: https://github.com/backstage/community-plugins/pull/2084/files#diff-6c6e87ebc8943694293d1e48a59120777d26f2978a6020552d650cae5b50f9a1L27. So after thinking this through maybe we should be exporting NexusRepositoryManager as a type.

repo: backstage/community-plugins


text:
v1.19.0-next.0 version bump

Backstage release v1.19.0-next.0 has been published, this Pull Request contains the changes to upgrade to this new release
Please review the changelog before approving, there may be manual changes needed to enable new features:

Changelog: v1.19.0-next.0
Upgrade Helper: From 1.18.0-next.3 to 1.19.0-next.0

Created by Version Bump 6324429776

Closing in favor of v1.19.0-next.1

authors: awanlin backstage-service

repo: backstage/demo


text:
Kubernetes: Default CPU Requests

By default, kubernetes pods request 0.1 cores. Perhaps cowait should instead default to 0, relying on the user to set requests accordingly?

Cowait already requests 0 by default

Cowait already requests 0 by default

source: gharchive/issue

repo: backtick-se/cowait


text:
Do not flag top level describe in a shared example

Fixes #216.
These were my first 15min ever with cops and AST, hope this is somewhat functional and usable :)

Thanks for the help with this! I left one comment on other cases this should cover. I'm good to merge this after that :smile:

Thanks! 😀 I've updated the PR with the proposed use of SharedGroups::ALL, and also added some more specs, which should cover all cases.

Thanks @clupprich!

authors: backus clupprich

repo: backus/rubocop-rspec

license: mit

license_source: bigquery


text:
🛑 Stack Overflow is down

In 00f9ed4, Stack Overflow (https://stackoverflow.com) was down:

HTTP code: 503
Response time: 120 ms

Resolved: Stack Overflow is back up in 5328871.

repo: baddate/uptime-monitor

license: MIT


text:
Can't run the cucumber feature on Gitlab pipeline which works in local environment

Current behavior
Getting the below error while running the feature on gitlab pipeline
Error:
An error was thrown in your plugins file while executing the handler for the before:run event.
The error we received was:
TypeError: fs_1.promises.rm is not a function
at beforeRunHandler (/xxxxx/cypress-cucumber-test/node_modules/@badeball/cypress-cucumber-preprocessor/lib/add-cucumber-preprocessor-plugin.js:66:25)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
Desired behavior
As the set up is same on local environment, feature should execute in the same way on pipeline
Versions

Cypress version: 12.4.0
Preprocessor version: 15.1.2
Node version: v12.18.3
Browser: Electron 106 (headless)

I'm passing the run command as below in .gitlab.yml file :
npm run runFeatures
where package.json has scripts added with this configuration:
"runFeatures" : "./node_modules/.bin/cypress run --headless --spec cypress/e2e/features/**/*.feature"

Answered in FAQ.

Where in the FAQ?

repo: badeball/cypress-cucumber-preprocessor


text:
[Jenkins] Support for Jenkins plugin version

Closes #622
Added simple badge for Jenkins plugins: shows latest version published to Jenkins' repository (fetched from: https://updates.jenkins.io/update-center.actual.json).
This uses the URL format: /jenkins/plugin/v/:pluginId.:format
Created service-test cases and added under Version in try.html.
This is my first contribution here, so let me know if I need to change something.

Hi! Thanks for this.
This downloads a 1.2M file for every badge. Is there an endpoint with a smaller payload you can use to get the version data?

I'm not currently aware of another API/endpoint, but I'll check.

Unfortunately Jenkins' Update Center doesn't have a separate JSON API apart from the full list, but it does serve tabular HTML data:
so a (not so pretty) solution could be:
camp.route(/^\/jenkins\/plugin\/v\/([^\/]+)(?:\/(.+))?.(svg|png|gif|jpg|json)$/,
cache(function(data, match, sendBadge, request) {
  var pluginId = match[1];              // e.g. blueocean
  var versionPrefix = match[2] || '';   // e.g. 1.0.0
  var format = match[3];
  var options = {
    method: 'GET',
    headers: { 'Accept': 'text/html' },
    uri: 'https://updates.jenkins.io/download/plugins/' + pluginId
  };
  var badgeData = getBadgeData('plugin', data);
  request(options, function(err, res, data) {
    if (err != null) {
      badgeData.text[1] = 'inaccessible';
      sendBadge(format, badgeData);
      return;
    }
    try {
       // First row is a excess HTML + permalink to latest version,
       // last row is all the excess HTML.
      var versions = data.split("</tr>")
        .slice(1, -1)
        .map(function (row) {
          var cleaned = row.replace('\n', '');
          return cleaned.match(/^<tr>.*>(.*)<\/a>.*$/i)[1];
        });

      var version = versions.find(function(version){
        return version.indexOf(versionPrefix) === 0;
      });

      if (!version) {
        throw new Error('unknown version');
      }

      badgeData.text[1] = version;
      if (version === '0') {
        badgeData.colorscheme = 'orange';
      } else {
        badgeData.colorscheme = 'blue';
      }
      sendBadge(format, badgeData);
    } catch(e) {
      badgeData.text[1] = 'not found';
      sendBadge(format, badgeData);
    }
  });
}));

Which works but is still parsing HTML in JS and not from an official API, so its stability cannot be guaranteed (although, those plugin download pages have remained identical for quite some time now).
On the positive side, it is much smaller (few kB vs. 1.2MB).

Hmm, yea, parsing the HTML doesn't seem better.
I wish I had a better sense of the memory usage on the server. If we used regularUpdate we could just fetch it occasionally. It would keep the whole thing in memory, though that seems like a better bet than fetching it each time.

I'll try using the regularUpdate (didn't even notice that earlier), and I could just map the JSON to a simple:
var versions = {
  plugin1: '0.1.0',
  plugin2: '1.1.0'
};

if memory usage is a concern. That way it wouldn't need to retain the whole, massive Object in memory.
Is there a recommended caching period? Is 1 day too long?

Simplifying the object down is a great idea!

Is there a recommended caching period? Is 1 day too long?

I'd probably lean toward more like 1 hour. If someone publishes a change they might want to see a change sooner than that even, but a day is a very long time to wait.

@paulmelnikow: I switched to regularUpdate with a 1 hour cache (should be acceptable considering Jenkins usually only publishes plugin updates once a day), and it is indeed much better. I parsed the original JSON to the format described above, so it shouldn't really use any considerable amount of memory.
I had to switch all tests to use mocked data as they would otherwise timeout constantly (the original payload is so big).
I also added the orange colouring for alpha and beta versions.

Excellent!
I think it would be good to include a test that hits the real service. There's an open PR MarkHerhold/IcedFrisby#71 to allow overriding the timeout on a case-by-case basis. Since that isn't merged yet, maybe you could add the test and comment it out?
Temporarily while you're testing, you could override Mocha's global timeout.
mocha.setup({ timeout: 10000 });

The two tests that should hit the actual API, consistently go over 10s each, and even 20s quite regularly. Is something like a 30s timeout even reasonable?

Ooph, well that's not great, though I think it's okay. Really glad we're caching these!
If it's taking that long and Jenkins only updates once a day, maybe we should set our timeout to something longer, like 4 hours.

Hey, I just wanted to follow up on this. Since Jenkins only updates once a day, should we set our timeout to something longer, like 4 hours? As an alternative to a test with a 30 second timeout, you could add a test with a small example in a fixture, using intercept().

Yeah, sorry for taking so long, I'll set the timeout to 4 hours (seems reasonable even for couple-of-times-a-day releases).
For intercept, I'm not sure what you mean? Do you mean mocking out the backend (instead of increasing the test timeout unreasonably high), like what I've currently done in this PR?

My bad, I realize you are already using .intercept(). Let's leave it at that for now.
If we start getting reports that these are failing, let's add a slow test that pulls the real data, so that we find out about the problems first.

Thanks!

authors: mikkopiu paulmelnikow

repo: badges/shields


text:
fix [Packagist] Version service test

Fixes #5702

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @calebcartwright!

  Generated by :no_entry_sign: dangerJS against 617f9b9ac76e0a0268424abaee08d2c81b5b0fef

authors: calebcartwright shields-ci


text:
deprecate [criterion] service

https://criterion.dev/ is gone
https://github.com/chmoder/criterion.dev is archived
bin time :wastebasket:

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @chris48s!

  Generated by :no_entry_sign: dangerJS against a8d38937ad3b8793e0bed22d0fceaaa16c946c24


text:
Not working when app is built.

Using Nextjs version 11.1.2.
After building the app the progress bar is not visible.
It is installed as a regular dependency not as a dev dependency

Do you have an example repository or site that demonstrates the problem?

One thing worth noting is the delay option described here. The option controls how many milliseconds the page is given time to load before the progress bar is shown. By default it's 80 milliseconds.
So, if the progress bar is visible for you in the dev mode, but not in your built app, the reason might be because your built pages are loading so fast that the progress bar is not shown. You can try setting the delay value to 0, but please note that even then the bar won't be shown for "instant" page loads (e.g. pages from the browser cache or preloaded when the mouse cursor is hovered over a link).

Yes, got it

repo: badrap/bar-of-progress


text:
Getting exception on frontend after updating meta data.

Bug report
Title
Getting exception on frontend after updating meta data.
Issue Description
Getting exception on frontend after updating meta data.
Preconditions
1. framework Version- master

Steps to reproduce
1. step1- Go to velocity grid and in meta data section add images and update it.
2. step2- Go to frontend.

Expected result
Home page should display.
Actual result

Fixed

This Bug occurs again on version 1.1.0

Hi @jestainternetsolutions
Could you please mention reproduce steps.
In which section of advertisement images(one,two,,three) you are getting this issue.
Also mention your php version.

@vaishaliwebkul
Running on PHP 7.2.19
The problem occurs on all sections
Steps to reproduce

Navigate to Velocity => Meta data => images
Add images to one of the sections
Save the changes
Open front-end (then the changes are vissible)
Navigate to Velocity => Meta data => images (now there are no images in none of the sections)
Add images to another section
Save the changes
On this point all previous settiings are overwritten

https://www.loom.com/share/d321953cb37c4d5ca466415ea00aa4c7

@vaishaliwebkul can you give us an update on this issue?

@jestainternetsolutions
As I have checked exception is not occurs right now, instead of the actual issue is advertisement images are not saved in the asset.
This issue will fix soon OR by tomorrow.
Thanks.

@jestainternetsolutions
Now Issue has been fixed in master.
Take pull from the master branch and check again.

repo: bagisto/bagisto


text:
Incorrect slot time for one booking many days in product page

Bug report
Title
Error on slot time for one booking many product in product page
Issue Description
Error on slot time for one booking many products in the product page
Preconditions
1. framework Version- master

Steps to reproduce
1. step1- add slot time in one booking many days
2. step2- select the slot from the product page, time always is 12:00 to 12:00

Expected result

time slot should be correct in product page which is entered by admin

Actual result

Fixed


text:
Guest coupon code cannot be used for general users

Guest coupon code shows 'Coupon code is invalid.' after using for general user.

Hi @ymymym
select 'guest' group in cart rule to allow coupons for guest users.
https://prnt.sc/t0ukei
https://prnt.sc/t0ukoj

Hi @vaishaliwebkul ,
Thanks for replying. Try to log in an account and apply the coupon code again.

@ymymym
for login user, the coupon code will work if a customer group or cart rule group should be matched.
Feel free to ask any query!
Thanks

authors: vaishaliwebkul ymymym


text:
compare feature is not working properly if admin creates a image type attribute and give attribute code and name "image"

Bug report
Title
compare feature is not working properly if admin creates a image type attribute and give attribute code and name "image"
Issue Description
if image type attribute has created by admin named as image then in compare list, in place of that image which is uploaded for image attribute,its showing product image
Preconditions
1. framework Version. Master

Steps to reproduce
1. step1: create a image type attribute make sure name and code should be image
2. step2: then add that attribute to family and create product upload any image for that attribute as well as upload product image

Expected result
actual image should be displayed for that attribute in compare list
Actual result
https://prnt.sc/ti8y3p
https://prnt.sc/ti8yyt

Duplicate issue https://github.com/bagisto/bagisto/issues/3495

@vaishaliwebkul
Both are different issues

@vishal-webkul
the bug is not resolved yet, in both case if image attribute code is 'image' type as well as if simple image type attribute is also not visible, it's showing as a link https://prnt.sc/tugok3

@rahulcs0082
please check the size of the images in compare list

fixed in both case when attribute have image code attribute as well as random code https://prnt.sc/txa0b8

authors: bhanu-webkul vaishaliwebkul


text:
Trying to get property of non object.

Please how do I solve this bug?
trying to get property 'default_locale' of non-object.
This is located in bagisto/packages/webkul/shop/src/http/middleware/locale.php file, in line
44
[app()->setLocale(core()->getDefaultChannel()->default_locale->code);]
Please help.
My LORD JESUS CHRIST Bless you. Hoping you believe In HIM.

@JESUDAWN
have you tried to changed the default locale??
Please open the shop again in incognito browser and then check.

@vaishaliwebkul i think that this is indeed happening when you enable any other currency and disable US dollar

@ghermans
Yes currency change will reproduce this error to as discussed https://github.com/bagisto/bagisto/issues/3038

@JESUDAWN
have you tried to changed the default locale??
Please open the shop again in incognito browser and then check.

I tried, but I don't even understand what to do and how to.
Thanks

@JESUDAWN
could you please show the screenshot of your error? also go to channels-> and share the screenshot of the currency section.

@JESUDAWN
could you please show the screenshot of your error? also go to channels-> and share the screenshot of the currency section.

Am not with my laptop now I 'II send it later, however even with my Android phone am having error too.
Warning: mysqli::close(): Couldn't fetch mysqli in /data/data/com.termux/files/home/bagisto/public/installer/install.php on line 67
Warning: Cannot modify header information - headers already sent by (output started at /data/data/com.termux/files/home/bagisto/public/installer/install.php:67) in /data/data/com.termux/files/home/bagisto/public/index.php on line 16
Fatal error: Uncaught Error: Class 'Illuminate\Foundation\Application' not found in /data/data/com.termux/files/home/bagisto/bootstrap/app.php:14 Stack trace: #0 /data/data/com.termux/files/home/bagisto/public/index.php(57): require_once() #1 /data/data/com.termux/files/home/bagisto/server.php(21): require_once('/data/data/com....') #2 {main} thrown in /data/data/com.termux/files/home/bagisto/bootstrap/app.php on line 14

@vaishaliwebkul

@ghermans
for now, the error will be gone when selecting all the currency from the currencies box.
Still, this should be resolved.

See attached screenshot and snapped shot from my phone and laptop
respectively.
Blessed morning from my LORD JESUS CHRIST.
On Fri, Sep 25, 2020, 9:14 AM Vaishali Agarwal notifications@github.com
wrote:

@JESUDAWN https://github.com/JESUDAWN
could you please show the screenshot of your error? also go to
channels-> and share the screenshot of the currency section.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bagisto/bagisto/issues/3967#issuecomment-698791439,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQE6XK36FZDWJLSAMNC2FEDSHRGNTANCNFSM4RY3NGYQ
.

I didn't. It exactly the way it came I installed it.
However, can you please show me what to do. Am a newbie to programming .
On Sat, Sep 26, 2020, 11:56 AM Glenn Hermans notifications@github.com
wrote:

Reopened #3967 https://github.com/bagisto/bagisto/issues/3967.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/bagisto/bagisto/issues/3967#event-3810674871, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AQE6XK2S6WZDHCWBOEULRW3SHXCFJANCNFSM4RY3NGYQ
.

@JESUDAWN this is a known issue and will be resolved.

Ok, patiently waiting
On Sat, Sep 26, 2020, 4:40 PM Glenn Hermans notifications@github.com
wrote:

@JESUDAWN https://github.com/JESUDAWN this is a known issue and will be
resolved.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bagisto/bagisto/issues/3967#issuecomment-699511643,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQE6XK5MM4M7MZUVGYXHQS3SHYDPNANCNFSM4RY3NGYQ
.

@JESUDAWN
this bug is fixed now, please check
Feel free to reopen the issue if still not resolved,

Bonjour,
J'ai un problème similaire :
Notice: Trying to get property 'language' of non-object in D:\Dureau\Local\Shop\classes\controller\Controller.php on line 196
Fatal error: Uncaught Error: Call to a member function getLocale() on null in D:\Dureau\Local\Shop\classes\controller\Controller.php:196 Stack trace: #0 D:\Dureau\Local\Shop\classes\controller\FrontController.php(283): ControllerCore->init() #1 D:\Dureau\Local\Shop\modules\everpsquotation\controllers\front\validation.php(40): FrontControllerCore->init() #2 D:\Dureau\Local\Shop\classes\controller\Controller.php(287): EverpsquotationValidationModuleFrontController->init() #3 D:\Dureau\Local\Shop\classes\Dispatcher.php(518): ControllerCore->run() #4 D:\Dureau\Local\Shop\index.php(28): DispatcherCore->dispatch() #5 {main} thrown in D:\Dureau\Local\Shop\classes\controller\Controller.php on line 196
Voici le Controller.php
         $localeRepo = $this->get(self::SERVICE_LOCALE_REPOSITORY);         $this->context->currentLocale = $localeRepo->getLocale(             $this->context->language->getLocale()         );
Et voici le fichier Language.php
    /**      * @return string return the language locale, or its code by default      */     public function getLocale()     {         return !empty($this->locale) ?             $this->locale :             $this->language_code;     }
Savez-vous pourquoi il ne retourne rien ?
Bien à vous
Cordialement

authors: Fukitsune JESUDAWN ghermans vaishaliwebkul


text:
add field company_name to bliss views

As mentioned in https://github.com/bagisto/bagisto/issues/2415, addresses company name should be shown in orders summary.
With this PR this is done for admin frontend and bliss theme.
@jitendra-webkul please have a look at it.
Thank you

don't reply

Hi @SteffenMahler
company_name should also visible in the generated invoice pdf & also inside email notification template .
https://prnt.sc/sl0gq0

authors: SteffenMahler ajaykan47 vaishaliwebkul


text:
请问为什么快捷键配置不了了?感谢!

独立工具窗口可以,激活该扩展程序那里则是一直灰色

补充..:那里都是灰色...但是目前快捷键配置失效了,别的扩展正常

补充..:那里都是灰色...但是目前快捷键配置失效了,别的扩展正常

这里是灰色是正常的 无法使用我这边正在找原因

已修复 设置后重启浏览器

authors: XuShall baiy

repo: baiy/Ctool


text:
Machine leaks API information in production

In production, when required param(s) are omitted from e.g. a POST request, machine's E_MISSING_OR_INVALID_PARAMS response will leak information about the API.
E.g.:
$ curl http://localhost:1337/some_endpoint

{
  "code": "E_MISSING_OR_INVALID_PARAMS",
  "problems": [
    "\"some_var\" is required, but it was not defined."
  ],
  "message": "The server could not fulfill this request (`POST /some_endpoint`) due to 1 missing or invalid parameter."
}

This error message is generated in the machine-as-action module, and there does not appear to be an option to disable this.
These detailed messages are very helpful in development, and likely if building a production API to be consumed by third parties.
However, for some projects they represent an unacceptable level of data leakage.
It would be great if there were an option to disable these detailed error messages in production, and instead return a straight 400 error with content simply Bad Request (text/plain).

@alxndrsn this totally make sense, maybe some kind of function that would run in this scenario and return the desired response body (leaving the headers & status code the same).
If anyone else looking at this issue has anything to add, open to more suggestions/feedback!

Although the framework has great power with its automation, you can provide a workaround with your own controller I presume.

@crh3675 this is true, but inconvenient if it has to be done in many controllers simultaneously.

Policies are processed before controllers, perhaps in there?

As far as I could work out, you can only have one policy per controller.  Also sounds a bit hacky... maybe more intuitive would be an error-handling middleware which filters out the messages I don't like.

You can have multiple policies per controller - we do it all the time-  just use an array instead. Or set a wildcard catchall.

You can have multiple policies per controller

@crh3675 this is true.  I got confused, because I've tried in the past to enforce policies like "is admin OR manager", but this doesn't seem simple to achieve via policies alone - the combined policies such as
    'some-endpoint': ['isAdmin', 'isManager'],

are a conjunction rather than disjunction, so I've ended up with policies like isAdminOrManager.  This gets tedious when there are many different combinations implemented.

@raqem I think there are workarounds implied, but not clearly defined.  Options seem to be:

rewriting the controller to not use machine
adding middleware to filter out these errors for particular endpoints and/or in particular environments

I'd guess that 2 is the less risky option, but I can't confirm that it either works or is reliable.  I'll share info here when I've implemented a workaround.

@crh3675 going back to your original point:

Policies are processed before controllers, perhaps in there? You can apply a global policy across all controllers which might be another temporary solution

As there's no setting for machine to disable these error messages, it's not clear to me how a policy would be able to help in this situation.

I guess it would be easier if the machine actually threw an error that was catchable.  I understand a bit more after looking into the machine modularization.  Looks like you might be able to create a custom res.badRequest with custom code and catch the E_MISSING_OR_INVALID_PARAMS error code .  Seems to not be the most desirable but may provide a workaround.

I am finding a solution for this too, These messages can be leak our api params to outside.

Super simple fix in in responses/badRequest
  if (_.isError(data)) {
    if (err.code === 'E_MISSING_OR_INVALID_PARAMS') {
      if (data.hasOwnProperty('problems')) {
        delete data.problems;
      }
    }

@crh3675 neat.  Do you mean in ./node_modules/sails/lib/hooks/responses/defaults/badRequest.js?

When you create a new Sails application you should have a folder under api/responses of which you can change

When you create a new Sails application you should have a folder under api/responses of which you can change

No, sails will not create response folder automatically. You will need to create the folder also the customResponse file by yourself

So it seems that the solution is to copy ``/node_modules/sails/lib/hooks/responses/defaults/badRequest.js``` into api/responses and customize

Yeah, the solution I choose like this:

Create a custom response file in api/response folder.

define exits property like this:
`{
successRequest: {
statusCode: 200,
description: 'Success to process',
responseType: 'responseToClient',
},
 successCreate: {
   statusCode: 201,
   description: 'Success to create',
   responseType: 'responseToClient',
 },

 invalidInputParam: {
   statusCode: 400,
   description: 'Bad param input',
   responseType: 'responseToClient',
 },

 notAuthorize: {
   statusCode: 401 ,
   description: 'Not authorize to access',
   responseType: 'responseToClient',
 },

 notUnique: {
   statusCode: 409,
   description: 'Not unique',
   responseType: 'responseToClient',
 },

}`

After that, whenever you call exit.exit function name then the data will automatically send direct to responseToClient function. Just do whatever you want in that file

authors: alxndrsn crh3675 karmamaster rachaelshaw

repo: balderdashy/sails


text:
fixing many to many deletes

Destroy will fail to create a valid sql query in many to many relationships with custom primary key column names.  The resulting query will include undefined columns
IN (undefined, undefined, undefined)

Looks good to me.  Does there happen to be a related issue for this?  Also, can someone verify that the added test will fail without this change?  Lastly, we need to test this against the adapter tests.  Thanks, @esopian !

No related issue that I know of.  We had to patch for behavior we saw in our project.
We failed the test first before fixing but someone should absolutely double check me on this  :)

I wonder if this can fix issue #783.

It should fix #783 as well.

@dmarcelino good point... we really need to look deeper into this issue.

Got to the bottom of this!  The results are coming directly from the adapter, so they haven't been transformed.  That means that results are keyed by column name.  Will submit a PR.  Unclear if this one should live on, or if it could mask other issues.  I think in this sort of situation, waterline should ideally have thrown an error early on.

Good catch @devinivy! That seems to be the best solution. Assuming your PR will fix the problem, we won't need this fix, since it can mask other issues (as you said), though we should keep the tests which are most welcomed. :)

@esopian does have the correct fix and the tests are great, so I may not have to make a PR.  Any feelings about,

Replacing the undefined filter with an assertion that will error and,
Possibly replacing the full transformation with a column name lookup rather than an attribute name lookup here.

if the tests still pass I think that makes sense!

@particlebanana, @tjwebb, what do you guys think?

@esopian, any chance you could follow up on @devinivy's suggestions in https://github.com/balderdashy/waterline/pull/928#issuecomment-93990300? Thanks!

Submitted #1022 that expands on this and makes it so we don't need to use the transformer.

@particlebanana's solution does seem simpler.

authors: devinivy dmarcelino esopian particlebanana

repo: balderdashy/waterline


text:
balena-yocto-scripts: Update to v1.17.2

Update balena-yocto-scripts from v1.17.0 to v1.17.2
Change-type: patch
Changelog-entry: Update balena-yocto-scripts to v1.17.2
Signed-off-by: Alex Gonzalez alexg@balena.io

@balena-ci retest

@balena-ci retest

@balena-ci retest

@balena-ci I self-certify!

repo: balena-os/balena-qemu


text:
Switch from balenaCI to flowzone

Changelog-entry: Switch from balenaCI to flowzone
Signed-off-by: Alex Gonzalez alexg@balena.io

@balena-ci retest

Flowzone master has been fixed by the test is caching

repo: balena-os/balena-variscite


text:
[WIP] Docs and designs for a DIY balenaSound portable device

Init commit.
Change-type: minor
Features to include:

[ ] Provide 3D models (#184)
[ ] Provide guides (@chrisys we could add some things from the boombeastic wiki: https://github.com/balenalabs/boombeastic/wiki)
[ ] Add GPIO on/off option
[ ] Add gpio remote control. (Reference this way: https://user-images.githubusercontent.com/40795980/74084516-32f60d00-4a70-11ea-9bfe-1eda369ade29.jpg) (#101)
[ ] Battery

For the team: You can add ideas via editining this comment. I hope this will get great. 👍

Do we really need a LED matrix? I think this would only add extra cost and use much energy.

@curcuz could you please update the 3D designs? And add the Pi 4?

@AlexProgrammerDE mind sharing some context?

@curcuz yeah sorry. I had the idea to make balenaSound portable like boombeastic. You made some cool designs, but they are outdated. Can you replace the logo and fill the ledmatrix hole?

may do this another time. we should concentrate on 3.0 support and bug fixes

authors: AlexProgrammerDE curcuz

repo: balenalabs/balena-sound


text:
Add integration sample

Purpose

Describe the problems, issues, or needs driving this feature/fix and include links to related issues in the following format: Resolves issue1, issue2, etc.

Goals

Describe the solutions that this feature/fix will introduce to resolve the problems described above

Approach

Describe how you are implementing the solutions. Include an animated GIF or screenshot if the change affects the UI (email documentation@wso2.com to review all UI text). Include a link to a Markdown file or Google doc if the feature write-up is too long to paste here.

User stories

Summary of user stories addressed by this change>

Release note

Brief description of the new feature or bug fix as it will appear in the release notes

Documentation

Link(s) to product documentation that addresses the changes of this PR. If no doc impact, enter “N/A” plus brief explanation of why there’s no doc impact

Training

Link to the PR for changes to the training content in https://github.com/wso2/WSO2-Training, if applicable

Certification

Type “Sent” when you have provided new/updated certification questions, plus four answers for each question (correct answer highlighted in bold), based on this change. Certification questions/answers should be sent to certification@wso2.com and NOT pasted in this PR. If there is no impact on certification exams, type “N/A” and explain why.

Marketing

Link to drafts of marketing content that will describe and promote this feature, including product page changes, technical articles, blog posts, videos, etc., if applicable

Automation tests

Unit tests

Code coverage information

Integration tests

Details about the test cases and coverage

Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes/no
Ran FindSecurityBugs plugin and verified report? yes/no
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes/no

Samples

Provide high-level details about the samples related to this feature

Related PRs

List any other related PRs

Migrations (if applicable)

Describe migration steps and platforms on which migration has been tested

Test environment

List all JDK versions, operating systems, databases, and browser/versions on which this feature/fix was tested

Learning

Describe the research phase and any blog posts, patterns, libraries, or add-ons you used to solve the problem.

@kasun04: Readme file is added in https://github.com/ballerina-guides/gmail-spreadsheet-integration/pull/3


text:
README does not reflect latest release

0.970.0 is not mentioned

This repo is deprecated. Have to move to attic.

repo: ballerina-lang/plugin-vscode


text:
Formatting issue in channels

Description:
channel<json>     jsonChannel;

Fixed in https://github.com/ballerina-platform/ballerina-lang/pull/10559

repo: ballerina-platform/ballerina-lang


text:
Outputs of printing a map and a record are different

Description:
import ballerina/io;

type Foo record {
    string a;
    string b;
};

public function main(string... args) {
    map<anydata> a = { a: "A", "b": "B" };
    Foo b = { a: "A", b: "B" };
    io:println(a);
    io:println(b);
}

Output:
{"a":"A", "b":"B"}
{a:"A", b:"B"}

Is this intentional?

This is fixed in jBallerina.

authors: Anoukh Kishanthan


text:
Abstract operation FillMember does not implemented for list get operation.

Description:
FillMember seems to be only implemented for list.add operation. It also need to support for list.get operation as well.
Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

Issue to clarify this in the spec https://github.com/ballerina-platform/ballerina-spec/issues/383


text:
Triple backtics to recognize ballerina code sections not parsing correctly at some instances

Description:

Steps to reproduce:

Have the following code

# Write an array of lines to a file.
# During the writing operation, a newline character `\n` will be added after each line.
# ```ballerina
# string[] content = ["Hello Universe..!!", "How are you?"];
# io:Error result = io:fileWriteLines("./resources/myfile.txt", content);
# ```
# + path - The path of the file
# + content - An array of string lines to write
# + return - The null `()` value when the writing was successful or an `io:Error`
public function fileWriteLines(@untainted string path, string[] content) returns int? {
 return 0;
}

Ballerina code section wont be correctly recognized. It will be parsed as follows.

Write an array of lines to a file. During the writing operation, a newline character \n will be added after each line. MISSING[`]```ballerina

string[] content = ["Hello Universe..!!", "How are you?"];
io:Error result = io:fileWriteLines("./resources/myfile.txt", content);

We need to update the \n to \\n in the place we have this.

We need to update the \n to \\n in the place we have this.

When we add an extra \, the documentation gets parsed as follows.
Write an array of lines to a file.
During the writing operation, a newline character `\\n` will be added after each line.
```ballerina
# string[] content = ["Hello Universe..!!", "How are you?"];
# io:Error result = io:fileWriteLines("./resources/myfile.txt", content);
# ```

Shouldn't we remove the extra \ in the final output to show what the writer intended?

When we add an extra \, the documentation gets parsed as follows.
Write an array of lines to a file.
During the writing operation, a newline character `\\n` will be added after each line.
```ballerina
# string[] content = ["Hello Universe..!!", "How are you?"];
# io:Error result = io:fileWriteLines("./resources/myfile.txt", content);
# ```

Shouldn't we remove the extra \ in the final output to show what the writer intended?

Had a look. We can use \n in the normal documentation.
eg. # During the writing operation, a newline character \n will be added after each line. parsing as expected.
Problem is inside the single backticks we capture identifier tokens and "\n`" gets identified as an identifier there.
Checked compiling following code and apparently we can define an identifier like that.
var \n` = 10;

But, according to the specs \n` is not supposed be parsed as an identifier right? @rdulmina

Had a look. We can use \n in the normal documentation.
eg. # During the writing operation, a newline character \n will be added after each line. parsing as expected.
Problem is inside the single backticks we capture identifier tokens and "\n`" gets identified as an identifier there.
Checked compiling following code and apparently we can define an identifier like that.
var \n` = 10;

But, according to the specs \n` is not supposed be parsed as an identifier right? @rdulmina


text:
A record with non-required fields of never readonly types can be used in an intersection with readonly

Description:
$title.
Steps to reproduce:
type Grault record {
    stream<int> x?;
};

public function main() {
    record {| int y = 1; |} & readonly a = {};

    Grault _ = a; // allowed
    readonly y = a; // allowed

    Grault & readonly _ = a; // error: invalid intersection type with 'readonly', 'Grault' can never be 'readonly'
}

Affected Versions:
slbeta3, slbeta4

Same for the rest fields.
type Grault record {|
    int i;
    stream<int>...;
|};

public function main() {
    Grault & readonly a;
}


text:
Deleting a source file doesn't clear diagnostics of that file

Description:

Create a ballerina project. Add another bal file and type something invalid there. In VSCode, under the problems tab, you will see errors related to that newly created file.
Now, delete the new file and look at the Problems tab. Diagnostics are still there.
Steps to reproduce:
See description
Affected Versions:
Swan Lake 2201 GA

Will be addressed with #34933

Closing since the fix has been merged with https://github.com/ballerina-platform/ballerina-lang/pull/35771.

authors: IMS94 TharushiJay nadeeshaan


text:
Shadowing issue with nested  From clause

Description:
$title.
Steps to reproduce:
function testReachableStatementInQueryAction9() returns error? {
    error? a = ();
    check from var item in 1 ... 5
        where item < 2
        do {
            a = (from var item in 1 ... 5 // should give variable redeclared error for `item`.
                where item is int
                where item < 2
                do {
                    int _ = 10;
                });
        };
    return a;
}

Fixed With https://github.com/ballerina-platform/ballerina-lang/pull/35135


text:
[Bug]: NPE in BallerinaTextDocumentService

Description
When pull module code action is executed the following exception is thrown. However, this does not break the code action.

This will be fixed with #38274


text:
[HTTP] Disable/Enable chunking based on the message size

At the moment we only can configure chunk enable/disable. But ideally it would be nice if we can specify a size that determines if we need to chunk or not.

This has been implemented hence closing the issue.


text:
Invalid error message when non-existed bal file is provided to "ballerina run"

Description:
If you provide a non-existent file to the ballerina run command, it produces an ambiguous error. The error should simply say that the file does not exist.
Steps to reproduce:
ballerina run file-that-doesnt-exist.bal
ballerina: valid package not available at 'file-that-doesnt-exist.bal'
Affected Versions:
ALL
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):
Bug

This is fixed now. Error message:
ballerina: cannot find file 'file-that-doesnt-exist.bal'

authors: afkham uthaiyashankar


text:
Fix tests generation for the records

Purpose

Fix value generation for the records.
This PR fixes https://github.com/ballerina-platform/ballerina-lang/issues/12679

Codecov Report

Merging #12680 into next-release will decrease coverage by <.01%.
The diff coverage is 0%.

@@                Coverage Diff                 @@
##             next-release   #12680      +/-   ##
==================================================
- Coverage           59.86%   59.85%   -0.01%
  Complexity            659      659
==================================================
  Files                2064     2064
  Lines              101609   101627      +18
  Branches            12932    12933       +1
==================================================
+ Hits                60825    60830       +5
- Misses              35586    35599      +13
  Partials             5198     5198

Impacted Files
Coverage Δ
Complexity Δ

...alang/langserver/BallerinaTextDocumentService.java
68.13% <0%> (ø)
0 <0> (ø)
:arrow_down:

...angserver/command/testgen/ValueSpaceGenerator.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...java/org/ballerinalang/bre/bvm/BLangVMStructs.java
50% <0%> (-1.67%)
0% <0%> (ø)

...ain/java/org/ballerinalang/net/websub/hub/Hub.java
59.09% <0%> (-1.52%)
0% <0%> (ø)

...et/http/actions/httpclient/AbstractHTTPAction.java
78.01% <0%> (-0.87%)
0% <0%> (ø)

...llerinalang/stdlib/socket/tcp/SelectorManager.java
74.1% <0%> (+1.78%)
0% <0%> (ø)
:arrow_down:

...va/org/ballerinalang/channels/ChannelRegistry.java
91.89% <0%> (+2.7%)
0% <0%> (ø)
:arrow_down:

...a/org/ballerinalang/bre/bvm/WorkerDataChannel.java
86.41% <0%> (+3.7%)
0% <0%> (ø)
:arrow_down:

...rinalang/runtime/threadpool/ThreadPoolFactory.java
66.66% <0%> (+4.76%)
0% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4b114d...32878c6. Read the comment docs.

authors: codecov-io rasika


text:
Handle error return of listener gracefulStop() method

Purpose

$Subject
Currently error returns from gracefulStop() methods of listeners results in panics. Actual behavior should be returning error. Added a fix with PR.

Fixes #40978
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Closing this, since the commits are added to https://github.com/ballerina-platform/ballerina-lang/pull/41416


text:
[Bug]: Deprecated notation does not work correctly with resource functions

Description
The deprecated notation produces an error for a resource function. Ballerina version = 2201.8.0

Steps to Reproduce
Repository where the error occurred.
https://github.com/wso2-enterprise/choreo-cp-configuration-service
Affected Version(s)
No response
OS, DB, other environment details and versions
No response
Related area
-> Compilation
Related issue(s) (optional)
No response
Suggested label(s) (optional)
Team/CompilerFE
Suggested assignee(s) (optional)
No response

The above problem can be reproduced with the following simple code.
import ballerina/http;

service on new http:Listener(8080) {

    @deprecated
    resource function accessor path() {

    }
}

It generates the error invalid resource method annotation type: expected http:ResourceConfig, but found deprecated for the ballerina/http, and the error is specific to this module. The error cannot be reproduced with the ballerina/udp module.

authors: chalindukodikara nipunayf

repo: ballerina-platform/ballerina-library


text:
Incomplete API doc snippet shown for publishMessage function from NATS client

Description:
When hovering over publishMessage function, I am seeing an incomplete API documentation for the function as below.

Publishes data to a given subject.

ballerina # nats:Error? result = natsClient->publishMessage(<@untainted>message); #

Parameters
nats:Message message : Message to be published

Returns
nats:Error?() or else a nats:Error if there is a problem when publishing the message

Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

Checked in Ballerina Swan Lake Beta 1
Closing since the issue seems to be resolved.
Hovering over publishMessage prompts the following:

authors: Kishanthan aashikam


text:
Update package to run with the latest package resolution changes

Purpose
Fixes ballerina-platform/ballerina-lang#32190
Checklist

[ ] Linked to an issue
[ ] Updated the changelog
[ ] Added tests

Closing this in favour of https://github.com/ballerina-platform/module-ballerina-websocket/pull/299

authors: azinneera niveathika


text:
[bal-image-slider], do not swipe on mobile click

Detailed description
in mobile view the user should use a swipe and not a click for rotate to the next or previous slide.
in our case, if i have custom content in the slide item and have in this case a back-side. i can reach it over the info button. then i click on the button and a previous slide item is available it will show me the back-side and also rotate to the previous slider item.
Steps to reproduce the issue

open site in mobile view with touch access
click on the slider-item at the right or left side
the slide moves left or right

Additional information
https://user-images.githubusercontent.com/3681337/187693724-166b7b7c-47ac-42ea-8b3b-ae3cddc91d41.mov

I identified several additional issues, we have to disucss the process tmrw in the daily.

check product slider as well with the touch navigation

#508

repo: baloise-incubator/design-system


text:
Sent messages in timeline of a topic

Sometimes (the app was downloaded via the Play Store) after sending a message to a topic, there is a possibility that the message does not appear immediately in the sender's timeline but shows up immediately in the recipient's timeline.
The appearance of the message in the sender's timeline can take 10-30 minutes after it is sent, which causes confusion. If the message does not appear on the sender's phone, neither does the recipient's reply.
Force closing the app or clearing the cache memory on the sender's phone does not help, and the timeline is restored at a random time.
The phones used for testing were a Samsung S21 and a Samsung Fold, both running Android 14

Does this issue appear when using the browser? If so, do you see any errors in the browser console log? Do you see any error messages in the container log?
The messages appear in the topic thread when indicated by a websocket connection, even if that app just posted the messages. It's hard for me to tell why there is a delay without further information, but I would initially look at the setup of the server and see if there is anything that could cause the websocket connection to break or prevent the connection. Perhaps there is some network security in place seeing the websocket connection requests as a threat?
I'm sorry I can provide more insight without some more details. Perhaps there is a bug, but this has not been reported by other users.

I haven't noticed anything similar on the web.
The issue appears randomly and resolves itself randomly. Calls during the issue function normally. I can't understand how network security affects some random messages and not, for example, voice calls, which involve a larger data volume, ruling out throttling on the reverse proxy.
My setup is on Ubuntu Server 24.04.1, and as a reverse proxy, I use Cosmos Cloud with all shields disabled and only protection against common bots enabled. I have the same reverse proxy settings for Dendrite, which works perfectly fine.

Is the delay by chance related to sending a very long string with no spaces? There is a bug which I have yet to push the fix out to android, where the tokenizer/sanitizer for clickable URLs was really slow, and could lead to a long period of unresponsiveness. I don't think that's your problem since you mentioned the 2nd android phone doesn't have that delay.
It's possible the communication mechanism used by databag (websockets) is related to the issue. In my reverse proxy for example, I need to specifically enable websocket support. I believe element/dentrite uses a polling get to receive updates.
I am usually able to resolve issues quickly that I can reproduce, so I will try and mirror your environment and see if I can that way. How frequent is the delay? Is the issue likely to be seen when using the app for 5min?

I do not receive errors from the reverse proxy. Cosmos Cloud supports WebSocket by default.
However, in their Discord community, I couldn't figure out how to set the URL properly to achieve optimal performance for applications requiring WebSocket.
Imagine that some users configure the URL as servapp-container, while others use proxy (pointing the local app's IP to the subdomain) to get things working correctly. Someone even disabled protection against common bots.
In my case, whether I configure the URL as servapp-container or as proxy, I don’t get any errors.
The only noteworthy observation I could share is that, with both setups, I receive the following response:
{   "id": "67665549420bf19a710f0f27",   "label": "Proxy Response databag success",   "application": "Cosmos",   "eventId": "cosmos.proxy.response.databag.success",   "date": "2024-12-21T05:42:17.022Z",   "level": "info",   "data": {     "bytes": 0,     "clientID": "my_pyblic_ip",     "hostname": "databag's_subdomain",     "method": "GET",     "route": "databag",     "status": 0,     "time": 36.18142271,     "url": "/status?mode=ring"   },   "object": "route@databag"
I've changed the URL's mode and left it as proxy with all shields disabled, even the common bots protection, and I’ll follow up later.
Also, I don’t have an answer for your last two questions.
Finally, something unrelated: I haven’t been able to enable push notifications on Brave, no matter how hard I try. A popup appears with the error message: "Operation failed, please try again."
I don’t face this issue on Firefox.

authors: balzack chamdim

repo: balzack/databag


text:
使用裁剪框时，图片比边框大

提bug前必看
请先回答下列三个问题，否则不允处理，谢谢配合。
1、我最新的Demo是否有这个bug？【如果Demo没问题，请升级新版】
答：有
2、你用的是什么版本？升级到最新版后是否正常？
答：3.5.0的demo进行测试
3、是否有改动过我库内部的代码？【如有，请告诉我你改了什么】
答：没有
bug内容描述
图片大于裁剪框，导致图片裁剪不全，能否让照片边缘贴近裁剪框。
我如何复现这个bug？
运行后点击-单选模式下允许裁剪，然后点击加号进入照片裁剪页面，照片明显大于裁剪框。
截图

其它说明
有没有其它要补充的？比如你的初始化TZImagePickerController的代码

不支持缩小图片...
如确有需要，欢迎提个PR...

authors: banchichen ccccccccai

repo: banchichen/TZImagePickerController


text:
Missing Database Schema Documentation

There is no visible documentation or ERD of the database structure, which could make it difficult for new developers to understand data flows.

please note every table in the db is represented by a very detailed entity file.
any change/addition to the db is done by modifiying these files, and migrations are generated automatically with npm run scripts

please note every table in the db is represented by a very detailed entity file. any change/addition to the db is done by modifiying these files, and migrations are generated automatically with npm run scripts

While this is true, I'd claim that a higher-level database schema overview is still valuable. An ERD or similar schema documentation provides an accessible, visual snapshot of the relationships between tables, which is particularly helpful for:

Onboarding and Collaboration (New team members or external collaborators / licensees) - not  needing to go through each entity file in detail.

System Design Discussions: A visual schema is useful in planning and architectural discussions.

Database Management: with more people involved, a schema overview helps ensure everyone understands the relationships and data flow, reducing the chance of misinterpretation or errors during maintenance.

authors: yarivbancor zavelevsky

repo: bancorprotocol/carbon-backend


text:
Jekyll server failed for doc with "`/' not found." in Browser

If i install via npm and want to build via grunt, the server started but cant find the URL.
Displays `/' not found. in the Browser.
Solution is to delete the complete line from the jekyll server config. (_config.yml)
baseurl: "/SASS-Material-Design-for-Bootstrap"

This is currently configured this way because we have a Travis build which pushes updates to the gh-pages branch which this repo is one of a number of hosted ones. I'll rewrite it at some point soon to use the empty URI and publish to a subfolder instead. Like you say, updating the config helps or you can navigate to the local URL: http://127.0.0.1:4000/SASS-Material-Design-for-Bootstrap/

ok. I thought so. Thanks!
BTW Best Material Design Bootstrap implimentation on Github! Srsly i tested them all ... But you really need to provide some examples to get startet :)
Please keep up the good work!

Thanks Christoph, glad to hear you're enjoying it :-)
Examples are definitely on the way, probably as a few different layout templates to get you started...

Sounds great! Thank you!

authors: andrew-waters pixelpoesie