Widgets could declare the layout model (box or sliver) they are expecting

This was inspired by a question on Stack Overflow.
Flutter has various classes that take Widget or List<Widget> constructor arguments. Sometimes a widget knows that it wants box children or sliver children, but it doesn't have great ways of expressing that currently.  You can guess based on the class names (if it has Sliver in its name and does not have Delegate in its name, it will produce a RenderSliver). For arguments, the current convention is that if a list of children that produce RenderSliver is desired, the List<Widget> argument should be named slivers. There isn't currently a way to express the equivalent desire for individual Widget arguments or for box children. The analyzer doesn't show a warning if you use a box as a sliver or vice versa.
In the future, we might support other layout models (sector layout? 3D?) and it would be nice if widgets written for those layout models could be easily identified as well.
One possible way to address these issues above would be to make Widget a generic with a type argument that expresses which layout world it lives in. So for example Widget<RenderBox>would produce only RenderBox children, and Widget<RenderSliver> would produce only RenderSliver children. If a widget has a child argument you could declare it to be a Widget<RenderBox> or Widget<RenderSliver> and the analyzer would warn you if you passed the wrong type of child. If you produce both types of children, you could extend Widget (if you don't want to be a child of widgets that care about layout) or a Widget<T extends RenderObject> if you want to let parents choose your layout world.
Teaching the type system about sliver vs box distinctions has the potential to make the API more complicated and hard to extend. If we updated all the constructors to specify the exact types they expect, it would some cognitive overhead when writing new widget classes because you have to think about whether you want to be a Widget<RenderBox> or Widget<RenderSliver> or Widget or Widget<T>. If you do the wrong thing you might find you can't use your class in places where you want to. Also, there is some performance impact to using generics, although it's unclear whether it would be substantial.
There are a few ways to potentially cut corners and make this change simpler:

Focus on slivers and don't bother annotating boxes because they're much more pervasive.
Focus on annotating subclasses of RenderObjectWidget and optimistically assume that StatelessWidget, StatefulWidget, and ProxyWidget will produce a render object that works.

Even with these mitigations, I'm not sure it's a good idea, but I thought I'd sketch out a few ideas into this bug that we can archive in case someone else wants to push this idea further future. Supposing that we did decide to expose this information, how might we use it?
Static type checking
Existing code is a challenge since we're trying to maintain API stability:
new Container(
  child: new Column(
    children: <Widget>[
      new Text('Hello world!'),
    ],
  ),
),

We can't easily change Container to accept a Widget<RenderBox> value for child, and we can't easily change Column to accept a List<Widget<RenderBox>> for children, because it would make this code invalid. A List is a subclass of List<Widget<RenderBox>>, but a List<Widget> isn't a subclass of List<Widget<RenderBox>>, even if it happens to contain Widget<RenderBox> children.
Here's a sliver world example has a similar problem.
new CustomScrollView(
  slivers: <Widget>[
    const SliverAppBar(
      title: const Text('Title'),
    ),
 ),

There aren't a ton of apps using lists of slivers directly at this point (they're required for CustomScrollView, Viewport, SliverList, but most devs probably use higher level abstractions). So maybe it would be feasible to convert the sliver classes over to using these type annotations without breaking the universe:

We could convert over the core framework slivers to be Slivers, deprecate the slivers argument to CustomScrollView and Viewport and replace it with an optional children argument of type List<Widget<RenderSliver>>. After some time we could remove slivers and make children required.
Or if we wanted to continue to have the argument be named slivers, we could change it from a List<Widget> to a List, and then later on replacing List with List<Widget<RenderSliver>> once we think we have gotten rid of most of the code that is passing List.

There are a lot of Widget subclasses that extend or require RenderBox at this point, so converting those over would be more work.
Runtime checking
If a widget is expecting children that produce only RenderSliver or RenderBox as arguments, it could express that with assertions:
assert(child is! RenderObjectWidget || child is RenderObjectWidget<RenderSliver>);

assert(children.every((child) {
  return child is! RenderObjectWidget || child is RenderObjectWidget<RenderBox>;
});

This doesn't really help much with the goal of showing analysis errors in the IDE, but at least you'd catch the error as soon as you constructed a widget instead of during rendering.
Metadata
We could use annotations.
@shouldRender(RenderSliver)
final Widget child;

Could be shorthand for
@assertEquals(extends(RenderObjectWidget), extends(RenderObjectWidget<RenderSliver>))
final Widget child;

The linter would warn if it sees a RenderObjectWidget<RenderBox> assigned to a shouldRender(RenderSliver) property or vice versa.
A few notes on this approach.

I am not sure how to extend this to lists of children.
We could potentially use metadata instead of generics for annotating the types that widgets can produce as well as what they consume.
This option sort of feels like we'd be building a whole new type system out of metadata. Maybe that would be a good thing if we could encode other information properties like whether a widget is shrink-wrapped or infinite, but it would definitely be a Project™.

Comments welcome. I'm not currently planning to pursue this idea further unless others are excited about it; feel free to close this issue.

We don't really know how to solve this in a usable way.
Please don't hesitate to comment on this bug if you have ideas. We would love to find a good solution. We're closing it for now because it's not actionable as it stands.

I don't have any new ideas about how to express this, but I wonder whether overloading would help with the backwards compatibility issue.  That is, you could add a constructor with children accepting List<Widget<Renderbox>>, and deprecate the old one but keep it around.
Alternatively, I suppose maybe having some way to attach automatic coercions to constructors/arguments might allow you to change the type of the constructor arguments but keep the old call sites valid via a compiler inserted conversion.

Thanks for the suggestions, @leafpetersen.
Unfortunately type overloading doesn't seem likely to become a thing in Dart. Also the homepage of dartlang.org seems pretty negative about type coercion.

The landscape is changing a lot with Dart 2.0, so I'm not sure things are still so definitive WRT overloading as that comment implies.  There are definitely concerns around overloading, but there is some demand for it as well.  Code migration is an interesting use case for us to keep in mind.
Coercions are harder - for me at least it's very clear that this can lead you down the path to insanity if you are not very careful.  But in so far as we can keep the user experience good, there is definitely some interest around this.  We are likely, as a very simple example, to add type based coercions on number literals.
cc @floitschG @munificent @lrhn @eernstg

The concerns about static overloading are mainly the added semantic complexity: Developers need to think about static resolution (based on some notion of "best match") as well as object-oriented dispatch (and the two are seriously different as you go into the details), and there is no end to the confusion that this has created for developers (say, in Java or C++). On top of that, the notion of "best match" usually gets hideously complex in itself.
It's probably not going to be worse than many other things to implement support for it, but it is costly for the developers who need to use it correctly in their daily lives.


Required materials API

i have 0 idea of addon development or lua in general but i am currently writing a weak aura to auto reply to various crafting requests. would it be possible to provide some sort of API in your addon that can generate required materials based and output it to a weakaura?

I am actually also working on a module that does this and more ^^ but I can see if I can also make an Api :)

really good work btw. i am impressed

thank you <3

an API is now implemented


Сan not connect to the drone

Hello, I'm simulating VTOL in Gazebo. I want to run example takeoff_and_land.py, but it cannot conect to drone.
My output:
Waiting for mavsdk_server to be ready...
Connected to mavsdk_server!
Waiting for drone to connect...

Is this running on the same machine or are you running docker or a virtual machine somewhere?

No answer in 3 years, I think I can close this.


How can I make a button close with materialize css?

I tried create a button for close a modal but, it isn't work?
My code:
$('.icon-fecha-modal-login').modal('close');

Sorry I discovered how did a resolution the problem.
:)


