Export error variables

Description
Export error variables out of the package. Unlike what's stated in #37, PR exports all (two) error variables. We don't have a use for the other variable but someone else might. If that's a problem, I'll revert back to what's in line with the ticket.
Reference issue
Fixes #37

I've used nolint next to the error variables to stop linter from complaining about a missing comment - the error message is self-explanatory, I think.
I'm not sure what to do about this one, though: https://github.com/pion/udp/pull/38/checks?check_run_id=2150153653

Merged with 534f92eb13db661274eb15a8ea186585e9f1e182
I hope you stay involved with Pion @besedad. I usually have to spend a lot of time helping people with their first commit, could use the help of an experienced developer like yourself :)
If there is anything I can do to improve Pion also would love to hear! Always trying to make it better.


Updating code for new version

I don’t know if the issues are from the new version of vue-instantsearch or vue-autosuggest but I am having difficulties updating my code.
Here is the old version: https://codesandbox.io/s/48pj5z4vx4 with vue-instantsearch version 1.7.0 and vue-autosuggest version 1.8.1, which was working except I couldn’t get the “No results” message to show up.
Here is the new version: https://codesandbox.io/s/88549z7p19 using vue-instantsearch version 2.0.0 and vue-autosuggest version beta. The “No results” message is now showing but other features that were implemented in the old way aren’t working correctly anymore or I don’t know how/where to insert the code. Also, in the input the selected element is showing has [object Object], don’t know why.
The features were:

when clicked in input, don’t show results until something is entered in input;
the first suggestion gets highlighted by adding a class to it (don’t know where to add the code for this one in new version);
if you press enter, Esc or click away from the input/dropdown without nothing selected, the input gets populated with the first suggestion.

Furthermore, could the vue-autosuggest input be type=search instead of text to be able to clear the input? If not, then how can we implement the ais-clear-refinements component of vue-instantseach? I tried but the button keeps being disabling. Is there another way in the beta version to clear the input?
Note:  There is a weird issue that now occurs in both versions that wasn’t there before but it could be related to cache. When clicking in the input, another dropdown shows with text of previous queries. Don’t know why but it isn’t always there so don’t know if it’s really an issue.

The first link you posted didn't work.

It looks like you were referencing "query" but not using v-model feature or defining the data attribute query.
in second example you were not using getSuggestionValue prop, but in first one you were.
"clearing" the input/results should just need to set "query" to empty. It looks like the caching you are seeing is because you might clear the input, but the ais "refinements" are still there so vue-autosuggest just sees data and displays it, it doesn't know how you got it.
The way you are doing first suggestion highlighting in that first codesandbox is a bit hacky. Instead of relying on the class names, I would recommend doing something like this: https://github.com/darrenjennings/vue-autosuggest/issues/94#issuecomment-466226911

https://codesandbox.io/s/z391yl42pm
It does look like the component doesn't allow you adjust to type=search. It should be allowed to override type=text to be search so I'll get that into the beta. I will put that into the roadmap.


[Bitwarden] Add support for self hosted instances

Description
Fixes #1447.

Added server url and certs preferences
Set Bitwarden CLI server when these preferences change

TODO

[ ] needs to be tested on a self hosted instance
[x] check that upgrade works fine

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@aozaki-kuro please could you give this a go on your self hosted instance!

@xorob0 I noticed you +1ed the issue, do you have a self-hosted server you could test on as well?
I'm about to add a "Switching server" toast to make it clear when the CLI is switching between servers.

Code looks great overall 🚀

Thanks! I'm not super happy with the use of Toast within the API class, but to pull it out to the view logic would add much more needless complexity.

Thanks @daniel-stoneuk for adding the feature ! I will do a proper tomorrow.

No worries @pomdtr, hope you like it 😁
Quick demo video (the extension needs to be reloaded for preferences to take effect anyway)
https://user-images.githubusercontent.com/15860949/164558875-8ba17c86-77bd-460d-9af8-3257a10900b4.mp4

Looks good! However I'm not sure we want to surface the server information to regular users.
And advanced users hosting their own server should have the reflex to both read the README and look at the prefs.

Good point. I tried surfacing it only when it wasn't the default but having it appear and push the rest down after the status load was a bit jarring.
Just had another think though, and I'll show the server field if:
a) the preference is set
b) the preference is unset but for some reason status returns the default
Thanks for the feedback!

Sorry for the late response, I was at work and spent a long time to figure out how to import an extension...

... And it seemed to be working totally fine on my side🙏

Let's await feedback from @pomdtr

Can confirm it works with my self hosted server

@daniel-stoneuk Can you add a mention of the feature in the README ?

