feat: add support for lowercased context tags

what

add support for use lowercased context tags

why

not all cloud-providers supports the uppercased keys for tagging/labeling resources

/test all

yes, mostly agree with @Nuru .
We're interested in the general functionality of this PR, but want to work with you get the interface right since the implications are far-reaching and involve all 130+ terraform modules we manage.
We'll want to future proof it so that we can support multiple "cases" (e.g. titlecase, lowercase, uppercase, snakecase, camelcase, kebabcase, etc).  Also, a similar feature would be to add support for id_format (E.g. serverName instead of server-name) as well, so the ID could be encoded based on preferences.
So, I think something like what @Nuru proposes as the interface looks good.
Feel free to pin us in the #pr-reviews channel on slack for real-time discussion =)

I agree we need to be able to do it generically for many outputs (id, tags`).
But do we need to transform the values of the tags? They are completely controlled by the user.

@osterman I think we should start small and fill in the roadmap as demand arises. While this PR's feature is important for tags because currently we force Title Case on tag keys, generally I agree with @aknysh that the users have enough control on ID for now.
@SweetOps Thanks again for your contribution.
This is a lot further along, but not quite there. I think you misunderstood my proposal. The idea is that tag_format contains 2 components separated by the colon:

The first part is the formatting applied to the tag key
The last part is the formatting applied to the tag value

The default format would be "title:none". At a minimum, we would want to have formats

none
Title
UPPER
lower

(I want the formatting of the format name to reflect the format it selects, but do not want to do something crazy like nOne)
I think I would implement a sub-module that takes a map of maps and returns a map of maps of maps for with each formatting option.
input:
{
  tags: {
    tag_keys: {  name: "name" }
    tag_values: { name: "null-label" }
  }
}

output
{
  tags: {
    lower: {
      tag_keys: {  name: "name" }
      tag_values: { name: "null-label" }
    }
    Title: {
      tag_keys: {  name: "Name" }
      tag_values: { name: "Null-Label" }
    }
    UPPER: {
      tag_keys: {  name: "NAME" }
      tag_values: { name: "NULL-LABEL" }
   }
 }
}

@Nuru we should not change the tags output because that will "break the internet". The tags output should be the same as it is today. Rather tags, should be:
output "tags" {
  value = local.tag_formats[var.tag_format]
}

aha, @Nuru you are suggesting the interface for the submodule. That makes sense.

I was just about to open an issue for this, currently I can't use the tags on GCP because the keys must start with a lowercase letter. I hope this gets merged soon!

Hello, any news/plans regarding tag name formating?

Hello, any news/plans regarding tag name formating?

Stepping back again, I think this is way overkill. The initial issue/request was that we allow lowercase tag names instead of forcing them to Title Case. I think we should do that (plus add a third option for UPPERCASE) and stop at that.
This current PR, as I understand it, uses a tag format specifier of valueFormat:nameFormat where valueFormat is one of:

default (which leaves values unchanged)
snake
kebab
pascal
camel

and nameFormat is either lowercase or titlecase. (I find it confusing that valueFormat comes first, since we generally put keys before values, but that is minor and easily changed.) More importantly, it leaves out UPPER and lower as options for valueFormat. And this only applies to tags, not the ID, which means that the name tag's value will not match the id in many cases, which I find problematic.
In the fully exploded feature, we would have an idFormat variable of the form format and a tagFormat to be nameFormat:valueFormat where any of the formats could be:

none (no change from input, generated names/attributes are lower case single words)
Title
Upper
lower
Pascal
camel
snake
kebab

But for tag values, this opens up the question of what constitutes a word boundary, since this module gets fully formed values, unlike id where we get a set of words. Plus, no one has asked for it, since tag values are either generated according to some specification (such as Kubernetes-defined labels) or use user input which the user can capitalize any way they want. Also, we have no mechanism for singling out some tags for one format and some tags for another format (e.g. don't touch Kubernetes tags, but make the rest upper case) and I do not want to complexify this further by adding one.
Pascal, camel, snake, and kebab case only make sense for id (where we are given words), but then not even fully there. For id, kebab case is lower with our current default delimiter - (and is in practice our current default since we only feed in lowercase words), and snake is just lower with delimiter _ instead of -.
So I say we scale way back. Limit this PR to generatedTagNameCapitalization being one of

Title
lower
UPPER

with default "Title"
Let's keep it simple, get it done, and get it out.
Later, if there is demand, we can add a new PR with idCapitalization being one of

lower
UPPER
Title
Pascal
camel

and forming the id from the components appropriately. (Remember, kebab and snake are just lower plus choice of delimiter.) We can discuss the finer points of that feature then and there.

Stepping back again, I think this is way overkill. The initial issue/request was that we allow lowercase tag names instead of forcing them to Title Case. I think we should do that (plus add a third option for UPPERCASE) and stop at that.
This current PR, as I understand it, uses a tag format specifier of valueFormat:nameFormat where valueFormat is one of:

default (which leaves values unchanged)
snake
kebab
pascal
camel

and nameFormat is either lowercase or titlecase. (I find it confusing that valueFormat comes first, since we generally put keys before values, but that is minor and easily changed.) More importantly, it leaves out UPPER and lower as options for valueFormat. And this only applies to tags, not the ID, which means that the name tag's value will not match the id in many cases, which I find problematic.
In the fully exploded feature, we would have an idFormat variable of the form format and a tagFormat to be nameFormat:valueFormat where any of the formats could be:

none (no change from input, generated names/attributes are lower case single words)
Title
Upper
lower
Pascal
camel
snake
kebab

But for tag values, this opens up the question of what constitutes a word boundary, since this module gets fully formed values, unlike id where we get a set of words. Plus, no one has asked for it, since tag values are either generated according to some specification (such as Kubernetes-defined labels) or use user input which the user can capitalize any way they want. Also, we have no mechanism for singling out some tags for one format and some tags for another format (e.g. don't touch Kubernetes tags, but make the rest upper case) and I do not want to complexify this further by adding one.
Pascal, camel, snake, and kebab case only make sense for id (where we are given words), but then not even fully there. For id, kebab case is lower with our current default delimiter - (and is in practice our current default since we only feed in lowercase words), and snake is just lower with delimiter _ instead of -.
So I say we scale way back. Limit this PR to generatedTagNameCapitalization being one of

Title
lower
UPPER

with default "Title"
Let's keep it simple, get it done, and get it out.
Later, if there is demand, we can add a new PR with idCapitalization being one of

lower
UPPER
Title
Pascal
camel

and forming the id from the components appropriately. (Remember, kebab and snake are just lower plus choice of delimiter.) We can discuss the finer points of that feature then and there.

Objectives

Introduce a convention that will scale with the various case formats for id and tags outputs

Out of Scope

AWS, GCP do not put limitations on the formatting of tag values, so it's out of scope
Reformatting tags names to non-trivial cases like pascal and camel

Scope:

Add id_case

with a default of lower (current behavior)
supported values are one of: lower, upper, title, pascal, camel (all in lower-case)
respects the delimiter which can be set to an empty string
id output respects the id_case (can use map as part of implementation)

Add tag_case with a default of title (current behavior)

supported values are one of: lower, upper, title (all in lower-case; very trivial to support)
the tags output respects the tag_case (can use map as part of implementation)
the value of the name tag respects the id_case

Objectives

Introduce a convention that will scale with the various case formats for id and tags outputs

Out of Scope

AWS, GCP do not put limitations on the formatting of tag values, so it's out of scope
Reformatting tags names to non-trivial cases like pascal and camel

Scope:

Add id_case

with a default of lower (current behavior)
supported values are one of: lower, upper, title, pascal, camel (all in lower-case)
respects the delimiter which can be set to an empty string
id output respects the id_case (can use map as part of implementation)

Add tag_case with a default of title (current behavior)

supported values are one of: lower, upper, title (all in lower-case; very trivial to support)
the tags output respects the tag_case (can use map as part of implementation)
the value of the name tag respects the id_case

@osterman  I mostly like your revised proposal. As usual, I disagree with your choice of name, in this case inherit,  but we can work that out relatively easily, as we always do. My bigger concerns are, for id_case, "respects the delimiter which can be set to an empty string" and "the tags output respects the tag_case" These concern me.
As I pointed out before, kebab andsnake are both just lower plus a specific choice of delimiter. Similary, pascal is the same as title with no delimiter. camel is the only one that is slightly more complex, but again it implies no delimiter.
I would prefer to limit id_case to lower, upper, and title , from which thoughtful users can create snake, kebab, and Pascal case. Yes, this leaves camel out, which is OK with me because it is the most complex.
As for Tags, I think we should not allow any formatting of tag values, and we should not mess with the Tag Names of any tags supplied in the tags variable/context. Rather than  "the tags output respects the tag_case", we should have a limited generated_tag_case varaible that takes only lower, upper, or title and it should only apply to the names/keys of the tags the module generates (which is why inherit or none do not really apply). The value of the name tag is, as always, the value of the id output, which is the id formatted according to id_case and truncated by id_length_limit. (This brings up the extra consideration we need to make for the hash we append to the end of a truncated ID. The hash is hexadecimal, so it cannot be considered to work with Pascal or camel case, and we should probably introduce a hypen delimiter in those cases.)
As if we do not have enough to consider, this also brings up another design decision.  It would conceivably be better if we truncated by cutting out the middle and replacing the middle with a hash of the removed contents. Sort of like the idea behind i18n and k8s. Further, we could convert from hexadecimal to alphabetical, using the letters only, skipping ambiguous b, i, o, s, so we get something like a word that can be shoved into Pascal case.

@osterman  I mostly like your revised proposal. As usual, I disagree with your choice of name, in this case inherit,  but we can work that out relatively easily, as we always do. My bigger concerns are, for id_case, "respects the delimiter which can be set to an empty string" and "the tags output respects the tag_case" These concern me.
As I pointed out before, kebab andsnake are both just lower plus a specific choice of delimiter. Similary, pascal is the same as title with no delimiter. camel is the only one that is slightly more complex, but again it implies no delimiter.
I would prefer to limit id_case to lower, upper, and title , from which thoughtful users can create snake, kebab, and Pascal case. Yes, this leaves camel out, which is OK with me because it is the most complex.
As for Tags, I think we should not allow any formatting of tag values, and we should not mess with the Tag Names of any tags supplied in the tags variable/context. Rather than  "the tags output respects the tag_case", we should have a limited generated_tag_case varaible that takes only lower, upper, or title and it should only apply to the names/keys of the tags the module generates (which is why inherit or none do not really apply). The value of the name tag is, as always, the value of the id output, which is the id formatted according to id_case and truncated by id_length_limit. (This brings up the extra consideration we need to make for the hash we append to the end of a truncated ID. The hash is hexadecimal, so it cannot be considered to work with Pascal or camel case, and we should probably introduce a hypen delimiter in those cases.)
As if we do not have enough to consider, this also brings up another design decision.  It would conceivably be better if we truncated by cutting out the middle and replacing the middle with a hash of the removed contents. Sort of like the idea behind i18n and k8s. Further, we could convert from hexadecimal to alphabetical, using the letters only, skipping ambiguous b, i, o, s, so we get something like a word that can be shoved into Pascal case.

@osterman Correction, GCP does force tags to start with a lowercase letter.
So for me, it is very important that the none formatting be included or a formatting that only changes the first letter to lowercase.

@osterman Correction, GCP does force tags to start with a lowercase letter.
So for me, it is very important that the none formatting be included or a formatting that only changes the first letter to lowercase.

@osterman Correction, GCP does force tags to start with a lowercase letter.

@Sytten that's the tag names, but not the tag values. The tag values can be uppercase, etc.

@osterman Correction, GCP does force tags to start with a lowercase letter.

@Sytten that's the tag names, but not the tag values. The tag values can be uppercase, etc.

Okay, I agree with the points raised by @Nuru
Here's my summary for @SweetOps:

limit id_case to lower, upper, and title , from which thoughtful users can create snake, kebab, and pascal case. This leaves camel out, which is OK for now.

Do not allow any formatting of tag values

Do not modify tag names of any tags supplied in the tags variable/context.

Only modify tag names for generated_tags and  generated_tag_case varaible that takes only lower, upper, or title and it should only apply to the names/keys of the tags the module generates (which is why inherit or none do not really apply).

The value of the name tag is, as always, the value of the id output, which is the id formatted according to id_case and truncated by id_length_limit.

Do not change the way truncation happens today.

Okay, I agree with the points raised by @Nuru
Here's my summary for @SweetOps:

limit id_case to lower, upper, and title , from which thoughtful users can create snake, kebab, and pascal case. This leaves camel out, which is OK for now.

Do not allow any formatting of tag values

Do not modify tag names of any tags supplied in the tags variable/context.

Only modify tag names for generated_tags and  generated_tag_case varaible that takes only lower, upper, or title and it should only apply to the names/keys of the tags the module generates (which is why inherit or none do not really apply).

The value of the name tag is, as always, the value of the id output, which is the id formatted according to id_case and truncated by id_length_limit.

Do not change the way truncation happens today.

@osterman I left out id_case of none by mistake. I think we should allow it, as users have full control over all the inputs except attributes, so they can implement whatever format they want and we should leave it alone.
Reflecting on it, I think we should name the variable generated_tag_name_case instead of generated_tag_case.
Also, you left out defaults, which for backwards compatibility should be

id_case = "lower"
generated_tag_name_case = "title"

If it is OK with you, I will edit your comment to incorporate these changes so it remains the reference.

@osterman I left out id_case of none by mistake. I think we should allow it, as users have full control over all the inputs except attributes, so they can implement whatever format they want and we should leave it alone.
Reflecting on it, I think we should name the variable generated_tag_name_case instead of generated_tag_case.
Also, you left out defaults, which for backwards compatibility should be

id_case = "lower"
generated_tag_name_case = "title"

If it is OK with you, I will edit your comment to incorporate these changes so it remains the reference.

@SweetOps Please take note of updated requirements here (I made some modifications just now, with @osterman's approval.)

@SweetOps Please take note of updated requirements here (I made some modifications just now, with @osterman's approval.)

@osterman @Nuru, take a look pls

@osterman @Nuru, take a look pls

/test all

/test all

/test all

/test all

/test all

/test all

/test all

/test all

@Nuru @SweetOps: Ok, let's do some "final" =) renaming:

id_case to label_value_case (applies to all the values of standard input labels)
generated_tag_name_case to label_key_case (applies all the key names of standard input labels)

standard input labels:

namespace
environment
stage
name (which is used for id)
attributes

@Nuru @SweetOps: Ok, let's do some "final" =) renaming:

id_case to label_value_case (applies to all the values of standard input labels)
generated_tag_name_case to label_key_case (applies all the key names of standard input labels)

standard input labels:

namespace
environment
stage
name (which is used for id)
attributes

/test all

/test all

/test all

/test all

/test all

/test all


Update IntegrationWithExistingApps.md

Makes sure a recent version of react native is used by specifying that at least version 0.49 should be used for Android. Otherwise an old 0.20.1 version hosted in jcenter might override the version included from node_modules.
Motivation
Ending up with an ancient version of react native might be confusing to new users trying out react native for the first time.
Test Plan
NA
Release Notes
[DOCS] [MINOR] [IntegrationWithExistingApps.md] - Make sure a node_modules version of react native is used

Can you tell us a bit more about why such an old version may be used? If we can fix that, it'd be ideal. I don't want to have to update this doc every time we release a new version (0.49 will be considered too old at some point).

If react native is added after jcenter() in a gradle file it will use a 0.20.1 version hosted by the Facebook organization there. My guess is that jcenter() was used for distribution before but npm was chosen instead in mid july this year?
This gradle file would install version 0.20.1 of react native:
    repositories {
        jcenter() // Included in default android projects
        maven {
            url "$rootDir/../node_modules/react-native/android"
        }

If you move jcenter() after the npm installed react native repository it works however. But I thought it would be helpful for other developers specifying a version later than 0.20.1 which then would automatically skip the jcenter() version.
But maybe it is a bad idea to mention a specific version even if it has the greater than tag. How about changing the gradle section to this? I.e specifically mentioning jcenter and moving "..." below the npm react native repository?
allprojects {
    repositories {
        maven {
            // All of React Native (JS, Android binaries) is installed from npm
            url "$rootDir/node_modules/react-native/android"
        }
        ... // Other maven repositories such as `jcenter()` goes here
    }
    ...
}

Thanks for the contribution. The docs have moved to their own repo at facebook/react-native-website. I've applied your change over there.


Checkpoint folder is empty

Hello, I am running, nni/test/retiarii_test/darts/test.py script. I can see result on webUI, after all trials are finished, I cannot obtain the trained model and checkpoint files in directory nni-experiment/my_exp_id/checkpoint/ folder.
How to obtain the best pytorch model?
Thanks,

In nni/test/retiarii_test/naive/lightning_logs/version_x/checkpoints/ folder, I could find the pytorch checkpoint file,
By running python search.py  --exec graph --budget 20, I can obtain python script as plain test (that defines the best model).
However, when I use this script with above checkpoint, and do evaluation, by loading:
PATH = "nni/test/retiarii_test/naive/lightning_logs/version_x/checkpoints/epoch=9-step=1199.ckpt"
checkpoint = torch.load(PATH)
model.load_state_dict(checkpoint['state_dict'], strict=False)

it seems every time I run the scripts, evaluation results are different, (I also used generated onnx file to evaluate, but onnx's evaluation output is the same every time)
If I set model.load_state_dict(checkpoint['state_dict']), it raises a error:
File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1051, in load_state_dict
raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
RuntimeError: Error(s) in loading state_dict for _model:
Missing key(s) in state_dict: "_model__conv1.weight", "_model__conv1.bias", "_model__conv2.weight", "_model__conv2.bias", "_model__fc1.layerchoice_fc1_choice_0.weight", "_model__fc1.layerchoice_fc1_choice_0.bias", "_model__fc2.weight", "_model__fc2.bias".
Unexpected key(s) in state_dict: "model._model__conv1.weight", "model._model__conv1.bias", "model._model__conv2.weight", "model._model__conv2.bias", "model._model__fc1.layerchoice_fc1_choice_0.weight", "model._model__fc1.layerchoice_fc1_choice_0.bias", "model._model__fc2.weight", "model._model__fc2.bias".
while I run retiarii with web UI, model accuracy was 0.97 something. Now, even onnx model cannot reach to that score.
what is the problem?

Hi, sorry for the late reply. The code from test/retiarii_test is only for automatic integration test. We suggest to use example code of DARTS from https://github.com/microsoft/nni/tree/master/examples/nas/oneshot/darts.


Upload script is very slow

Short Description
It takes over 20 minutes for the upload_data.py script to run due to waiting for each dataset to finish uploading and be sent to the archive before starting the next dataset upload.
Can we speed this up by sending all the datasets to be uploaded before being sent to the archive?
Evidence/Steps to Reproduce
No response
Acceptance Criteria/Expected Behaviour
No response
Details
No response
Resolution
No response

Options include:

[ ] Slower to run sequentially, but could have 2 separate hosts files i.e.  hosts_1.yml and hosts_2.yml
[ ] Faster to run, but more work is putting all the groups i.e. xnat_web_1 and xnat_web_2 into the same hosts file i.e. hosts.yml
[ ] Group_vars templates could be modified to achieve this


Replaced Mob with LivingEntity in shape abilities

This pull request would allow other mods to use these abilities regardless of the player's shape.

Do you already have some mod in mind that could use the ShapeAbilities? Maybe we can improve the API further.

Thanks for the quick response and for merging the changes!
I am currently developing Shappoli, an Origins addon, part of which integrates with your mod. I made an execute_shape_ability action that makes use of those abilities, here is an example: ExplosionShapeAbility.
It would be great to make the ID field required not only for GenericShapeAbility but for all ShapeAbility, this would allow data-driven systems like Origins to check if an entity has a specific ability.
Also, it would be nice to allow mods to easily subscribe to the ability.onUse() method with Mixins either by making it empty in ShapeAbility and all child classes calling super() on it or moving this part of the networking code to some utility method.

You can safely reject the make ShapeAbilities call super.onUse() commit if you don't like it as I am not sure if I like it myself

I didn't know you had an event system like that, I think I can remove most mixins from my code thanks to it! 🤔

I think this should do it

Thanks, I'll look into it! Not sure if I want to globally disable some of the mod features though. I'll make sure to open a new pull request if I add anything useful :>
My MC username is Shap_po

I've added you :D


Implementation of signature based methods.

This PR implements two classes for time series analysis with signatures:

GeneralisedSignatureMethod Transformation class for generating signatures from time-series data.
SignatureClassifier Wraps the above method with a tabular ML classifier.

The structure of the GeneralisedSignatureMethod follows closely from this work in this paper.
This adds esig as a soft dependency.

hi, thanks for updating this PR, its failing some of the automated tests. I'll discuss this with Markus and see if we can suggest solutions, I'd really like this in the toolkit

Sorry it's taking ages, there have been a host of issues with each different signature package I tried.
I should be one esig update away from tests passing though. The only remaining issue is some import fault in esig rather than an installation problem. The developers are aware and it should be sorted in the next update.
Give me two weeks, then if tests are still not passing we should discuss.

no problem, I feel you pain :) And no rush, but if you need assistance give us a shout.

At long last, everything seems to be working. However, as can be seen, it's not finishing the tests for macos. Do you know whats going wrong here?

Hi @jambo6, GitHub now requires approval from first-time contributors to run CI checks, just approved it now.

Quick question: is SignatureClassifier not redundant with pipelining that we already have?
I.e., just stick the GeneralisedSignatureMethod and classifier together.

I like to have specific classifiers for transformers for evaluation purposes. For example we put in the RocketClassifier so that we can concretely  point to the classifier we have evaluated. I would prefer it stay in. And @jambo6 well done on sticking with it, we really appreciate the effort involved

SignatureClassifier is effectively redundant, but it was so as to keep inline with with other things all having Classifier at the end. I've no strong feelings with regards to how the signature module should be laid out though, so am happy to edit/remove anything if you ever want me to.
Do I need to do anything else for this at the moment?

This looks really great!
Looks almost ready to be merged.
Quick remarks:

you should add new transformers and estimators to sktime.tests._config - add the new estimators, and some reasonable parameter combinations
I like your decorators aroudn fit and predict. We've been internally disussing how to deal with the various conversions, see the related PR #980 and discussion for forecasting. Perhaps you have some good ideas?

I like your decorators aroudn fit and predict. We've been internally disussing how to deal with the various conversions, see the related PR Forecasting support for multivariate y and multiple input/output types - working prototype #980 and discussion for forecasting. Perhaps you have some good ideas?

Perhaps a file that has a selection of decorators that provide conversions for fit/transform methods to a specific type? For example the decorators convert any pandas input to numpy and convert back. It would be good to have some logic that can convert between sktime formats under the hood, so the code in any fit/transform only needs to consider one particular format.
@mloning I have updated the docs and made the edits according to your comments.

but the tests don't all pass! It somehow destroys the test examples

it's just some import error that should be easily fixable, @jambo6

sorry, clustering has introduced minor conflicts I think

Now merged @jambo6 - thanks again, great work!


[Test]

Codecov Report

Merging #1 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master     #1   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines         174    184   +10
=====================================
+ Hits          174    184   +10

Impacted Files
Coverage Δ

index.js
100% <100%> (ø)
:arrow_up:

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 8aa3d19...f8cad30. Read the comment docs.


Fix config search

This PR is dependent on #281. That one should be merged first.

It looks like the config_search is currently not working at all, in the master (v1) branch.
This adds a more reliable way of searching for buildozer files and adding it to the gulp config.

Tested and looks good! OK to merge to master for me, will discuss later before doing so.


typo: applicationinsights data-lane and resource-manager

metatadata -> metadata
assmebly -> assembly
doens't -> doesn't
reponse -> response
createion -> creation
Applciation -> Application
aditional -> additional
an workitem -> a work item
detaile d -> detailed
defintions -> definitions
definitioned -> definitions

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-js

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-node

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go


feat: permanent cancel button on ion-searchbar

Feature Request
Ionic version:

[x] 4.x
Describe the Feature Request

Being able to keep the cancel button of the ion-searchbar visible, even when there's no focus on the searchbar. Comportment of the button doesn't change.
Describe Preferred Solution

A simple attribute would do the trick: <ion-searchbar permanentCancelButton></ion-searchbar>.
Additional Context

Use case: A user clicks on a search icon in the toolbar; the toolbar is dismissed to give space to the invoked searchbar. Now the user needs a way to go back to the previous toolbar if the searchbar is not focused.

Hi there,
Thanks for the feature request. Can you explain your use case a bit more? I'm not sure I fully understand the benefit of having the Cancel button always visible even if the input is not focussed.
Thanks!

Sure @liamdebeasi ! Have a look at the following GIF, it's showing the latest comportment of the Facebook search bar that I was trying to reproduce. Imagine this with the actual implementation in Ionic: we click on the search icon, and end up with the expanded search bar. If the user clicks on anything but the bar, it will lose its focus, hence leaving the user with no way of getting back to the previous screen with the search icon (except clicking again on the bar to let the cancel button appear, but it's really bad in terms of UX). Hence the permanent cancel button that would be needed in that case.

Hi there,
Thanks for the follow up! The behavior in the GIF is actually just autofocusing the searchbar when it appears, which is why the cancel button is visible.
I am going to close this issue, but I think this functionality could be accomplished with the following feature request: https://github.com/ionic-team/ionic/issues/17745.
Thanks for using Ionic!

Hi @liamdebeasi, I think you closed it too soon. Let me explain:
Agreed, it is autofocus, and that's why the cancel button is visible. However, when we loose the focus (like in this new GIF, the user simply clicks on the background), the cancel button disappears, leaving the user with the search bar, but no way to come back to the other interface except clicking on the bar again, and hitting cancel.
Of course, I could also dismiss the search bar when (ionBlur) fires, but in my case, I'd rather not, because I want the search bar to stay until the user explicitly clicks on cancel. Hence the permanent cancel button, that stays whether the search bar is focused or not.
If you agree with me on that, my PR might also be reopened (#18401).
Here's the GIF:

Ahh you're right - I misunderstood your previous explanation. Reopening!
I will take a look at your PR shortly. 👍 Thanks for clarifying!


Implement approvals in IGSDB

Approvals are a cryptographic signature which states that the data sets fulfills certain requirements. They will be used by software applications to filter suitable high-quality data sets.
Currently we think about approvals for NFRC and AERC and possibly for LBNL research level and generic records.

ISE will prepare a proposal.


Handle lowercase project ids

Fixes bug #34 (Workzone plugin does not handle lowercase project ids), and also bug #58 (bitbucket does not preserve ssh key order).

Note to @klarna-incubator/kred-core reviewers: this has been tested internally at Klarna (see the sync-with-upstreams branch in tools-bec).


about evaluation

tkank you for you nice work. could you tell us what evaluation code do you use? please

Thank you, the evaluation code is provided by the F3Net https://github.com/weijun88/F3Net/tree/master/eval

Thank you, the evaluation code is provided by the F3Net https://github.com/weijun88/F3Net/tree/master/eval

Thank you most sincerely


[Android-Build NDK] CMake license problem

Bitrise Build Issue Report template
Description of the issue
I got this message from gradle when I want to compile
Caused by: java.lang.RuntimeException: You have not accepted the license agreements of the following SDK components:
[CMake 3.6.3155560].
Before building your project, you need to accept the license agreements and complete the installation of the missing components using the Android Studio SDK Manager.
Environment:
Where did the issue happen?
It happen with the gradle command assembleRelease(and other type)
If on Bitrise.io: which stack? If not on Bitrise.io: on what operating system? (Plus any other information you can share) Linux Android
Which build Step causes the issue and which version of the step?
unit test => gradle compilation
bitrise-build-09e4d25b16c46b8e.txt
Reproducibility

Does a "Rebuild" help? (You can trigger a rebuild from the Build's page, by clicking the "Rebuild" button in the top right corner of a finished build) : NO
Does a rebuild without caches help? (You can remove the Cache:Pull and Cache:Push steps temporarily to not to use the cache, or you can delete all the caches on the Settings tab of the app. : NO
If you have multiple different build configurations (workflows), does the issue affect all/more than one? : YES
If it's an issue which happens sporadically, what's the frequency? (e.g. Once a day ; about x% of the builds) : every builds
Does upgrading the build Step to the latest version help? : YES/NO
When did the issue start? :

Linux/Android stack builds
Can it be reproduced by running the build locally, after doing a clean git clone (git clone the repository, into a new directory, somewhere on your Mac/PC) and running the build from there with the Bitrise CLI ( https://www.bitrise.io/cli )? If no, can it be reproduced with Docker (using the same docker images / environment we use on bitrise.io)? Related guide: https://bitrise-io.github.io/devcenter/docker/run-your-build-locally-in-docker/ .
Other stacks
Can it be reproduced by running the build locally with our CLI ( https://www.bitrise.io/cli ), after doing a clean git clone (git clone the repository, into a new directory, somewhere on your Mac/PC) and running the build from there with the CLI ( https://www.bitrise.io/cli )?
Build log
Please attach the build log (you can download the build log from the build's page,
once the build is finished, using the "Download log" button - floating at the bottom right corner of the log viewer),
or if you can't attach the whole log then send the full log through a private channel (e.g. email - https://www.bitrise.io/contact ), with a link to the related GitHub issue.

Hi,
You have to copy/provide the licenses for the packages which are not preinstalled but required/installed for your project or build.
You can find more information here: http://devcenter.bitrise.io/android/frequent-android-issues/#alternative-solution-for-the-license-error
Let us know whether that helps!

Hi @viktorbenei,
Effectively it helps me but now i'm face to
Caused by: java.lang.NullPointerException 	at com.android.builder.sdk.DefaultSdkLoader.installSdkTool(DefaultSdkLoader.java:570)
for running the android unit test.
I join the log file
77fec3a41a51affe.txt
Do I miss something else ?
Because before the tests was passing this step.

Try to do a clean git clone, into a new directory on your Mac/PC, and run the gradlew command there. Do you get the same error?

I got this
`FAILURE: Build failed with an exception.

What went wrong:
A problem occurred configuring project ':app'.

SDK location not found. Define location with sdk.dir in the local.properties file or with an ANDROID_HOME environment variable.`

In Android studio I have the local.properties but it aim my local SDK, I was thinking that the Bitrise Machine has 'ANDROID_HOME'  env variable ?

The Bitrise Android/Xamarin stacks do have the ANDROID_HOME env set.

But locally you might not - in that case set it with export ANDROID_HOME=/path/to/android/sdk before running gradlew

I have done this and now it failed because it doesn't found.
> NDK not configured.   Download it with SDK manager.)

Then set the ANDROID_NDK_HOME var too, like the ANDROID_HOME one

Then it worked BUILD SUCCESSFUL

So I have to define ANDROID_NDK_HOME and ANDROID_HOME with a script ?
Can you give the right paths ?

No, you don't have to define those, those are already set.
Can you try to build on a different Mac/PC? This error is usually a project configuration issue, but hard to tell what causes it - on your own Mac/PC you might have a cached version of a resource which makes it pass, which is not available in your repo/on another Mac/PC.
See these for example:

http://stackoverflow.com/questions/40108471/java-lang-nullpointerexception-no-error-message-apk-building
http://stackoverflow.com/questions/39183674/java-lang-nullpointerexception-no-error-message
http://stackoverflow.com/questions/39226834/errorjava-lang-nullpointerexception-no-error-message

And https://www.google.com/?gfe_rd=cr&ei=5MJSWOPpKaat8wfBvIfoCQ&gws_rd=cr&fg=1#safe=off&q=java.lang.NullPointerException+(no+error+message) in general

I try to do it on a different Mac, it works, the Mac didn't have java installed on it but after installing it and the SDK, NDK (exporting ANDROID_NDK_HOME and ANDROID_HOME), i start the ./gradlew inside the freshly cloned project and it worked... I don't know what to do because, this can eliminate a problem of gradle cache or misconfiguration of the project.

Which Java version do you use?

JDK 1.8

java -version  java version "1.8.0_92" Java(TM) SE Runtime Environment (build 1.8.0_92-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

Did you try to do a build with Docker, as described here https://bitrise-io.github.io/devcenter/docker/run-your-build-locally-in-docker/ ? It should definitely help in reproducing the issue locally.
Is there any way we could reproduce this issue? e.g. a sample repository you could share with us?

No sorry it's my company app so I can't but I will try to do it locally on the docker machine. I will let you know. Thank you for your time ! :)

Sure, let us know how it goes, and if we can help with anything!

Closing as we did not receive a reply - @mbertin please let us know if we can help with anything and we'll reopen this issue!

Hello @viktorbenei,
I try to do it locally and I have met this error...
In order to locate the problem, i started a new project with this gradle file
`apply plugin: 'com.android.application'
android {
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "com.igraal.testbitrise"
minSdkVersion 16
targetSdkVersion 25
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
externalNativeBuild {
cmake {
cppFlags ""
}
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
externalNativeBuild {
    cmake {
        path "CMakeLists.txt"
    }
}

}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})
compile 'com.android.support:appcompat-v7:25.1.0'
testCompile 'junit:junit:4.12'
}
`
I fix the license problem by copying pasting my proper licenses following the bitrise doc about it.
And I have the same bug, I think the problem is about the cmake command install that failed on the docker... I don't see how to fix it... Do you have any project that use cmake working on docker ?
This is the new repository if you want to test, it's just a new project created by Android studio with the android-licenses folder
https://github.com/mbertin/testBitriseAndroid

I notice that by commenting the externalNativeBuild part in the gradle file, it works !

Good catch @mbertin !
Btw, did you get the same error in this new project?

Yes i Got the same error which is

A problem occurred configuring project ':app'.
java.lang.NullPointerException (no error message)

and the stacktrace from gradle :

Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':app'.
at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:79)
at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:74)
at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:61)
at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:540)
at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:93)
at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:47)
at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:35)
at org.gradle.initialization.DefaultGradleLauncher$2.run(DefaultGradleLauncher.java:124)
at org.gradle.internal.Factories$1.create(Factories.java:22)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:121)
at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32)
at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98)
at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99)
at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30)
at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81)
at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:52)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:37)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.health.DaemonHealthTracker.execute(DaemonHealthTracker.java:47)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:72)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.health.HintGCAfterBuild.execute(HintGCAfterBuild.java:41)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:237)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
Caused by: java.lang.NullPointerException
at com.android.builder.sdk.DefaultSdkLoader.installSdkTool(DefaultSdkLoader.java:570)
at com.android.build.gradle.internal.SdkHandler.installCMake(SdkHandler.java:300)
at com.android.build.gradle.tasks.ExternalNativeJsonGenerator.create(ExternalNativeJsonGenerator.java:626)
at com.android.build.gradle.internal.TaskManager.createExternalNativeBuildJsonGenerators(TaskManager.java:1225)
at com.android.build.gradle.internal.ApplicationTaskManager$11.call(ApplicationTaskManager.java:219)
at com.android.build.gradle.internal.ApplicationTaskManager$11.call(ApplicationTaskManager.java:216)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:156)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:120)
at com.android.build.gradle.internal.ApplicationTaskManager.createTasksForVariantData(ApplicationTaskManager.java:214)
at com.android.build.gradle.internal.VariantManager.createTasksForVariantData(VariantManager.java:485)
at com.android.build.gradle.internal.VariantManager$3.call(VariantManager.java:293)
at com.android.build.gradle.internal.VariantManager$3.call(VariantManager.java:290)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:156)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:120)
at com.android.build.gradle.internal.profile.SpanRecorders.record(SpanRecorders.java:44)
at com.android.build.gradle.internal.VariantManager.createAndroidTasks(VariantManager.java:286)
at com.android.build.gradle.BasePlugin$11.call(BasePlugin.java:688)
at com.android.build.gradle.BasePlugin$11.call(BasePlugin.java:685)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:156)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:120)
at com.android.build.gradle.BasePlugin.createAndroidTasks(BasePlugin.java:683)
at com.android.build.gradle.BasePlugin$10.call(BasePlugin.java:608)
at com.android.build.gradle.BasePlugin$10.call(BasePlugin.java:605)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:156)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:120)
at com.android.build.gradle.BasePlugin.lambda$createTasks$1(BasePlugin.java:603)
at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:93)
at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:82)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:44)
at org.gradle.internal.event.BroadcastDispatch.dispatch(BroadcastDispatch.java:79)
at org.gradle.internal.event.BroadcastDispatch.dispatch(BroadcastDispatch.java:30)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy11.afterEvaluate(Unknown Source)
at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:67)
... 52 more

And without the externalNativeBuild part it builds correctly & generates the right APK?

Yes it builds and generates the APK.

Good catch @mbertin and thanks for sharing the info!
I wonder why externalNativeBuild makes it fail though..

@viktorbenei I don't understand because on mac it works... Maybe it's the version of GCC or something else. Let me know if you find the solution.

Sure, we definitely will @mbertin ! Thanks again for the infos! ;)

Hi @viktorbenei !
Do you have any news about my issue ?

We didn't have the time to explore this, mainly because you said it works correctly if you remove externalNativeBuild.

Yes but I need it for my company because now we can't use bitrise on the Android project...

I just registered https://github.com/mbertin/testBitriseAndroid on bitrise.io, and I got a green build O_O

really ?

Yeah, but I just checked and you commented out the externalNativeBuild bits in the project

yes, I let the commit but if you checkout on the previous commit it will failed.

Hi @viktorbenei ,
I have found a solution about this problem... I use an older version of gradle
classpath 'com.android.tools.build:gradle:2.2.2'
instead of
classpath 'com.android.tools.build:gradle:2.2.3'
And the problem is gone.

Thanks for reporting @mbertin !!
Hmm.. That's super strange, especially because the project did work on my Mac too, without any change, full clean clone etc.
I'll still try to dig into this, to see if this might be related to how the NDK is installed in the docker image. I suspect that maybe it might be related to the pre-installed CMake version: https://github.com/bitrise-docker/android-ndk/blob/master/Dockerfile#L33 - related discussion: https://github.com/bitrise-docker/android-ndk/pull/20
It's quite unfortunate that the android update sdk command does not have the CMake package, so that it have to be installed "manually", which is always prone to errors or might break if they decide to change something..
Anyway, thanks again for the info, and I'll try to debug this a bit more. It seems today I'll finally have some time to try to play around with this ;)

@mbertin you won't believe what the solution is. Simply:
rm -rf ${ANDROID_HOME}/cmake

To remove the default cmake install.
We'll do a couple of additional tests to see if we should remove the default cmake install from the Docker image completely.

@viktorbenei really ? Thank you for the time you spent on it !
Now I can build ! ^^

Well, it worked with the sample you provided (if I re-enabled externalNativeBuild in my code, where it initially failed, but after rm -rf ${ANDROID_HOME}/cmake it worked) :)
https://github.com/viktorbenei/testBitriseAndroidNDK / https://github.com/viktorbenei/testBitriseAndroidNDK/blob/master/app/build.gradle#L27

Hi @viktorbenei,
I'm replacing @mbertin at work. I found out that our builds are not successful since your last update on android-ndk. It is related to CMake again...
I found a workaround by using the previous release of the android-ndk. I hope it will be fixed soon, so I can keep updating my CI.
Just wanted you to know, thanks !

@AthanaseKa what was the error you got?

@viktorbenei I had different errors depending on the gradle version.
With gradle 2.2.1 & 2.2.2:
`A problem occurred configuring project ':app'.