PBID-11: Support new compound cookie and provide optout status as ORTB EID ext fields

Migrating from legacy _parrable_eid cookie. The new cookie contains ibaOptout and ccpaOptout status fields.

Renaming branch, so am now closing this draft.


COMPOSER-1936: Enable regression-insecure-repo test for nightly CI pipeline

Related: RHBZ#2177699
This pull request includes:

[ ] adequate testing for the new functionality or fixed issue
[ ] adequate documentation informing people about the change such as

[ ] submit a PR for the guides repository if this PR changed any behavior described there: https://www.osbuild.org/guides/

The PR is technically ready to merge but I saw you also triggered the nightly pipeline for it.  I guess we want that to pass as well before merging?  Or do we only care about the insecure-repo test for that?
In other words, do we expect the cross-distro test to pass in the nightly pipeline before merging this PR?

The PR is technically ready to merge but I saw you also triggered the nightly pipeline for it. I guess we want that to pass as well before merging? Or do we only care about the insecure-repo test for that? In other words, do we expect the cross-distro test to pass in the nightly pipeline before merging this PR?

I care about the regression-insecure-repo.sh script and it reported pass in the nightly pipeline. Let's merge.


TDI-36536: added parsing of String Dates to Dates using the design-ti…

…me pattern.

Why was this merged when the comments were not addressed?


Feature :: search bar with categories

Improvement of search bar, now it's organized by categories.
Vue multiselect doesn't allow you to customize a lot the group options so I try to do something not too ugly with it :
I put the label "wip" but if you're ok with this PR we can merge it for the V1 of VQB
=> After discussion it will be ok for the V1