Awesome, it looks like we're almost ready for a merge when README (and maybe CHANGELOG) is updated

Thank you so much @aozaki-kuro and @xorob0 for testing this on your self hosted instances!

Can you use this PR to fix change Logout Vault to Logout in the Action Panel ?

Yep, will do that now!

Is this ready for merge now?

Go ahead. Thanks for your contribution @daniel-stoneuk !

Awesome work! Thanks @daniel-stoneuk 🎊


Fix Docker Hub's description

Unless I'm terribly mistaken:

the current repository is what is used to push to https://hub.docker.com/r/racket/racket and
the current repository builds its images on debian:stable-slim.

However, the Docker Hub description suggests that images are built on top of buildpack-deps, which can be frightening for some: It is based on Ubuntu, which increases the size of the images (debian:stable-slim is 80MB when buildpack-deps is 834MB) and the surface of attacks.

Ah, yeah it's out of date. Pull request welcome, else I might get around to it eventually.

Hum. To be honest, I don't even know what I would need to change in a pull request to update the Docker Hub page. Isn't it more or less only copying the README?
Le 9 mars 2022 01:30:48 UTC, Jack Firth @.***> a écrit :

Ah, yeah it's out of date. Pull request welcome, else I might get around to it eventually.
--
Reply to this email directly or view it on GitHub:
https://github.com/jackfirth/racket-docker/issues/65#issuecomment-1062462332
You are receiving this because you authored the thread.
Message ID: @.***>

@Niols I believe this has been fixed for some time now, so I'm going to go ahead and close this issue. Please feel free to re-open if I'm wrong.


spoofer wallet with 8 hotspots with[Addition]:

Hotspot b58 Addresses
the adress wallet - 13PZC4v1hooy7hf9itJjjaKayCa2v6FbKuG8KA4LpbQWXHdAZRH
and the 8 hotspots below :
Muscular Sapphire Zebra
Brilliant Cornflower Cricket
Fast Satin Perch
Agreeable Tawny Piranha
Original Tweed Duck
Helpful Blonde Buffalo
Cheery Holographic Ladybug
Bitter Cloud Lynx
Discord Handle
No response
Reason(s)
the hotspots only witnness its own. and all hotspots is placed in the middle of nowhere with good space between them

Never found such a bad project. When you bought the equipment, the seller and the project party did not supervise whether the sales were legal or not, and did not inform you of the existing risks, just as the police acquiesced in allowing qualified arms dealers to sell arms, but did not inform you that they must sell and use arms legally.  I believe that Helium will definitely declare bankruptcy. As it is said on the Internet, he is a fraud. Because now everyone is reporting. Even though the new 5G hot spot equipment is excellent, it is impossible for new miners to be deceived again.I hope everyone who sees this will forward it. Let everyone know that the project party is a fraud gang.


Change the Gitter away from grumpy-devel ?

Should we change the Gitter away, creating a new room?
cc: @RezaGhanbari

@alanjds
Let's create a new gitter, That looks reasonable.
And now, I am trying to catch up your code which is different from google grumpy :)

Yes, I should update the Readme. Sorry
There is grumpy-tools-src. You do a setup.py develop.
Then the same on grumpy-runtime-src.
After that, each change on Go files you should setup.py build into grumpy-runtime-src
For the development flow, it is all

As told to @RezaGhanbari in pvt, I am a bit out of bandwith right now. Have life obligations calling me after the effort on the release and article. So, I will tend to step-back on new efforts, but the Readme update is on top of my priorities now that a new organization is born.

Internally, most notable differences are that Python code is no more called via subprocess, easing the use of debuggers. And lots of inside info can be got via running code with -v debug flag.
My modus operandi was of running a piece of code via python myscript.py and then changing to grumpy -v debug myscript.py and fixing what is different between both. Then write py.test tests for it.

Thank's @alanjds for explanation.
I think it's good to have a updated readme and a release note for next version.


feat(agents-api): Add embed_instruction argument to embeddings & document creation endpoints

[!IMPORTANT]
Adds embed_instruction argument to document creation and embedding endpoints, updating models and OpenAPI spec accordingly.

Behavior:

Adds embed_instruction argument to CreateDocRequest and EmbedQueryRequest in Docs.py.
Updates create_doc() in create_doc.py to handle embed_instruction by removing it from doc_data.
Modifies run_embed_docs_task() in create_doc.py to pass embed_instruction.
Updates embed() in embed.py to prepend embed_instruction to text_to_embed.

OpenAPI Specification:

Adds embed_instruction to CreateDocRequest and EmbedQueryRequest models in models.tsp.
Updates openapi-0.4.0.yaml and openapi-1.0.0.yaml to include embed_instruction in required properties for CreateDocRequest and EmbedQueryRequest.

This description was created by  for a006be61252cfe2eee55a05d05bc451ed1194914. It will automatically update as commits are pushed.

@HamadaSalhab You checked in the local jwt

@creatorrr They were already there, the changes are there due to reformatting. Btw, we should delete these notebooks. I don't see the point in having them here.


Using the "in" operator should make bracket access safe on an object

Search Terms
object in keyof bracket operator in
Suggestion
Checking a key with the "in" operator on an object should make it safe to to use in brackets
Use Cases
Useful when writing functions that process input JSON/doesn't have a concrete type.
Examples
//  Ideally this uses TypeScripts control flow logic to allow the bracket access.
function getPropFailsToCompile(data: object, key: string): any {
    if (!(key in data)) {
        throw new Error("Data is malformed")
    }
    return data[key]
}

// Compiles but keyof object has type 'never' in Typescript
function getPropCompilesButNotReasonable(data: object, key: keyof object): any {
    if (!(key in data)) {
        throw new Error("Data is malformed")
    }
    return data[key]
}

// Best way I've gotten this to work.
function getPropWorks(data: object, key: string): any {
    if (!(key in data)) {
        throw new Error("Data is malformed")
    }
    return (<any>data)[key]
}

Checklist
My suggestion meets these guidelines:

[x ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x ] This wouldn't change the runtime behavior of existing JavaScript code
[x ] This could be implemented without emitting different JS based on the types of the expressions
[x ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[ x] This feature would agree with the rest of TypeScript's Design Goals.

And just realized 'keyof object' is never. So you can't pass anything reasonable to the functions that do compile :)

Duplicate of #21732

Possible duplicate of #21732

This is a bit tricky; we'd need a new kind of type property key that relates to a (hopefully const?) variable, or some special-casing which isn't great. These kind of helper functions are usually short enough and general-purpose enough that having a type assertion or two in the body doesn't change their safety very much, so the trade-off isn't great in terms of complexity. Hearing about more common / safety-requiring scenarios would be good.

The property accessor can only use string or symbols which are both already immutable in javascript, right?

The value itself is immutable, but the references to them aren't (unless they're bare const identifiers).

right, and object isn't immutable either. You'd need something stronger than types to say "This key works for this specific object as long as no else has edited it."
The const thing is interesting. I figured your type checks already have something that's smart about reassignments i.e. in the playground this doesn't compile cause it's smart enough to realize that value might be undefined.
function typeErasure(): string | undefined {
    return "hello world"
}

let value = typeErasure()
let temp = undefined

if (value === undefined) {
    throw new Error("This is undefined")
}

value = temp

let x = value.length

See #31445 - the compiler would need a way to know that the same key is used for the indexed access as for the in expression, which it currently has no mechanism for; it only looks at the types, and in your case key is string.  I believe this is what @RyanCavanaugh was getting at above.

The same issue occurs with the for...in loop construct, which may(?) have a slightly narrower solution scope in that it seems the 'key' variable used in the iteration is guaranteed to be a string which can be used to index the object (regardless of the type the property was defined as in the first place), and it ignores the case of Symbol properties.
The example below fails compilation at obj[key] unless the function signature is changed to obj: any. (It also fails with signature obj: object).
function processUnknown(obj: unknown) {
    if (typeof obj === 'object') {
        if (obj !== null) {
            for (const key in obj) {
                //     ^^^
                // Typescript identifies key as type `string`

                console.log(`key ${key} indexes ${obj[key]}`);
                //                                ^^^^^^^^
                // Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{}'.
                //   No index signature with a parameter of type 'string' was found on type '{}'.(7053)
            }
        }
    }
}

However following runtime examples show that this access is safe, regardless of property type. (The only thing I can see breaking this is if somehow the property is removed between const key getting a value and the indexing access op itself.)
processUnknown(JSON.parse('{"someJsonKey":"someJsonValue","someOtherJsonKey":1}'))
// key someJsonKey indexes someJsonValue
// key someOtherJsonKey indexes 1
processUnknown({ "1": "one (string)", 2: "two (number)" })
// key 1 indexes one (string)
// key 2 indexes two (number)