Failed to find CMake.
Install from Android Studio under File/Settings/Appearance & Behavior/System Settings/Android SDK/SDK Tools/CMake.
Expected CMake executable at /opt/android-sdk-linux/cmake/bin/cmake.`

With gradle 2.2.3:
`A problem occurred configuring project ':app'.

You have not accepted the license agreements of the following SDK components:
[CMake 3.6.3155560].
Before building your project, you need to accept the license agreements and complete the installation of the missing components using the Android Studio SDK Manager.
Alternatively, to learn how to transfer the license agreements from one workstation to another, go to http://d.android.com/r/studio-ui/export-licenses.html
`

Can you try to use 2.2.3 and provide the license, as described here http://devcenter.bitrise.io/android/frequent-android-issues/#alternative-solution-for-the-license-error ?
@mbertin 's sample does include this license, if that helps: https://github.com/mbertin/testBitriseAndroid

I've added the license and everything appears to be working well.
Thanks a lot !

Awesome, I'm really glad to hear that @AthanaseKa ! :)


Inquiries about the feature "group a scene" support

Thank you for sharing the source code of the annotation tool.
I was wondering if there are any plans to add a feature that groups data included in the [Xtreme1 online version](https://app.basic.ai/#/login/). This feature would be helpful for more users to utilize Xtreme.

Hi Siyeong-Lee!
Scene feature currently is only available on BasicAI cloud version.
For open source Xtreme1 project, the next update will be 3D segmentation feature.

@nicozhan Thank you!


Handle a scenario where the same trackable is being added multiple times

Since we work in a multi-threaded environment we should properly handle a scenario where the same trackable is being added at the same time from multiple places. Currently in that case each add operation would call all methods and try to connect to Ably channels etc. What should happen is the trackable adding steps should be called only once and all the other add operations should simply wait for the result of the first one.
On Android, we handle the situation with the help of the DuplicateTrackableGuard that makes sure only one add operation is being executed. All other add calls will be added to a list and notified when the first operation finishes and what was the result of that operation.

Just to explain how this is different to https://github.com/ably/ably-asset-tracking-swift/issues/340. Adding a trackable is an asynchronous operation that can last several seconds. This issue relates to the behaviour if you try and add a trackable whilst an add operation for a trackable with the same ID is still in progress, whereas #340 is about if you try and add a trackable when one with the same ID has already completed being added.

This should be done alongside #341 as they'll probably require the creation of similar mechanisms.

I'm unassigning this from myself since I'm not actively working on it. My work-in-progress can be found at https://github.com/ably/ably-asset-tracking-swift/compare/main...341-same-trackable-being-added-multiple-times (it's based on top of #440).

The corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2595


Incorrect title HTML element in package documentation generated by ceylon doc

When viewing package documentation generated by ceylon doc, the title element of the HTML looks like "Package [x, y, z]" instead of "Package x.y.z" because the (Java) code in org.eclipse.ceylon.model.typechecker.model.Package.getName() returns a List<String>, which the code in org.eclipse.ceylon.ceylondoc.PackageDoc.generate() passes to writeHeader().

Fixed, thanks.


Standard Frameworks

I wanted to ask some questions about the architecture of the project in general.  Is there a reason to not use standard python frameworks/test runners/build tools for HPO?
For example, rather than hand-crafting a REST endpoint based on a HTTP server, would it make sense to use something like Django Rest/Flask?
Similarly with unit/integration tests, would it make sense to use a standard python library for creating and running tests?

Hi @johnaohara, great Q and yes ideally we should move to Standard Frameworks. The current choices are primarily due to historic reasons. Early in the Autotune project, we had both optuna and java code bundled into the same docker image and at that time the goal was to keep it simple as well as make sure that the size of Docker image was manageable.
Those points are no longer relevant and we are now free to move to Standard Frameworks functionally as well as for the tests


Poll: do you need a version of this library in Swift UI?

Please react with 👍 if yes and 👎 if no.
Thank you

I am curious if anyone has found a solution to using this library in SwiftUI yet?

I am curious if anyone has found a solution to using this library in SwiftUI yet?

It is kinda hard to get stuff like this working in SwiftUI. I mostly prefer screens over which I need more control written in UIKit. And this tags field goes into one of those screens. So I'm happy either way.

I am curious if anyone has found a solution to using this library in SwiftUI yet?

Use UIViewRepresentable.


IE11 fix using lodash .find (#106)

IE11 Fix
Description
Fix for IE11 not supporting .find method on arrays. Fix provides replacement with .find method from lodash collection.
Extended dependency increases size of ACDL from 31 325 B to 32 307 B.
Related Issue
Fixes #106

LGTM. How come was it not detected by our browser support tests? Do we need to fix them too?


Get progress percentage

Hi,
I want to display a progresa bar when I upload a big file.
My file is converted to base 64 before sending it.
I saw this plugin who do that (not tested yet): https://www.npmjs.com/package/angular-progress-http
Or angular documentation: https://angular.io/guide/http#listening-to-progress-events
Is there a way to do that with nswag studio?

ATM there is no way to do this, and I think it is also too specific to support exactly this library... You should exclude the given operation and implement it manually with extension code...


Running composer tests fails with error from CodeSniffer

Environment details

OS: MacOS Big Sur 11.6
PHP version: PHP 8.0.12

Steps to reproduce
From project root (google-cloud-php) running:
composer install
composer tests

results in the following error:
> dev/sh/tests
Running PHPCS Code Style Checker
PHP Fatal error:  Array and string offset access syntax with curly braces is no longer supported in /Users/danom/code/googleapis/google-cloud-php/vendor/squizlabs/php_codesniffer/CodeSniffer/CLI.php on line 453

Fatal error: Array and string offset access syntax with curly braces is no longer supported in /Users/danom/code/googleapis/google-cloud-php/vendor/squizlabs/php_codesniffer/CodeSniffer/CLI.php on line 453
Script dev/sh/tests handling the tests event returned with error code 255

Changed PHP version to 7.4
brew install<EMAIL_ADDRESS>brew unlink<EMAIL_ADDRESS>&& brew link --force --overwrite<EMAIL_ADDRESS>composer tests

Tests now run however the result is:
ERRORS!
Tests: 8569, Assertions: 4804, Errors: 5067, Failures: 5, Skipped: 809.
Script dev/sh/tests handling the tests event returned with error code 2

This must be a local development issue, as I was able to run dev/sh/tests locally and it succeeded.
I'm closing this for now as I can't duplicate an issue.


Remove redundant words from a few messages

The way they're phrased sounds a bit odd, although the intended meaning was clear.

Coverage remained the same at 25.952% when pulling f35cf1fe4a1277d2bf7f6a8b30d1399f90d651bd on jfkthame:patch-1 into 241b8b1309145bbe1158a088b71680f765dbb07c on mozilla:master.

Thanks for doing that.


Add reference to LOGIN_REDIRECT_URL to readme.

Description
The readme on github was missing a reference to LOGIN_REDIRECT_URL, as seen on readthedocs. I simply added the redirect url for new users of the repo.
Motivation and Context
This change will help new users get the project running quicker.
How Has This Been Tested?
No tests necessary
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

I've removed installation instructions from the README and now point to the full instructions in the documentation.


use staging assets for staging cli release e2e tests

Issue #, if available:
Description of changes:
Use the assets pushed by the staging release process to run the staging e2e tests during staging CLI release; this will allow us to run the following release flow:

staging bundle build
staging cli build
prod bundle build
prod cli build

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm
/approve


Uncaught exception ModuleNotFound: Module unittest was not found

im running linux mint 17
after udo make prefix=/usr/local install
i try
echo 'echo "Hello World"' > hello_world.sh
^_^ james 0 546 ~/src $ bang run hello_world.sh
The program was aborted due to an error:
Uncaught exception ModuleNotFound: Module unittest was not found

-_- james 0 547 ~/src $ bang new test

Thanks for reporting the issue. I'll check this out.

Got the same error doing the same steps:
bang new duplicate_database
The program was aborted due to an error:
Uncaught exception ModuleNotFound: Module unittest was not found

Using Ubuntu 14.04.3 LTS
Thanks!

Ok, thanks for your report. I am downloading some docker containers so I can test on ubuntu. I'll reply this week ;)

Sorry for taking too much time, but I've been busy.
Please guys, report me back so I can release a new version with the fix ;).


remove diar result files when done

this PR solves issue #40.
now all diarization files that is not overwritten by reruns should now be removed after a diarization. This is all files on the format {filename}.txt, {filename}.rttm etc, except for two files in diarization/config/output_vad/vad_outputs, however these files will according to my testing be removed when starting a new analysis so no need to explicilty remove them.
all other files should either be needed for every analysis, our have a common name like inpu-manifest.json so they will be overwritten each iteration.

what currently happens if two analysis of two different files are called at the same time? i was thinking based on the input-manifest.json file and similar when they are overritten? do we need to have a dymanic system where each run every created file is stored in a folder named the medias filename maybe? or is this not an issue?

Collaborator

I have not considered this and I need to look into this more, unless @tonytonfisk2 or @oskar-dah knows more
"each run every created file is stored in a folder named the medias filename maybe"
#To be safe I should probably change it so it works like this

now all of the diarization created files is put in a general folder with a timestamp (diarization/app/diarization/{timestamp}), when done, I call shutil.rmtree(diarization/app/diarization) which recursively removes all files. I cant influence the name of "diarization/app", but is the second 'diarization' to general of a word? if someone would accedentaly create this folder again all it's content would be deleted by the diarization
according to my testing it works now though :), maybe a timestamp is not the prettiest solution, but it still is only a temporary dir.


[RFC] Combining static thresholds and streaming ML modeling for anomaly detection

What problems are you trying to solve?
Machine learning (ML) based anomaly detection outputs rare data patterns via statistical analysis of past data. However, few machine learning (ML) models are perfect. For example, an anomaly detection model may rightly find a spike but miss the mark in teasing out the extent of spikes to trigger an alert. Such misclassifications falsely alert customers to non-issues, or unnecessarily miss critical events. It would be nice if a user could equip an AD plugin with a safe threshold to trigger alarms when AD detects a changed pattern. Currently, AD cannot incorporate rules in its workflow.
What are you proposing?
Combining ML-based anomaly detection and domain-specific rules improve prediction performance. OpenSearch customers will be able to tell the model what it should do besides the models' findings. This information allows the customer to tune anomaly detection performance to their specific needs on their data.
What is the user experience going to be?
AD allows users to specify rules deriving an anomaly before or after the detector runs. We link rules via AND/OR. That feature X's value should be at least y before being considered an anomaly describes an AND linkage between the threshold condition (X > y) and anomaly condition (anomaly grade > 0). Reporting an anomaly as long as feature X's value is larger than Y regardless of what the model says describes an OR linkage between the same two conditions.
Why should it be built? Any reason not to?
Some community users felt the necessity of combining domain-specific knowledge and ML models. One user anecdotally revealed their interest in marrying static thresholds with ML models. Another forum user indicates that the ML model reports too many anomalies and wants to specify the minimum percentage of changes for an anomaly. Another github issue requests to change the threshold condition after ML models have learned the threshold range.
What will it take to execute?
When a user can provide rules deriving an anomaly, we can combine the rules and ML models to achieve combined benefits. The solution is equivalent to adding conjuncts (if the metric value is at least the threshold before being considered an anomaly) or disjuncts (if the metric value exceeds the threshold, then mark the observation as anomalous) to the original anomaly grade > 0 condition. There are many kinds of rules. One rule is a value outside the range. For example, consider a feature value larger than x. Another rule is missing data. For instance, 90% of past x intervals have missing data. Further, we can leverage temporal information in a time series rather than their instantaneous values alone. Users can configure the alert to happen if something happened "just once," "for the last y readings," or "for z of the last y readings"? The alert can also occur based on change percentage. For example, the change from one point to the next has to be at least x%.
What are remaining open questions?
How to implement a low-latency and high-volume rule evaluation when the rule has temporal information since there can be repeated queries?
Request for comments
We are looking for all forms of feedback! Some questions we would like to get your input on include

What are your use cases of static thresholds in anomaly detection?
Do you have additional feedback beyond what is listed in this RFC?

This sounds like the post-processing of AD results, focusing on when should we notify customers on the anomaly. We may build more on Alerting strategy, including suppression, aggregation, etc.

Yes, it is post-processing of AD results. We may be able to do these in alerting. But doing this inside AD can improve the easiness of use. They can directly view filtered anomalies in AD without creating a separate dashboard. They don't have to write complicated queries in alerting.


Fix DISABLE_TOKEN_AUTH flag check in docker_registry/toolkit.py

When we set DISABLE_TOKEN_AUTH to true, there are two functions that
should check the flag, but only one function does.
So we add the check in both check_token() and validate_parent_access().
Signed-off-by: Guo Xiuyan<EMAIL_ADDRESS>

Changes Unknown when pulling e682fda3c386d7cd87714d076e344b309c54e751 on guoxiuyan:Fix_Token_True into ** on docker:master**.


add: sahilatahar

Description
I have added my profile
Related Issues
Changes Proposed
When I click on add your profile button it redirect to GitHub project repo but does not scroll to Steps to Add Your Profile Data section in readme.
Checklist

[x] I have read and followed the Contribution Guidelines.
[x] All new and existing tests passed.
[x] I have updated the documentation to reflect the changes I've made.
[x] My code follows the code style of this project.
[x] The title of my pull request is a short description of the requested changes.

Screenshots
Note to reviewers

@sahilatahar Thank you so much for your contribution! Your efforts are greatly appreciated and will go a long way in improving our project. Please feel free to share it with others and help us grow even further!


Tab added to inform players of coming Updates

Changes / Comments
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[Y ] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[  Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.

[Y ] Does the pull request title have the sheet name(s)? Include each sheet name. => Maybe I am blind but I dont see it

[Y ] Does the pull request title have the sheet name(s)? Include each sheet name. => Maybe I am blind but I dont see it

clicked the wrong box, it’s been a while since I used Roll 20 Github.  Both my updates are for shadowrun2e.html and Shadowrun.css.

@BalambStudent For future reference, you're probably better off combining changes like this into a single pull request. There's a slight chance that they desync and it'll cause a huge mess. I will come back to check that this isn't the case later today.


feat: optimize client retry logic

What type of PR is this?
optimize(client retry)

What this PR does / why we need it (English/Chinese):
en: Various delay backoff strategies are introduced, and the user-defined retry conditions.

Through client SetRetryConfig (RetryConfig) injects retry config and fails to pass the client WithRetryConfig (), otherwise the circular reference seems to be unable to be solved. For the initialization of RetryConfig, use the option mode of withXXX().
Users can customize the RetryIf function through req, resp and err to realize customized retry conditions.
Introduce four delay strategies: default, random, fixed and exponential. Users can customize the combination
The default value of retryconfig remains to be discussed
The default retry condition feels to be optimized. pkg/common/retry/retry.go::DefaultRetryIf()

zh:引入了各种延迟退避策略，用户自定义重试发生条件。
1.用户通过client.SetRetryConfig(RetryConfig)注入重试配置，没有通过client.withRetryConfig()的方式，否则的话循环引用好像不能被解决。对于retryConfig的初始化使用withXXX()的选项模式。
2.用户可以通过req、resp和err来自定义RetryIf函数，实现自定义重试条件。
3.引入 默认、随机、固定、指数 四种延迟策略，用户可以自定义组合
4.retryConfig的默认值还有待商榷
5.默认重试条件感觉还有待优化。pkg/common/retry/retry.go::DefaultRetryIf()
ps：相关文档 https://bytedancecampus1.feishu.cn/docx/doxcnfQGEZeVgZFkJf4nfcazGbg ，完善中

Which issue(s) this PR fixes:
Fixes (issue63)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.wyfwangyafeng_i seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

cla 和 ci  need solve @CSWYF3634076

cla 和 ci need solve @CSWYF3634076

get

在文档上面开一个小节整体说明一下兼容性相关的问题吧

好的，我在文档中说明一下

continue in #209


failed to import bridging header

Hi,
i always get error "failed to import bridging header".
Any idea?
**/Users/muratyilmaz/Desktop/VuforiaSampleSwift-# master/VuforiaSampleSwift/VuforiaManager/VuforiaEAGLView.h:11:9: 'Vuforia/UIGLViewProtocol.h' file not found
Failed to import bridging header '/Users/muratyilmaz/Desktop/VuforiaSampleSwift-master/VuforiaSampleSwift-Bridging-Header.h'**

Problem solved. thanks for your work. its very useful. i have one more question.  Does it support Vuforia Object Rego?

Thank you for your question.
I didn't try Object Rego. But, as far as I read Vuforia's sample code, I think that my sample maybe work with Object Rego.

I'll try Object Rego today. I'll give feedback about it.

Thanks.
If you got some problem, please tell me about it.

Hi muratyilmaz. I have exactly the same problem. How did you solve it ?

Hi Silvering,
i was trying to run on simulator :) This is the problem. Vuforia doesn't work on simulator.
first you must plug your iPhone and select your iPhone on Xcode.

I just solved the problem which was the header.h import. Thanks for your reactivity ;-)

@Silvering Hi Silvering ,I also have the same problem ,can you tell me how to solve .i almost crazy
i always get error "failed to import bridging header".

@AmonDeng
I fixed the bridging header path for Release configuration.
If you try to build using Release configuration, please try it after applying this fix.
Otherwise, please check the below.

Vuforia SDK doesn't work simulator, You must use iOS Device.
You need to copy Vuforia SDK into This Project.
Please check that Header Search Paths and Objective-Bridging Header in Build Settings of VuforiaSampleSwift target are correct.

@yshrkt  still not work ,it appear a new problem ." vuforia file not found"  but I did include libVuforia.a
this problem make me lost much Hair

@yshrkt  can you send a whole project to my email<EMAIL_ADDRESS>.  I'm desperate to solve this problem and know how to combine scene kit and vuforia.
Good people good life!

I tried to change bridging header to latest 6.x Vuforia SDK but had lots of errors. So  I had to rename Vuforia latest SDK to the old 5.5 one then it works.  Also when apps loads it says scenekit context not found ... it can detect the target but shows a almost transparent red box . Maybe I am doing something wrong. Any advise?

I have the same problem.
I've changed the header search path  like this: $(SRCROOT)/VuforiaSampleSwift/vuforia-sdk-ios-6-2-9/build/include/Vuforia and the Objective-Bridging Header like this: $(SRCROOT)/VuforiaSampleSwift/VuforiaSampleSwift-Bridging-Header.h and i still get error.
Vuforia/UIGLViewProtocol.h' file not found and Failed to import bridging header ‘/(rootPath/VuforiaSampleSwift/VuforiaSampleSwift/VuforiaSampleSwift-Bridging-Header.h.
does any one know how to fix this?

I also encounter the same problem like @MinaAshena and how did you resolve the issue @muratyilmaz

The issue is in the headers that reference <Vuforia/**.h> do not know how to resolve the  framework name. If these do not compile then the bridging header fails.
#import <Vuforia/UIGLViewProtocol.h> is the first point of failure. This is in VuforiaEAGLView.

Copy Vuforia SDK to $(PROJECT_DIR)/VuforiaSampleSwift/vuforia-sdk-ios-6-2-9.

Copy Vuforia Image Targets to $(PROJECT_DIR)/VuforiaSampleSwift/VuforiaAssets/ImageTargets.
e.g. VuforiaSamples-6-2-11/VuforiaSamples/Resources/Assets/ImageTargets

Reopen VuforiaSampleSwift.xcodeproj

Changes build settings as bellow if needed:

Hear Search Paths
"$(SRCROOT)/VuforiaSampleSwift/vuforia-sdk-ios-6-2-9/build/include"

Library Search Paths
$(PROJECT_DIR)/VuforiaSampleSwift/vuforia-sdk-ios-6-2-9/build/lib/arm

Objective-Bridging Header
VuforiaSampleSwift/VuforiaSampleSwift-Bridging-Header.h

I have the same problem.
Error :
/Users/apple/Downloads/VuforiaSampleSwift-master/VuforiaSampleSwift/VuforiaManager/VuforiaEAGLView.h:11:9: error: could not build module 'Vuforia'
#import <Vuforia/UIGLViewProtocol.h>
:0: error: failed to emit precompiled header '/Users/apple/Library/Developer/Xcode/DerivedData/VuforiaSampleSwift-dvryxxfoldtndabwrtwxhvibvpbm/Build/Intermediates.noindex/PrecompiledHeaders/VuforiaSampleSwift-Bridging-Header-swift_1224YBKGJ1X1-clang_18DCYIGZG1FMG.pch' for bridging header '/Users/apple/Downloads/VuforiaSampleSwift-master/VuforiaSampleSwift/VuforiaSampleSwift-Bridging-Header.h'
i Set all setting as per comment.
I am Using vuforia-sdk-ios-8-5-8 latest version link : https://developer.vuforia.com/downloads/sdk
i am also copy Image Targets in my project from vuforia sample project link : https://developer.vuforia.com/downloads/samples
1) Header Path :  $(SRCROOT)/VuforiaSampleSwift/vuforia-sdk-ios-8-5-8/build/include
2) Search Path : $(PROJECT_DIR)/VuforiaSampleSwift/vuforia-sdk-ios-8-5-8/build/lib/arm
3) Objective-Bridging Header : VuforiaSampleSwift/VuforiaSampleSwift-Bridging-Header.h
Please let me know if any thing missing.


Imports could be better

I am looking into using the arcgis-angular-webpack branch as an example for how to implement nice module loading for the ArcGIS JS API in our Angular application.  I have used the branch as an example, and it seems to work pretty well.  One thing of note, however, is that when you import modules the way the example shows:
import Map from "arcgis-js-api/Map";
import MapView from "arcgis-js-api/views/MapView";

They are imported as any
This is pretty problematic to use, and in a lot of cases, people like to use the noImplicitAny compiler flag.  This workflow will not allow you to do that.
In my experimentation, I was able to structure the imports as such:
import * as Map from "esri/Map";
import * as MapView from "esri/views/MapView";

This is using the module names as defined in the typings, and by doing so, the imported modules come in with the correct typings.  It seems much nicer this way, and everything seems to continue functioning.
My question is: Is what I am doing a bad practice in some way?
If not, could the example be updated to import in this way?
Thanks,
Eben

Hey @ekrapfl, your approach is good, there is no incorrect answer as related to noImplicitAny. You do raise a good point and I can definitely update the code and make the typings implementation cleaner if someone does set that flag. Here's a quote from the Angular docs https://angular.io/guide/typescript-configuration:
* TypeScript developers disagree about whether the noImplicitAny flag should be true or false. There is no [in]correct answer and you can change the flag later. But your choice now can make a difference in larger projects, so it merits discussion.
Also note, you can set "esModuleInterop": true in tsconfig.json and then you should be able to use this pattern with "noImplicitAny": true:
import Map from "esri/Map";

I'll make some updates.

Thanks for the feedback @andygup!  Just wanted to make sure I wasn't doing anything wrong :)

Done via https://github.com/Esri/angular-cli-esri-map/commit/6efa23eba493ce9bfdf4be5e1becf550cb38886c


General: Change password handling for internal users

Checklist
General

[ ] I tested all changes and their related features with all corresponding user types on a test server.
[ ] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[X] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[X] I chose a title conforming to the naming conventions for pull requests.

Server

[X] I followed the coding and design guidelines.
[X] I implemented the changes with a good performance and prevented too many database calls.
[X] I documented the Java code using JavaDoc style.

Client

[X] I followed the coding and design guidelines.
[X] I translated all newly inserted strings into English and German.

Changes affecting Programming Exercises

[ ] I tested all changes and their related features with all corresponding user types on Test Server 1 (Atlassian Suite).
[ ] I tested all changes and their related features with all corresponding user types on Test Server 2 (Jenkins and Gitlab).

Motivation and Context

This is the final PR of my Password Migration to Bcrypt Hashing to finally switch the Password Service.
Description

I deprecated the old PasswordService and added a new one supporting Bcrypt. A new Java Migration sets all passwords of external users to null and first decrypts and then hashes the other passwords to complete the transformation.
I then adapted all occurrences, especially all instances of creating and updating the user. Instead of decrypting the password at any given place I now pass the password along.
I also documented the new usage and current limitations of Jenkins.
I upped the maximum missable classes because by deprecating the password service I created another class that is, again, just a wrapper class for external functionality so nothing we need or want to write tests for.
The cypress tests currently fail. I can't reproduce certain errors locally. Currently investigating if this PR requires the cypress setup to do some changes.
Steps for Testing

You can only test this locally as this change would make any test server unusable until reset or this PR is merged.
For local testing:

SQL dump jhi_user
Do the testing
Drop jhi_user and import your SQL dump

Prerequisites:

1 Instructor
2 Students
1 Programming Exercise with Complaints enabled

Start the application
Make sure that jhi_users was updated correctly
Log in with internal and external users
Do a password change with internal users (verify the password gets updated for the git repository)
Edit internal users with a password change and without. Verify that changes are correctly propagated. For Jenkins developers, please validate that the behaviour was correctly documented.
Test anything that seems reasonable to you in regards to the changes.

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

SecurityConfiguration.java: n/a | 97.65%
JiraAuthorizationInterceptor.java: 100% | 100%
ArtemisInternalAuthenticationProvider.java: 41.67% | 74.07 %
DomainUserDetailsService.java: 0% | 36.36%
BitbucketUserManagementService.java: 71.05% | 94.34%
VcsUserManagementService.java: n/a | 100%
GitLabUserManagementService.java: 88.24% | 97.50%
JenkinsUserManagementService.java: 86.84% | 98.64%
PasswordService.java: n/a | 100%
UserCreationService.java: 68.97% | 94.12%
UserService.java: 78.33% | 93.25%
AccountResource.java: 77.08% | 95.71%
UserResource.java: 75% | 96.77%

Regarding the Cypress tests, see the description above.


fix: 1387 update date rules in seedlot registration screens

Description
Closes #1387
Changelog
New

Added limitation to date fields on seedlot registration form
Added validation to interim step end date field

Changed

Nothing :)

Removed

Nothing :)

How was this tested?

[ ] 🧠 Not needed
[x] 👀 Eyeball
[ ] 🤖 Added tests

What gif/image best describes this PR or how it makes you feel?

Thanks for the PR!
Deployments, as required, will be available below:

Frontend
Backend
Oracle-API

Please create PRs in draft mode.  Mark as ready to enable:

Analysis Workflow

After merge, new images are deployed in:

Merge Workflow

Do you think we need to check the dates before data is changed in methods such as handleStorageDates? I like the idea of double checking since the maxDate only limit the user's selection but does not specifically invalidate an input

I don't it's necessary, I think the message is quite clear by not letting them select the dates, and if they input a future date manually, it'll trigger the error and show the invalid message.