Codecov Report

Merging #262 into master will decrease coverage by 53.48%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           master     #262       +/-   ##
===========================================
- Coverage   95.97%   42.48%   -53.49%
===========================================
  Files          74       61       -13
  Lines        1565      925      -640
  Branches      238      183       -55
===========================================
- Hits         1502      393     -1109
- Misses         63      532      +469

Impacted Files
Coverage Δ

src/components/SearchBar.vue
100% <100%> (ø)
:arrow_up:

src/components/constants.ts
100% <100%> (ø)
:arrow_up:

src/lib/dataset/mongo.ts
0% <0%> (-100%)
:arrow_down:

src/components/stepforms/schemas/utils.ts
0% <0%> (-100%)
:arrow_down:

src/lib/pipeline.ts
0% <0%> (-100%)
:arrow_down:

src/store/getters.ts
0% <0%> (-100%)
:arrow_down:

src/store/backend-plugin.ts
0% <0%> (-100%)
:arrow_down:

src/store/mutations.ts
0% <0%> (-96.97%)
:arrow_down:

src/lib/translators/mongo.ts
3.66% <0%> (-95.71%)
:arrow_down:

src/store/index.ts
0% <0%> (-92.86%)
:arrow_down:

... and 78 more

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 480dcaf...772b6d6. Read the comment docs.


Plugin configuration

This PR implements a new argument for specifying a yaml file for loading arbitrary plugin configuration.
Closes #1121
Credit to @Luis-GA

Codecov Report

Merging #1226 (d925877) into main (1c7bc86) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1226   +/-   ##
=======================================
  Coverage   98.47%   98.47%
=======================================
  Files         456      456
  Lines       25428    25433    +5
=======================================
+ Hits        25039    25044    +5
  Misses        389      389


Update README.md

Adding CF links
@jshcodes what happened to the manual install guide?

Uh... So that's weird.  Let me see if I can find out what happened.


Add reset cron time button on trans detail page.