Playground Link for above examples
Similar to the plain in test/expression, there currently doesn't seem to be any way to type-guard down this kind of property access at the moment? Unless you explicitly cast using (obj as { [key: string]: unknown })[key], or rely on variables declarations or function signatures that use { [key: string]: unknown } as a pre-declared type.
Processing parsed JSON shape is the use case I came across this with as well. The example below may motivate things a bit more:
function processParsedJson(id: string, jsonObj: unknown) {
    if (typeof jsonObj === 'object') {
        if (jsonObj !== null) {
            let keysExist = false
            for (const key in jsonObj) {
                keysExist = true
                console.log(`parsed JSON ${id} has key ${key} pointing to ${jsonObj[key]}`);
            }
            if (!keysExist) {
                console.log(`parsed JSON ${id} did not have any keys`)
            }
        }
        else {
            console.log(`parsed JSON ${id} was null object type`)
        }
    }
    else {
        console.log(`parsed JSON ${id} was non-object type ${typeof jsonObj}`)
    }
}

processParsedJson('1', JSON.parse('{"someKey":"someValue","someOtherKey":1}'))
// parsed JSON 1 has key someKey pointing to someValue
// parsed JSON 1 has key someOtherKey pointing to 1
processParsedJson('2', JSON.parse('{}'))
// parsed JSON 2 did not have any keys
processParsedJson('3', JSON.parse('2'))
// parsed JSON 3 was non-object type number
processParsedJson('4', JSON.parse('["a", 2, null, {}]'))
// parsed JSON 4 has key 0 pointing to a
// parsed JSON 4 has key 1 pointing to 2
// parsed JSON 4 has key 2 pointing to null
// parsed JSON 4 has key 3 pointing to [object Object]
processParsedJson('5', JSON.parse('null'))
// parsed JSON 5 was null object type

Playground Link
(Note: JSON.parse currently returns type any, not unknown as this function argument might imply, but hopefully the examples above motivate the kind of type-checking behaviour that you might expect to get if you want to explicitly validate arbitrary JSON shape)

I had the same issue today (Playground Link)
I was able to get around it by defining an existsIn helper as follows:
function existsIn<T>(obj: T, name: string | number | symbol): name is keyof T {
  return name in obj;
}

And then I was able to define the function I wanted
const values = {test: 'this value', foo: 'that value'};

const handleMessage = (name: string): void => {
  if (existsIn(values, name)) {
    console.log(values[name]);
  }
}

I had the same issue today (Playground Link)
I was able to get around it by defining an existsIn helper as follows:
function existsIn<T>(obj: T, name: string | number | symbol): name is keyof T {
  return name in obj;
}

And then I was able to define the function I wanted
const values = {test: 'this value', foo: 'that value'};

const handleMessage = (name: string): void => {
  if (existsIn(values, name)) {
    console.log(values[name]);
  }
}

maybe there's some unsoundness I haven't considered here, but it seems like it should be pretty simple to have name in obj imply the same name is keyof T assertion that an explicit type guard does!

maybe there's some unsoundness I haven't considered here, but it seems like it should be pretty simple to have name in obj imply the same name is keyof T assertion that an explicit type guard does!

What is the typescript recommended way to determine that an unknown variable is an object with a given property on it? @nightpool's suggestion is fairly good but like he said, "it should be pretty simple to have name in obj imply the type correctly. I'm always typing something like:
const obj: unknown = { foo: 'bar'}
if (typeof obj === 'object' && obj !== null && Object.hasOwnProperty.call(obj, 'foo') && typeof obj.foo === 'string') {
  //                                                                                ^^^^^ ERROR
}

This is not the best user experience nor does it actually work though it seems like it ought to.


cannot reset custom service provider

What happened:
On Android, App version 2.17.0
I set the custom ocean url to my defichain on testnet. now trying to reset it back to the main ocean is not working.
When I tap the reset button it asks for my password and then spins infinitly
trying to just enter the offcial url doesn't work either as there is no way to confirm it.
What you expected to happen:
clicking the reset button should reset it to main ocean
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:

We are taking a look into this issue, but was unable to reproduce.


should bash have an extension of .sh?

Ref. lib/reel/shell.rb:46
        'bash' # TODO: should bash have an extension of .sh?
      else
        # TODO: cleanup error output
        fail ArgumentError, "#{shell_env_var} is an unsupported shell."
…

Ref. lib/reel/shell.rb:74
          'bash' # TODO: should bash have an extension of .sh?
        else
          # TODO: cleanup error output
          fail ArgumentError, "#{shell_env_var} is an unsupported shell."
…


[2.9] Fixes the local upgrade failure

Back port of https://github.com/rancher/rancher/pull/48292

Looks like there's some conflicting go.sum entries that need to be fixed.

@markusewalker resolved the conflicts in go.sum and go.mod


HALON-409: Don't trigger reset on internal TRANSIENT failures

Created by: nc6