之前的http api和存储层都有一个ResetCronTime来批量重置👇🏻，只是没有集成到admin。
ResetCronTime(after time.Duration, limit int64) (succeedCount int64, hasRemaining bool, err error)`

本次在admin事务详情页增加根据gid重置单条事务的NextCornTime的UI功能，以尽快再次尝试执行。

Codecov Report

Merging #439 (5ac2835) into main (b002b74) will decrease coverage by 1.04%.
The diff coverage is 2.17%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #439      +/-   ##
==========================================
- Coverage   96.05%   95.02%   -1.04%
==========================================
  Files          57       57
  Lines        4136     4182      +46
==========================================
+ Hits         3973     3974       +1
- Misses        118      163      +45
  Partials       45       45

Impacted Files
Coverage Δ

dtmsvr/api.go
96.96% <0.00%> (-3.04%)
:arrow_down:

dtmsvr/storage/boltdb/boltdb.go
93.02% <0.00%> (-3.86%)
:arrow_down:

dtmsvr/storage/redis/redis.go
96.88% <0.00%> (-1.80%)
:arrow_down:

dtmsvr/storage/sql/sql.go
93.27% <0.00%> (-3.89%)
:arrow_down:

dtmsvr/trans_status.go
92.11% <0.00%> (-3.29%)
:arrow_down:

dtmsvr/api_http.go
91.53% <33.33%> (-1.38%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

整体单测不太稳定，又出现了持久层串台问题，单独跑出错的单测都没有问题，避免大量修改本提交版本暂时注释了单测。

串台的原因是新的单元测试中有一个事务，最后没有把状态设置为succeed，导致被cronjob取出处理。我在最新的代码里面，设置了状态，就没有串台问题了


Introduce new type for serializing encoded Atoms objects

Presently, the featurization in AtomGraph is present for effective serialization support. However, this is not without its issues (see #85).
However, instead of adding a new featurization type, I propose adding a new type that encapsulates the data that would be serialized otherwise, and use this for serialization purposes (and more).
This new type would essentially contain an AbstractAtoms object, AbstractFeaturization object, and an encoded_features field. The features stored in encoded_features can always be decoded using the AbstractFeaturization associated.
Some of the pros that this approach offers -

Atoms object becomes more atomic
decreased coupling between  Atoms and Featurization objects
completely independent, and customisable  serialization (could be specialized for different types if required too, but I think it should be fairly generic)
no need to add a new pseudo featurization type that does nothing
no need to additionally set the field to nothing once a convolution op gets performed on an Atoms object
relaxes the constraint on new types of AbstractAtom, as they won't need to have the featurization field
Present serialization logic as present in the constructor for AtomGraph  can be simplified. This would also apply to other types of AbstractAtoms types (as they're developed).

Codecov Report

Merging #91 (96898c6) into main (c5bde65) will increase coverage by 1.63%.
The diff coverage is 73.91%.

@@            Coverage Diff             @@
##             main      #91      +/-   ##
==========================================
+ Coverage   81.08%   82.72%   +1.63%
==========================================
  Files          11       12       +1
  Lines         312      301      -11
==========================================
- Hits          253      249       -4
+ Misses         59       52       -7

Impacted Files
Coverage Δ

src/ChemistryFeaturization.jl
0.00% <ø> (ø)

src/atoms/atomgraph.jl
69.23% <71.42%> (+6.89%)
:arrow_up:

src/serialize.jl
75.00% <75.00%> (ø)

src/featurizations/graphnodefeaturization.jl
90.69% <100.00%> (-1.31%)
: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 c5bde65...96898c6. Read the comment docs.


Improve ColumnContinuousSection

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

Comparison is base (9c7f743) 100.00% compared to head (9023a2b) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #233   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           70        70
  Lines         1730      1744   +14
  Branches       184       189    +5
=========================================
+ Hits          1730      1744   +14

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


Provide example of custom distributed evaluation function via dask

This is an example of how to write a distributed evaluation function from the Python side. @CodingCat this is what I was thinking of in the discussion of #4280. It does require understanding what AllReduce does but apart from that I think it's quite simple. This approach is fully general, a user could implement any possible evaluation function.

I agree the code would not be complicated if we look at an individual case
But for the cases in our current view, users essentially have to write the same piece of code like here to implement each custom function
And in xgb, we have provide the same functionality in c++, my point is why we put this burden to user again (for many users I talked with I do not even believe they can write it correctly)

@RAMitchell @CodingCat I think it's possible to do allreduce inside Learner.

I'm curious about whether we can call back to c++ for all reduce automatically given a customized metric.  We can add a C API and let language bindings call it after calculating customized metric.  It might not be general enough, but seems reasonable to think about.

@trivialfis Do you mean something like #4280?

Much less complicated I think.

Still need to do a couple of things on this. The python rabit API is not actually documented, there are no tests, there are no enums defined for AllReduce ops. Would also be good to get some agreement and consistency with spark before we go down this route (if at all).

To me, exposing rabit to users is equivalent to ask users to learn how NCCL/Arrow works when they want to use RAPIDS. It's not my taste to develop a software for users. Blocking something for some non-concrete reason is not my taste to manage software development either.
Not masking sum operation, etc. can be resolved by providing more general abstractions in c++ layer, why #4280 contains a lot of code can be explained as (1) most of changes are moving stuffs; (2) I need to create abstractions instead of just write two lines of plain code because Java/Scala accepts a class instead of a function
I am too busy to continue the discussion here which is essentially a duplication of #4280. I don't think I would change my taste about what is to be exposed to the users just because of this.
So please go ahead with the approach here. I will close #4280 and leave the community or myself (when I have time) to make it consistent with python part

@CodingCat @trivialfis @RAMitchell
I don't think exposing Rabit to users is the best path forward.

I am noticing that users are trying to make their customized metrics work and fail, especially for multi-class classification, learning-to-rank, and survival tasks. We don't have to add yet another obstacle.
We may want to adopt other collective primitives other than AllReduce. For example, in https://github.com/dmlc/xgboost/issues/4503#issuecomment-496181250, we may want to adopt a sparse representation to reduce memory consumption for sparse, high-dimensional datasets, and current (dense) AllReduce may not be optimal.

Moving forward: I think we can still merge this PR. Later, we should take time to decide on a good, high-level metric interface for different tasks (binary classification, multi-class classification, regression, learning-to-rank, survival, counting) and implement the high-level interface on top of this PR. So for most users, AllReduce call would be automated (as @trivialfis suggested).
Note to @CodingCat: I liked the general idea of #4280. I will leave my comments about the metric interface soon.

We may want to adopt other collective primitives other than AllReduce. For example, in #4503 (comment), we may want to adopt a sparse representation to reduce memory consumption for sparse, high-dimensional datasets, and current (dense) AllReduce may not be optimal.

I don't think dimensionality of the data matters for evaluation because we only consider rows. I can't think of a case where the AllReduce would be problematic. Maybe for ranking where you have a huge number of groups?

I don't think exposing Rabit to users is the best path forward.

I can try implementing @CodingCat's higher-level interfaces here and see what it looks like. There is no rush to merge this. My feeling is we can do this without touching C++ code. Performance should be adequate using numpy and it's only proportional to number of rows so evaluation doesn't tend to be a bottleneck.

@RAMitchell

I don't think dimensionality of the data matters for evaluation because we only consider rows

This is true for metrics. So AllReduce will be appropriate for the customized distributed metrics. The link I put up was referring to the use of AllReduce in gradient histogram calculation.

My feeling is we can do this without touching C++ code

I personally favor baking good (emphasis on "good") metric interface into the C API. That way, we don't have to duplicate the distributed code across multiple language wrappers. However, I'm pretty flexible on this point: as long as the user can stick to the high-level API without touching Rabit, I'm fine with putting all things in the wrapper level.
Aside: Let's also consider a path to supporting user-defined objective (loss) function in distributed setting.

@hcho3 Survival modeling, We can use Discrimination indexes such as C-index, Brier Score along with negative log-likelihood that is currently present in the Cox-PH model. This document looks good.
https://bmcmedresmethodol.biomedcentral.com/articles/10.1186/1471-2288-12-102


Can't run the app on Android

Describe the bug
When I run the app on Android simulator return the error
"Failed to Invoke: No deep link found."
To Reproduce
Download the source code
Configure server_configuration.dart
const String baseUrl = "http://localhost/bagisto/public/graphql";
const String defaultWebsiteId = "1";
const String defaultChannelId = "1";
const String defaultStoreCode = "pt-br";
const String defaultChannelName = "com.webkul.bagisto_mobikul/channel";
const String defaultCurrencyCode = "BLR";
const String storage = "storage/";
List supportedLocale = ['en', 'fr', 'nl', 'tr', 'es', 'ar', 'pt_br'];
Expected behavior
The app run and show products
Screenshots
?
Smartphone (please complete the following information):
sdk_gphone_86_64
Android 13
Additional context
?

@eddoperes :
NO Android device would understand the URL named http://localhost/ as the android device will try to locate this with in the android device only.
If you are trying to run the Android application in a local environment then map your system with a permanent IP address and then use that IP address as the base Url
Or if you are using any public server with a domain mapped then use that domain name and complete URL as your baseURL.
Hope this solves your issue.
Still if you find something then you can always re-open this issue and we will help you out.
For now, we are closing this issue.

Thanks for replay
I changed the server_configuration.dart e replaced
const String baseUrl = "http://localhost/bagisto/public/graphql";
with
const String baseUrl = "http://<IP_ADDRESS>/bagisto/public/graphql";
Of course the Android emulator will think localhost is the phone, my mistake.
But I replaced localhost with <IP_ADDRESS> and Flutter knows <IP_ADDRESS> is the machine hosting the emulator (I have already used <IP_ADDRESS> in others projetcs and worked) and even so the problem persist
"Failed to Invoke: No deep link found."

Hey @eddoperes
Please share the complete logcat details.
there are logs below the COOKIE DATA as well.
I need to check those and then I will be in a state to answer your queries.
P.S  -> Have you tried opening the baseUrl in the browser of the same android phone ? Is it working ?

I don't know much about GraphQL. For me is more common use REST. But I think that GraphQL is working.

I could not find this folder logcat. I didn't find COOKIE DATA as well. Were are it? Is in the apache server? Is in Flutter project?

Hey @eddoperes : for the url part in the browser edit the address and make sure that the website is accessible to you in the android device itself.
For the logcat, this is the output printed in the DebugConsole window of your Visual Studio Code Editor for the flutter code when you run the flutter code.
Please do share me the complete OUTPUT
In the earlier provided screenshot as well the OUTPUT is printing  and there is a print line "COOKIE DATA", I need the output below that to check what exactly is happening

logcat.txt

I copied the contents of logcat window of Android Studio

vscode.txt

vscode.txt

I copied the contents of vscode console too

vscode.txt

I copied the contents of vscode console too

After ignoring the errors the result is above

Hey @eddoperes : have you enabled any categories on the homepage of the website ?

Hi @eddoperes
Hope you are doing well!
Can you let us know which version of Bagisto you are using? The open-source version of Bagisto Mobile App is compatible with Bagisto v2.0.0.
So to install & configure the Bagisto Headless API you have to clone the project by using  the below command:
composer require bagisto/graphql-api ^v2.0.2
Note:- The below command will provide you the code from the master branch, which is not the stable version:
composer require bagisto/graphql-api dev-main
In case you are still facing some issues regarding setting up the project, you can raise a ticket to our support team at<EMAIL_ADDRESS>Thanks & Regards,
Bagisto Support Team

I have read the errors message in Flutter console and find this one:
"Failed to find class User in namespaces [App, App\Models] for directive @paginate."
What could be wrong?

No progress yet.
This is the error appearing in VSCode console:
EXCEPTION -> OperationException(linkException: ServerException(originalException: ClientException: Connection reset by peer, uri=http://<IP_ADDRESS>/bagisto221/bagisto/public/graphql, originalStackTrace: #0      IOClient.send

I executed -> composer require bagisto/graphql-api ^v2.0.2

Hi @eddoperes ,
Can you let us know which version of Bagisto you are using? The open-source version of Bagisto Mobile App is compatible with Bagisto v2.0.0.
Thanks & Regards,
Bagisto Support Team

Hi @eddoperes,

But not this version v2.0.0. Where can I find it? It's not on github.

You can find the Headless version v2.0.2 (API version) which is for Bagisto v2.0.0:
https://github.com/bagisto/headless-ecommerce/tree/v2.0.2
https://github.com/bagisto/headless-ecommerce/tree/v2.0.2?tab=readme-ov-file#1-requirements
You can use the below command to clone API via composer:
composer require bagisto/graphql-api ^v2.0.2
Thanks & Regards,
Bagisto Support Team


[Event Request] Database::"Job Planning Line" - Function "Quantity" - OnValidate - OnValidateQuantityOnBeforeValidateRemainingQuantity

We like to request the following Event:
Object: Database::"Job Planning Line"
Function: "Quantity" - OnValidate
Publisher Event: OnValidateQuantityOnBeforeValidateRemainingQuantity
Reason: To implement custom business logic
Where is the event placed:
CalcQuantityBase();
IsHandled := false;
OnValidateQuantityOnBeforeValidateRemainingQuantity(Rec, xRec, IsHandled);
if not IsHandled then
if "Usage Link" and (xRec."No." = "No.") then begin
Delta := Quantity - xRec.Quantity;
Validate("Remaining Qty.", "Remaining Qty." + Delta);
Validate("Qty. to Transfer to Journal", "Qty. to Transfer to Journal" + Delta);
end;
Event Code:
[IntegrationEvent(false, false)]
local procedure OnValidateQuantityOnBeforeValidateRemainingQuantity(var JobPlanningLine: Record "Job Planning Line"; xJobPlanningLine: Record "Job Planning Line"; var IsHandled: Boolean)
begin
end;

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


 The final goal is to add support for desktop (linux & windows). In order to do that, the goal of this PR is:

migrate platform code to specific packages (ap_*)
migrate everything to use platform channels (ap_platform_channel)
take this opportunity to simplify the interface between ap and clients (for example, remove overloaded methods like play, playBytes and expose only the crucial building components)

as a part of that, I had to refactor all that mess with the flags. I created a file config_attributes_analysis.md with my thought process and justification and reworked all the flags into some unified data classes.

note: for now I removed all notification related code to try to get this work simply first. we can re-asses how notifications fit in as a second step.

Hello @luanpotter. Any update on this?

Looking forward to the PR, especially windows support! I wonder is there updates? Thanks

Can we help you in any way on this branch?

Hey everyone, so sorry about the huge delay here. Got completely sidetracked by work and then by personal issues. I am back and will try to get this in ASAP!


Does RHEL 6 covered under Microsoft Supported OS versiosn

It looks like .Net Core has added support for RHEL 6 since v2.0.3, does this also mean RHEL 6 is also covered under Microsoft supported OS version and will there be active support available for this OS version?

Thanks for the confirmation. Requesting to comment on couple of items below

are there any considerations for self contained application support on RHEL 6
.Net Core SDK availability for building solutions on RHEL6

@livarcocc can you speak to a RHEL.6 option for the SDK?
Self-contained applications should work just fine. You have to publish one specifically for rhel.6 like:
dotnet publish -r rhel.6-x64 --self-contained

We currently have the change available for our 2.1.300 release, that will match the .NET Core 2.1 release.

Also couple of queries on this support

Will the same binaries published for RHEL.6 work for CentOS.6 as well
I am assuming the binaries published for rhel.6 would work for any rhel 6.x version, is this correct assumption.

Yes,
We are testing on RHEL 6.9.

There are also special instructions you have to follow to get the prereqs on RHEL 6. https://github.com/dotnet/core/blob/master/Documentation/build-and-install-rhel6-prerequisites.md

Ok, I'm going to close this now as I think the question is answered. We will support this in .NET Core 2.1.


Fix: Incorrectly calculated unread mentions

We are calculating the unread mentions to be used in the UI but
are currently not used (should do that soon)
Due to not exposing this we have not caught an issue - the logic to
determine if the current user was mentioned in an upcomming  message
was incorrect. In fact, there is no is_mentioned key on the message
object, but the data is passed via a flags array.
This logic is already used correctly in eventMiddleware.js.
This PR replaces the incorrect code and fixes the tests.

Hmm fascinating -- so one question this raises for me is: why is there also a flags property on the message itself?
After all, this diff itself says
 export type EventNewMessageAction = ServerEvent & {
   type: typeof EVENT_NEW_MESSAGE,
+  flags: string[],
   message: Message,
// [... others edited for brevity ...]

and Message has
  /**
   * This is (always?) present in a `message` event; but we leave it out of
   * the `messages` subtree of the Redux state, moving the information to
   * the separate `flags` subtree.
   */
  flags?: string[],

and in fact we have some code in messageReducers.js that dutifully scrubs that flags property of action.message, and on the other hand flagsReducers.js goes and consults action.message.flags to get its information.
The question behind that question is of course: is there really also a flags property on the message itself, or have we just been wrong about that the whole time?

After fruitlessly searching the code, then testing a couple of ways, I'm pretty sure the answer is: there is no message.flags on these events. Which means our flags data is just always blank for messages we learn about in a narrow we're caught up in.

It is flags passed through the event itself.
So event.flags and not event.message.flags.

That is likely to keep the message object the same for all users.

Not sure what you mean by "it".
Did you read the comment I quoted?
  /**
   * This is (always?) present in a `message` event; but we leave it out of
   * the `messages` subtree of the Redux state, moving the information to
   * the separate `flags` subtree.
   */
  flags?: string[],

The only reason that's there in the type is because it's supposedly in the message on the event.

(Note from an audio discussion with Boris):
On the other hand, our MESSAGE_FETCH_COMPLETE actions do have a flags property on each message. Plus, that's really the natural place for it in the first place. So I think the right direction to fix this is:

The changes in this commit, plus:
Leave flags? on Message, but fix the comment to explain the correct situation.
Fix the code in messageReducers, flagsReducers, and possibly another place or two that is expecting to find this information in action.message.flags.

Added a commit intercepting the event and 'fixing' it.

// fixfixfix

This is not very helpful. :-) Is this a TODO? What should be "fixed" -- what would we rather be doing? Basically, when I look at this comment I don't know what I'm supposed to take from it / do about it. (That's actually true for me right now even though the context of this thread is fresh in my head -- it'll be more so for future readers, including future-me.)
This fix takes a different direction from what I described specifics for above. That's fine but it needs to take care of the appropriate details for this direction:

The comment on flags? in Message is still wrong and needs to be fixed.
Lower in this same eventMiddleware, we refer to event.flags; should be event.message.flags.
Are there other places that look at event.flags?
We should have the flags in just one place in the Redux action we're creating; if we're putting it on event.message.flags, then we should remove event.flags.

So... the // fixfixfix line is weird because I don't remember writing it (though I guess I did) and serves no purpose. Removed it.

Oh, I remembered what the // fixfixfix was supposed to be - I wanted to add a comment about the code added. Now did that.

Also reworked to move the key and not just duplicate it.
Not sure if it is better than just duplicating, but after some thought, also not sure it is worse.
So just did it.

Thanks for the updates, and the point-by-point replies! This is really helpful.

The comment on flags? in Message

So, here's how our Message type is documented:
/**
 * A Zulip message.
 *
 * This type is mainly intended to represent the data the server sends as
 * the `message` property of an event of type `message`.  Caveat lector: we
 * pass these around to a lot of places, and do a lot of further munging, so
 * this type may not quite represent that.  Any differences should
 * definitely be commented, and perhaps refactored.
...
 */
export type Message = { // ...
  /**
   * This is (always?) present in a `message` event; but we leave it out of
   * the `messages` subtree of the Redux state, moving the information to
   * the separate `flags` subtree.
   */
  flags?: string[],

So it's describing the data the server sends in that spot (the message property of an event of type message.) Where properties appear in this type without further discussion, we're saying they appear in the data the server sends.
And for flags, the comment specifically says we believe it appears there. We discovered in this thread that in fact it does not. That's why I say the comment is wrong.

Other than that, the first commit looks good! On the rest, just small comments:

The second commit adds tests for exactly the functionality the first commit added; let's squash it into the first commit.
In the third commit, the message seems unchanged. Given what we learned in this thread, I don't think it's accurate; it needs to be updated.

I don't think we need to necessarily link any change to the type comment with this PR being merged.
The change in eventMiddleware makes the data more in line with what we expect, not less.
We (I?) knew it even before this PR that the server does not send a flags key even for a /message GET - flags? indicate that it is optional. The flags key was missing for an empty flags array, which may or may not be a good idea (having flags: [] is definitely more orthodox)

Updated:

squished the first two commits, merging their commit message
updated the second commit's message

We (I?) knew it even before this PR that the server does not send a flags key even for a /message GET - flags? indicate that it is optional.

Well, that's not what the comment says -- it says it is there for events. Which it's not.
Also, what you "knew" is not true. :wink: The messages in a fetch result (which is from /messages) do have a flags key; that's in fact the only way we ever currently get flags. It's the reason one of those three messages in that screenshot does have the @-mention highlighting.
Which makes a very nice demonstration of why it's important that when we learn the answers to these questions, we write them down clearly.
(As does the bug this PR is fixing in the first place.)

The flags key was missing for an empty flags array

Hmm, why do you say that?
I just went and empirically checked, by watching the Chrome devtools' network tab on the webapp. The server sends flags: [] when there are no flags set, just like we'd both hope.
I'm interested in hearing why you say it was missing, because that suggests either (a) some exceptional case where it is indeed missing, which would be important to know, or (b) a source that's mistaken, which we should correct.

Your fix commit says:

In a previous commit we 'normalize' the incoming data, moving it to the
message object and now we can treat any message the same, no matter if
it got to the app via a GET /messages API call or as a new message
via the event system.

We don't actually handle /messages results here, though, right? Those generate MESSAGE_FETCH_COMPLETE actions, which I don't see a handler for in this reducer.

Merged -- thanks again @borisyankov ! I added a commit of my own to correct that jsdoc, as well as another to revise the Message jsdoc a bit more.
I had a couple of questions in my previous two comments -- those are independent of merging this PR, and I'm still interested in the answers.

The flags key was missing for an empty flags array

Hmm, why do you say that?

I did miss the fact that we are omit()-ting the flags key now.
Which means we should go ahead and omit even more keys that we don't use and split the keys into ApiMessage and InernalMessage (or just Message)
We are not using keys like: content_type, client, etc.

Ah, I see -- meaning you were looking at the message in the Redux state and saw that key wasn't there? That makes sense.

Which means we should go ahead and omit even more keys that we don't use and split the keys into ApiMessage and InernalMessage (or just Message)
We are not using keys like: content_type, client, etc.

Sure! I think separating the API's "message" type from our stored "message" type would be a good further improvement. For fields we don't use: I might be inclined to keep a few where it's at least clear what they mean and how/why we probably want to use them in the future, but there are a lot of them that I don't understand (and we don't use) or that I think I understand and they seem obsolete.
I do think keeping flags around was higher-risk, and removing it was higher-priority, than those, precisely because we do use the flags. Keeping them around meant keeping a stale copy of desirable information, which was a bug waiting to happen. But all these fields that we don't use are potential sources of confusion too.


Add Countries resource and User.mobile_allow_live_timetracking field

@AlGvrl Update README to flag the countries endpoint as done.


[Release] 4.0.1

This brings over version & changelog information from the 4.0.1 release, which was tagged off of a separate branch to which we cherry-picked bug fixes.

Codecov Report

Merging #313 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #313   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           5      5
  Lines         225    225
  Branches       22     22
=====================================
  Hits          225    225

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 2541632...43cceca. Read the comment docs.


Missing charms?

Throughout my playthrough I kept collecting charms and they would sometimes give me It and other times not. Most notably, Millibelle's Blessing and Marissa's Audience not showing up. Sometimes they would give the wrong icon or name too. Below is a picture of when I collected Marissa's Audience.

It never showed up in my inventory and the charm isn't there on reload.

Is there a debug or something I could use to get it? Or is it a conflict with another mod.

Now I tried getting the Bluemoth Wings and it gave me Snail Soul

Did you perchance install or remove any mod that adds extra charms after you started that savefile?

Not that I remember. Might've been Pale Court or Charm Crab.

Charm Crab could very well be it - it's known to not interact well with other mods that significantly change gameplay; even its README mentions that.

Ahh I see, thanks for the help.


Unable to pass data props to handler

In async example (https://github.com/rackt/react-router/blob/master/examples/async-data/app.js) we pass data to the handler:
React.render(<Handler data={data}/>, document.getElementById('example'));

But it seems that this isn't working anymore. The props sent are always {}
What's the best way to send data to the handler? (especially when pre-fetching async data)

It seems like the problem occurs because I'm rendering the view on the server-side. Anyone have an idea how to send the props when the application is isomorphic?

Question no longer valid since the problem was not in react-router. Issue can be removed.


Date Picker - Expanded view is not aligned with Input

@vasanth-appsmith I checked the story for the input component we are setting max-width: 250px that is why Input component is not aligning with the date picker.
So, how are we going to handle @vasanth-appsmith ?

I think we have to make it to 100% to the parent which is input

Ok @vasanth-appsmith understood.