Closing as an obsolete


initial commit for CouchDBTrainer

Created a couchdb trainer that will let the chatterbot train from a set of couchdb documents.
This enables people who use a couchdb database to automatically train the chatbot from their documents (rather than resorting to different dbs).
Things that you will have to do from a db end:

Create your training dataset with doc_type:'chatterbot'
Create a map function that will emit key value paris with values in the same format as the json corpus.

Hi @galeej thank you for submitting this pull request for #659. Unfortunately I can't merge it in to the project because it lacks comprehensive unit test coverage and documentation. With the addition of those two elements I believe this could be a candidate feature addition.

Hi @gunthercox  could you let me know what all I should do vis-a-vis unit testing and documentation (should I add more comments or should i give you a more detailed documentation in word or something)?

@galeej This link we show how to run unittests under chatterbot http://chatterbot.readthedocs.io/en/stable/testing.html
The MangoDBTestAdapter will tell how to write a testcase for your new adapter https://github.com/gunthercox/ChatterBot/blob/master/tests/storage_adapter_tests/test_mongo_adapter.py#L7

And also the tests are faling, please run chatterbot unitests before pushing
nosetests tests/logic_adapter_tests

And more documentation about Python Unittest framework

thanks.  Will finish and push again.

Hi All,
my apologies for the delay... I've been a bit busy with exams.  I'll have this done by the end of the month.


Include BR Domain Faculdades Osvaldo Cruz

Request:

Include BR Domain Faculdades Osvaldo Cruz

the school official website URL
https://www.oswaldocruz.br/home/default.asp

the school street address, including city and country
Rua Brigadeiro Galvão, 540 - Barra Funda São Paulo Brazil

an URL of a page on the official website where the school offers an IT-related long-term (>1 year) course
https://www.oswaldocruz.br/www/view/cursos_e/analise-e-desenvolvimento-de-sistemas/

a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.
I requested to educational institution

@roma-mb Thank you! Please post a new comment here as soon as you have an update from the school.

@roma-mb You might miss my previous comment. Please react.

@roma-mb Thank you! Please upload it here as soon as you have an update.

Thank you! Please upload it here as soon as you have an update.

Hello, @philipto, I have an update. Please provide your e-mail address so I can send you a response from the college.

@roma-mb Thank you! Please send the response to<EMAIL_ADDRESS>mentioning this request URL: https://github.com/JetBrains/swot/pull/19306

@roma-mb Thank you! Please send the response to<EMAIL_ADDRESS>mentioning this request URL: #19306

Done, Thank you!

@roma-mb I am sorry, it looks like I still did not receive any message from you. Could you please try again and resend the message now?

@roma-mb
Hello Philip, thank :fist_oncoming:


Add Rafael Caricio to the list of maintainers

Added myself to the list of maintainers.

:+1: :+1: :+1: :smile:


Merge  and  #trivial

This is an attempt to consolidate the logic in the <ConfirmBid> and <ConfirmFirstTimeBid> components. Let me know what you think!
#skip_new_tests

Looks like this needs a rebase, but I think it's a 👍direction.
I noted one place where some logic I added in a previous PR got removed, but I think it's alright and I can follow up with something more comprehensive now that the components are merged.

Warnings

:warning:

Missing Test Files:

src/lib/Components/Bidding/__tests__/types.d-tests.ts

If these files are supposed to not exist, please update your PR body to include "#skip_new_tests".

  Generated by :no_entry_sign: dangerJS

This should be good for review.


lab3- Add an optional -l, --lang, and/or \l flag

Add an optional -l, --lang, and/or \l flag, which indicates the language to use when generating the lang attribute on the root  element. For example, --lang fr would mean that the HTML documents are in French, and would include , while -l pt-BR would mean the text is using Brazilian Portuguese: . By default, use en-CA for Canadian English.

add this function successfully, and the branch issue-9 had merged to the main branch.


[Provider] Add compatibility with Graylog 5.0

Graylog 5.0 has been released, see:

https://www.graylog.org/post/graylog-5-0-a-new-day-for-it-secops/
https://go2docs.graylog.org/5-0/changelogs/changelog.html#Graylog500

This likely means that some Terraform resources won't work anymore with Graylog 5.0, and thus need to be updated in order to make it compatible.

Can confirm issues do exist because of the API-upgrade:


envoy listener 2 ports + 2 clusters

I try to set 2 listener in config with different ports and clusters for redirect
` static_resources:
listeners:

name: listener_back_end
address:
socket_address: { address: <IP_ADDRESS>, port_value: 9090 }
filter_chains:

filters:

name: envoy.tcp_proxy
config:
stat_prefix: ingress_tcp
cluster: back_end
tls_context:
common_tls_context:
tls_certificates:
- certificate_chain:
filename: "/ProxyServerConfig/SSL/certificate.crt"
private_key:
filename: "/ProxyServerConfig/SSL/private.key"
clusters:

name: back_end
connect_timeout: 0.2s
type: STATIC
lb_policy: ROUND_ROBIN
hosts: [{ socket_address: { address: <IP_ADDRESS>, port_value: 1990
}}]
name: listener_front_end
address:
socket_address: { address: <IP_ADDRESS>, port_value: 443 }
filter_chains:

filters:

name: envoy.tcp_proxy
config:
stat_prefix: ingress_tcp
cluster: front_end
tls_context:
common_tls_context:
tls_certificates:
- certificate_chain:
filename: "/ProxyServerConfig/SSL/certificate.crt"
private_key:
filename: "/ProxyServerConfig/SSL/private.key"
clusters:

name: front_end
connect_timeout: 0.2s
type: STATIC
lb_policy: ROUND_ROBIN
hosts: [{ socket_address: { address: <IP_ADDRESS>, port_value: 8081
}}]`

envoy is started but when I try open in browser any of this port I get: ERR_CONNECTION_CLOSED. Each configuration works separately...
Anyone can help? Thanks!

i found solution


Adding custom fields to sign up/sign in forms.

I tried this but my calls to AccountsTemplates.addFileds and removeFiled from a custom were overwritten by the call to the same methods in the main Telescope code. How do I solve this?

Hello there!
Where are you trying to change the fields? In which file?
Consider that each file is loaded with a particular and well defined order: see File Load Order inside the Structuring your App section of Meteor docs.

But the package code is always loaded before the main code, right? And my
code is in a package.
Hello there!
Where are you trying to change the fields? In which file?
Consider that each file is loaded with a particular and well defined order:
see File Load Order inside the Structuring your App
http://docs.meteor.com/#/full/structuringyourapp section of Meteor docs.
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-83589346.

Ok, now I see...
You could try to wrap your call to AccountsTemplates inside a
Meteor.startup(function(){
  // AT confgi here
  // ...
});

but there would probably be another race condition...
...lets try!

I think I am saying something incorrectly here. But my idea is that my
package's call to AccountsTemplates should happen after the main code's.
Wouldn't putting it in Meteor.startup do the opposite of it?
On Mar 19, 2015 7:48 PM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

Ok, now I see...
You could try to wrap your call to AccountsTemplates inside a
Meteor.startup(function(){
// AT confgi here
// ...
});
but there would probably be another race condition...
...lets try!
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-83598594
.

well, all stuff inside a meteor.startup is actually run after all regular file loading is finished...
the big question is: will your Meteor.startup run after or before the one used by accountstemplates to initialize itself?? :-)

Oh thanks for clearing that up. I will check and let you know as soon as I
can.
On Mar 19, 2015 8:04 PM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

well, all stuff inside a meteor.startup is actually run after all regular
file loading is finished...
the big question is: will your Meteor.startup run after or before the one
https://github.com/meteor-useraccounts/core/blob/master/lib/server.js#L168-171
used by accountstemplates to initialize itself?? :-)
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-83610864
.

any news on this @PranayShah?

This is what the AccountsTemplates object looks like when logged from within a Meteor.startup (function())  within a package. And the error which I was getting. There are no methods associated with the AccountsTemplates object.
I20150405-01:14:19.546(5.5)? { options:
I20150405-01:14:19.546(5.5)?    { enablePasswordChange: false,
I20150405-01:14:19.547(5.5)?      showForgotPasswordLink: true,
I20150405-01:14:19.547(5.5)?      confirmPassword: false,
I20150405-01:14:19.548(5.5)?      overrideLoginErrors: true,
I20150405-01:14:19.548(5.5)?      lowercaseUsername: true,
I20150405-01:14:19.548(5.5)?      negativeFeedback: false,
I20150405-01:14:19.548(5.5)?      positiveFeedback: false,
I20150405-01:14:19.548(5.5)?      negativeValidation: true,
I20150405-01:14:19.548(5.5)?      positiveValidation: true,
I20150405-01:14:19.549(5.5)?      privacyUrl: 'privacy',
I20150405-01:14:19.549(5.5)?      termsUrl: 'tos',
I20150405-01:14:19.549(5.5)?      showReCaptcha: false,
I20150405-01:14:19.549(5.5)?      showAddRemoveServices: false,
I20150405-01:14:19.550(5.5)?      showLabels: true,
I20150405-01:14:19.550(5.5)?      showPlaceholders: true,
I20150405-01:14:19.550(5.5)?      defaultState: 'signIn',
I20150405-01:14:19.550(5.5)?      forbidClientAccountCreation: false,
I20150405-01:14:19.550(5.5)?      sendVerificationEmail: false,
I20150405-01:14:19.550(5.5)?      socialLoginStyle: 'popup',
I20150405-01:14:19.551(5.5)?      homeRoutePath: '/',
I20150405-01:14:19.551(5.5)?      redirectTimeout: 2000,
I20150405-01:14:19.551(5.5)?      onSubmitHook: undefined,
I20150405-01:14:19.552(5.5)?   _initialized: true }
I20150405-01:14:19.608(5.5)? Exception while invoking method 'userOrOrg' TypeError: Object [object Object] has no method 'removeFields'
I20150405-01:14:19.608(5.5)?     at [object Object].Meteor.methods.userOrOrg (packages/batmobile-users/lib/atConfig.js:54:1)
I20150405-01:14:19.608(5.5)?     at [object Object].methodMap.(anonymous

Just wanted to say I'm planning on looking into this next week.

@PranayShah, I think I've just spotted the error: it's removeFiled and not removeFields!
...btw, you should see all methods from the class' prototype.
Lets also have a look at the Remove Fields section.

This does not work even with AccountsTemplates.removeField . The error shown now is:
 Exception while invoking method 'userOrOrg' Error: AccountsTemplates.removeField should strictly be called before AccountsTemplates.init! . And this is even after calling the method from a Meteor.startup block.

Yeah, I suspected this... :(
Your Meteor.startup is executed after the one used by useraccounts to trigger its initialization.
So, in summary:

if you work on regular top level code, being inside a package, your file is loaded before Telescope's top level code and your changes are somehow overwritten by Telescope's configuration file
if you run some configuration inside Meteor.startup, this is executed after the Meteor.startup used by useraccounts because, as another package, it's probably loaded first...

The only way would be getting your package loading before useraccounts so that your Meteor.startup goes before the UA initialization.
But unfortunately, we have no means to say a package should come before another one...
We can do the opposite, specifying that a package depends on another, but this is not the case :(

So can we hope to work this out. This seems like a pretty necessary
requirement to me.
On Apr 7, 2015 1:50 AM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

Yeah, I suspected this... :(
Your Meteor.startup is executed after the one used by useraccounts to
trigger its initialization.
So, in summary:

if you work on regular top level code, being inside a package, your
file is loaded before Telescope's top level code and your changes are
somehow overwritten by Telescope's configuration file
if you run some configuration inside Meteor.startup, this is
executed after the Meteor.startup used by useraccounts because, as
another package, it's probably loaded first...

The only way would be getting your package loading before useraccounts so
that your Meteor.startup goes before the UA initialization.
But unfortunately, we have no means to say a package should come before
another one...
We can do the opposite, specifying that a package depends on another, but
this is not the case :(
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-90228920
.

@splendido Any updates on this?

no, not really
what if you remove all AT stuff from Telescope and configure everything inside your package?

Do you mean removing Telescope's dependency on AT entirely, hence modifying
the core Telescope code for this and then adding  it back again but as a
dependency of my own package? So I feel this is bound to work but does it
not sound like an overkill to do something simple like adding extra fields
to the user's schema right at login, specially since AT supports all that
so beautifully.
On Apr 25, 2015 1:12 PM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

no, not really
what if you remove all AT stuff from Telescope and configure everything
inside your package?
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-96146197
.

could you explain how you'd like to change the fields?
I've just read again all this thread but I can't get it.

All I want to do is add fields with calls to AT.addField,  like it is
documented in the Accounts templates package.  These calls have no effect.
On Apr 25, 2015 1:26 PM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

could you explain how you'd like to change the fields?
I've just read again all this thread but I can't get it.
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-96148366
.

Ok, but I'd say that new fields should be kept...
Are you by chance trying to change email or password which are the ones changed by Telescope?

Indeed I was trying to change the email and password fields. And I understand that is not possible. But, that aside, how would you suggest I specify a different template to be used when the /register and /sign-in links are navigated to? Specifying AccountsTemplates.configureRoutes ( )  with the template option specifying a template does not work. I realize I may be confusing you here by talking about different issues in the same thread but I am essentially trying to solve the same problem here. In my use case, there are 2 kinds of users, normal users and organizations. I want to be able to provide different sign-up fields for either of them depending on say, a Session variable, which is set according to the type of user selected while in the /register route itself. Sorry for a long and almost useless reply.

Hey @PranayShah it is not possible to implement this last request in case you'd like to have the organization field required: see this issue
Btw, to get different templates you should override the default one (e.g. with aldeed:template-extension) so you can switch something on the fly...
This said, I'm sorry but in your case the only solution I see is to delete the at_config.js file from Telescope and keep only your one...
Perhaps we should reason about this with @SachaG?
The only other solution I can see would be not to change default useraccounts settings so that Telescope users/developers could change them on their own?
I'd say that we should wait for<EMAIL_ADDRESS>(which is currently in the works...) so to agree on some default settings (options + routes...).
Thoughts?

Hey thanks for taking the time to read through all of it.  I am not sure
what you mean by agreeing  on default settings.  In my opinion the defaults
provided by the useraccounts package are perfect and changing them would
not affect this issue of mine anyway.  A core difference I see in using the
package here versus in any other project is that I lose all the flexibility
that useraccounts provides like being able to change the route's path,
templates which is rendered for that path etc. And yes,  your suggestion on
letting Telescope users/developers configure these settings for themselves
makes compete sense to me.
Besides until now what was I trying  to do was have a custom template which
had a call to atForm within it.  I was not trying to change templates on
the fly. Instead I was calling AT.addField and At.removeFields on the fly,
if you will. But it did not work right from specifying a different template
to the part where I was adding and removing fields, an issue which you have
already referenced to.
Sorry again :P
On Apr 25, 2015 8:19 PM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

Hey @PranayShah https://github.com/PranayShah it is not possible to
implement this last request in case you'd like to have the organization
field required: see this issue
https://github.com/meteor-useraccounts/core/issues/358
Btw, to get different templates you should override the default one (e.g.
with aldeed:template-extension) so you can switch something on the fly...
This said, I'm sorry but in your case the only solution I see is to delete
the at_config.js
https://github.com/TelescopeJS/Telescope/blob/master/lib/config/at_config.js
file from Telescope and keep only your one...
Perhaps we should reason about this with @SachaG
https://github.com/SachaG?
The only other solution I can see would be not to change default
useraccounts settings so that Telescope users/developers could change them
on their own?
I'd say that we should wait for<EMAIL_ADDRESS>(which is currently in
the works...) so to agree on some default settings (options + routes...).
Thoughts?
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-96217520
.

No worries, you're welcome!
The thing about adding/removing fields at run time on the client is impossible: this is one of the selling points of useraccounts and all the structure was designed to enforce them!
If you set a required field, the server won't let you register if you don't provide it: so javascript magicians cannot tweak your required fields from the client side ;-)
When I say

to agree on some default settings
is to have Telescope simply pulling in required useraccounts packages and have no at_config.js file so to let developers do whatever they wish...

Hope it's clearer now.

But I was calling at.Removefield server side via a Meteor method.
Anyway thanks a lot for all the help.  So appreciated.
On Apr 25, 2015 8:46 PM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

No worries, you're welcome!
The thing about adding/removing fields at run time on the client is
impossible: this is one of the selling points of useraccounts and all the
structure was designed to enforce them!
If you set a required field, the server won't let you register if you
don't provide it: so javascript magicians cannot tweak your required fields
from the client side ;-)
When I say
to agree on some default settings
is to have Telescope simply pulling in required useraccounts packages and
have no at_config.js file so to let developers do whatever they wish...
Hope it's clearer now.
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-96220774
.

wow... super hacky @PranayShah!
I wouldn't to that: what if a regular user tries to register in the meanwhile?
You'd face critical races ;-)

Totally agreed :)
On Apr 25, 2015 9:25 PM, "Luca Mussi"<EMAIL_ADDRESS>wrote:

wow... super hacky @PranayShah https://github.com/PranayShah!
I wouldn't to that: what if a regular user tries to register in the
meanwhile?
You'd face critical races ;-)
—
Reply to this email directly or view it on GitHub
https://github.com/TelescopeJS/Telescope/issues/831#issuecomment-96231794
.

Hey, folks! Telescope has changed a lot in the past months, and there is a new React-based version, Telescope Nova (intro video). If you know Crater, it runs on the latest version.
The Legacy version is no longer supported. I'm closing this issue.
I invite you to check the new version, it's awesome!
Happy hacking! 🚀
Ps: by the way, don't hesitate to join the Slack to ask any question, you are welcome! 👍


Fixed job.addChild().encapsulate

Resolves #1643. Calling job.addChild().encapsulate would create two parents. This PR uses the code suggested in #1643 and adds a test to confirm that only one parent exists.

Jenkins, test this please.

Jenkins, test this please.

Jenkins, test this please.