text:
No internet after connection

I can connect to the server successfully (running on godaddy vps), but I cannot connect to or ping any website aside from the vps itself.
I am running Centos 7.  I tried Ubuntu 15.04 before, but it had the same situation.
Here is my server.conf
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
cipher AES-256-CBC
comp-lzo

If I need to supply any other information, I'd be glad to.  Thanks

If on Windows, remember that you need to run the OpenVPN client as an administrator.
Use the script in a clean VPS, if you hadn't already done so.
If during install you specified a different IP address than the one auto detected, don't.

I have the same problem although I did exactly what you said and did WHATEVER advice I got from other websites. No internet connection except vps itself. :(

authors: Nyr ac130kire pooriamo

repo: Nyr/openvpn-install


text:
IPv6 support

It would be very helpful if this script would support IPv6.

This will be done sooner than later, it's the next big upgrade planned.

source: gharchive/issue

authors: Nyr lmalsch

license: mit

license_type: permissive

license_source: bigquery


text:
Swagger error : Structural error What should I modify?

I am building an API documentation, I`m new to programming in general and this is the first time I work in Swagger.
This is my code:
/stareMesaj:
post:
tags:
- Metode disponibile
summary: Stare mesaj
description: Call de verificat stare mesaj. More soon.
operationId: stareMesaj
responses:
 '200':
  description: Ultimele 60 zile -  Nu aveti drept de interogare     stare pentru mesaj
  headers:
    X-Rate-Limit:
      description: calls per hour allowed by the user
      schema:
        type: integer
        format: int32
    X-Expires-After:
      $ref: '#/components/headers/ExpiresAfter'
    content:
    application/json:
      schema:
        type: string
      examples:
        response:
          value: Hello world!
     application/xml:
      schema:
        type: string
      text/csv:
       schema:
        type: string

On the responses tag I get the following error:
Structural error at paths./stareMesaj.post.responses
should only have three-digit status codes, `default`, and vendor      extensions (`x-*`) as     properties
Jump to line 395

I dontknow what to do. I googled the error but cant find it. What is the problem here ?
Thanks in advance

I think you need more indentation beneath the '200' tag, to make the following tags (eg description) properties of that object.

Closing as above, as hopefully resolved, and not an issue with the specification itself.

repo: OAI/OpenAPI-Specification

license_source: github-api


text:
Version Enhancement to Compatibility Strategy

The current OpenAPI Specification includes a field version in the Info Object that is a required string containing a version number for the API. Currently the specification does not state the semantics or syntax of the structure of this string. Community discussion has indicated a preference for semver format and semantics.
Versioning is really just an obvious, intuitive, and commonly used approach to the deeper issue of API compatibility. From that perspective, versioning is just one of several possible compatibility strategies. There are several commonly used approaches to versioning. Many in the hypermedia community feel that we should not version resources, although that pushes potential versioning into the representation. Since the OpenAPI specification describes both the URL and the payload, representation compatibility strategies should be addressed, as well.
I would like to propose that the current info.version be elaborated to a compatibilityStrategy object functionally similar to the Security Definitions and Scheme Objects. To maintain compatibility and for forward migration, the default strategy would map to the equivalent of the current version definition.
An example might be
{
    "openapi": "3.1.0",
    "info": {
        "title": "MyAPI",
        "compatibilityStrategy": "semver"
    },
    ...
}

The details of compatibility strategies and their corresponding objects needs to be elaborated.
Other strategies might include “simple”, “date”, or “migration”. The “simple” strategy might be a single-digit strategy based on a major version or a sequence number as is most commonly represented in URL-based API versions. The “date” strategy is fairly self-evident and might address use cases like Stripe. The “migration” strategy describes an approach I am developing that obviates the need for versioning based on a limited compatibility period.
I would also like to propose that compatibility strategies could apply at smaller granularities than the API as a whole, most notably at the level of the payload entity defined in the Schema Object. This proposal will also impact the evolution of the “deprecated” fields and should be coordinated or merged with issue #782.

While I certainly have opinions about versioning and versioning strategies, it is far too difficult to force people into a single or set of versioning strategies.  Hence the @OAI/tdc did decide collectively to not pick one, nor propose a set of them.  It is open-ended intentionally.

Part of what I'm trying to address here is that the spec narrows the solution space to "versioning strategies" not the broader space of "compatibility strategies" of which not all involve versioning. Additionally, issue #782 suggests that deprecation should be more tightly coupled to versioning as the only compatibility solution.

@fehguy Let me give two compatibility strategies that don't fit into the concept of a single global "version".
Take "hypermedia" for the first, understanding that OAS can't fully describe it yet. With hypermedia, you have changes that warrant a new resource and representation, and changes that evolve an existing representation without warranting a new resource. For the former, hypermedia deals with it by providing the link relations to the new resource, so no versioning is necessary, especially with the use of forms and a shared ontology. For the latter, the versioning problem is pushed down to the level of the representation. In either case, a single global version is unnecessary or insufficient.
For a "migration" strategy, you leverage the property that any incompatible transformation from API A to A' can be decomposed into no more than two transformations, the first of which is mutually compatible and the second is breaking. This allows you to apply the mutually compatible half of the transformation until you have passed the need for compatibility, and only then apply the breaking half of the transformation. This renders global versioning irrelevant or unnecessary while conceptually pushing the compatibility tracking all the way to the atomic level in a way that should not be managed by OAS.
In both of these cases, deprecation needs to be tied to the management of compatibility, not to a global property.
The security schema already sets a precedent for a pattern for representing multiple strategies in OAS. I propose we apply a similar pattern to compatibility strategies, ideally in an extensible way. This allows for the specification of more detailed versioning strategies that could be automatically managed and understood as well as accommodating non-versioning compatibility strategies.

Then the design of your API should be encapsulated into a version concept, which may include "evolving" definitions of responses as defined in your hypermedia strategy. It really doesn't change the version strategy that we've outlined.
Adding more "types" for versions is an unbounded problem as you point out. There will be no value in OAI trying to constrain them to a fixed set.  The smartest move would be to say "versioning strategies are up to the API provider" imho.

All versioning is a compatibility strategy, but not all compatibility strategies are versioning. Saying these approaches "should be encapsulated into a version concept" inverts the generalization relationship, and a single global version doesn't even cover the space of practical and useful versioning strategies adequately.
I'm not saying they should be constrained to a fixed set, but that the typical set should be well-known and defined in a way that is machine-manageable with provisions for extensibility.
In my understanding, this is how the security schema is defined. How is this different?

Labelling a strategy for how you want to ensure backwards compatibility and evolvability in your API as "versioning" is oversimplification.
This space is complex and consists of gradients, where each byte we change in our API surface as well as how it operates under the hood, which states it has and how these are communicated to the client, how the states transition between each other, etc., need to be thoroughly examined and analysed before being implemented.
Where "compatibility strategy" attempts to describe this as the fuzzy and complex space it is, "versioning strategy" labels it as black and white; either you have a new version or you don't. It oversimplifies the problem space and does not allow for the fine-grained compatibility strategy @srvance describes to be communicated and perhaps even inhibits its implementation.

I think my opinion is pretty clear on this, perhaps @OAI/tdc members have other inputs?
I consider there to be virtually zero value in having an open-ended compatibilityStrategy.  Even if we constrain it, it's an unconstrained problem.  It'll never be something that can be described let alone enforced by any sort of tooling.
For that, I suggest using extensions to the spec to add more information where you feel the spec is falling short.  Remember this spec is not trying to solve all problems but as a first said, the @OAI/tdc may have other input on it.

@fehguy: The problem is that the current spec requires the version field, which severely limits the strategies implementers can employ to ensure API compatibility. If it could be made optional, with extensibility in mind, I think everyone would be happy. @srvance has already suggested how that might look like. Here's another example:
{
    "openapi": "3.1.0",
    "info": {
        "title": "MyAPI",
        "compatibility": {
            "strategy": "semver",
            "version": "1.0.1"
        }
    },
}

Here's how that can be extended with something outside of the specification:
{
    "openapi": "3.1.0",
    "info": {
        "title": "MyAPI",
        "compatibility": {
            "strategy": "http://webconcepts.info/concepts/link-relation/"
        }
    },
}

This way, the compatibility field as well as its subfield strategy can be made required, but different values of strategy can require different sibling fields to exist (or not). I hope you get the idea.

eh we're not seeing eye-to-eye.  I'm hoping someone from @OAI/tdc can help because it just doesn't make sense to me, unless you want to imply (and I'm borrowing this quote) that "there is only one version, and that's the latest" in which case, yes, version is a useless field.
If that were the case--and I hope it's not--just set your version: 'n/a' which is technically legal with the spec.  Problem solved!

Versioning is one of many possible compatibility strategies. If you choose to not version your API, it will indeed not have a version number. It might then be that "there is only one version, and that's the latest".
While version: 'n/a' could work, it is more information about what the compatibility strategy of the API is not than what it actually is, which I find rather useless. If a field is required, it would be nice if it could have values that makes sense for more than once use-case. If quite a few use-cases renders the field useless, I'd vote to make it optional or to design a new field that embraces both the covered and the previously uncovered use-cases.

Not only are there compatibility strategies where a global version is irrelevant, those strategies set different expectations around compatibility that are useful to be communicated. "Hypermedia" indicates it may only be an issue in the individual representations, not in the API and all its endpoints as a whole. It also tells you something about the mechanism by which compatibility is provided. "Migration" indicates that you will receive deprecation warnings at fairly small granularity that you will need to respond to. It may set an expectation around response time, but under that strategy, there are no version labels. This is also why it compatibility strategy needs to tie into the deprecation tagging.
@darrelmiller and I spoke about this at API Strat in Boston. His response seemed positive and he suggested I create the issue in the first place.

ok perhaps when he has time he can lead this.  I just don't think there's a practical solution within the goals of the OAI to what you're describing, but if you talked in person he probably gets it better than I do

For better or worse, using a version identifier for an API is by far the most commonly expected declaration of compatibility.  I would love to see better approaches to describing compatibility that could drive tooling, but without specific examples it's hard to make the case for adding complexity to the spec. The examples of semver, simple, date are further precision on the format of the version, not really an alternative to versioning.  This information could be added by including a "x-versionFormat".
I don't think we help the average user by adding a layer of indirection to declaring a version.  I think this area should be explored via specification extensions first and based on adoption we can consider enhancing the specification for more flexibility.
Security is one of those areas where the industry already has a wide range of schemes in practice and therefore it makes sense to model what is currently in common use.  A version identifier is an adequate solution for 95% of users at this point in time.  Having said, that, I would love to see exploration of other approaches to version compatibility.  I just don't think the OpenAPI spec is a place to pioneer new approaches.

For better or worse, using a version identifier for an API is by far the most commonly expected declaration of compatibility.

That's a reason to support it, not a reason to require it.

Lets separate the problem being highlighted from the solution to that problem being proposed. If the version were called revision and described as "the revision of the API description," we wouldn't be having this discussion. I don't think anyone would argue with the value of having a unique identifier for each published revision of your API specification that carries with it some indicator of its place in a sequence. It would be much easier for OAI to define the contents of the field without controversy, and it would serve the machine-readable versioning needs of the tools space.
The problem arises because the field claims to be the version of the API itself and is required with its only extensibility being the avoidance of an internal format specification or of semantics. This makes it useless for cross-tool machine-readability and only partially useful for human consumption, requiring external documentation to properly interpret. Any further features built on it will suffer from the same ambiguity and inconsistency.
As @handrews points out, the prevalence of versioning of APIs means that the standard needs to support it. However, the fact that a significant population of API thought leaders think that versioning is a poor approach to compatibility should be a strong reason not to lock the standard into that singular solution, regardless of whether we can yet enumerate many alternatives.
The alternatives presented provide motivation to not lock the standard to versioning. If you don't like them, that's fine, but you also shouldn't ignore them if you want this standard to become what the industry needs.

If version were called revision then we'd have 2 happy people and over a thousand unhappy ones.  I suggest using extensions as @darrelmiller said.  The concept of version is pretty widely shared (there are 10's of thousands of people using the spec with version required) and I do not see a large number of people asking for us to support what you're asking for.

Because the specification doesn't not define what version looks like, the only thing tooling can do is identify that one OpenAPI definition is a "different version" than another.  It is just an identifier.  If you want to treat that identifier as a kind of revision that doesn't make any statement about compatibility, then go for it.  The fact that semver even exists is a statement that versions don't naturally make compatibility statements.
If you don't want to use version, then leave it blank.  Personally, I would be fine with making it not a required field.  The version attribute isn't required for a spec to be useful.

@darrelmiller How would you feel about defining it as the version of the API description, not of the API itself?
The word version carries connotations that steer users and tools and block alternate approaches. I understand if you don't want ideas you don't feel are fully mature to be represented in the standard yet, but do you really want to prevent them?
Frankly, @fehguy, lots of people feel the pain of versions, but few understand that there are alternatives and what they are. The ones who do usually get drowned out by the ones who insist there aren't practical alternatives or don't want to be bothered. Millions of people thought the world was flat for hundreds of years, and look where we are now. Mass belief is not a strong argument of anything other than mass belief and an acknowledged current perceived reality.
Is there any way to put it to the thousands? Counting reactions, there are five in this thread in favor of the proposal and two against.

OK i'm stepping away from this issue :)  I don't need to get into a tabs vs. spaces religious war, I've stated my position and I remain unconvinced to change it even after further comments.  You have so many ways to work inside the spec for this I don't understand why this is still being debated.  Put the damn revision in your api description or as a vendor extension.  Done.  We can all move on
The "millions of people thought the world was flat" is a personal first for me, at least in GitHub, so thanks for that.

Regarding the original suggestion, it's unclear to me what tooling would benefit from that information.
At this point in time, arguing over the semantics of calling the field revision vs version but keeping it pretty much the same content - really pointless. Not saying it can't be changed, just don't think the semantic difference is important enough to do so now.
However, the main thing is who do we really benefit and why. The strongest case that was brought here was that people should learn to work better, not use versions and they do now and so on and so forth. I don't think it's our mission to educate people, especially not about things that are opinions and not fact. Sure, we recently chose to not support payloads for GET, DELETE and so on, and you can say that it's an educational decision, but it's not. In this case, while "a significant population of API thought leaders" may suggest that, in practice, it is not being used so often, and it may never be used that often. If we support it and it's not even further adopted, we ended up making the spec more complex, making it more difficult to adopt by those who just want to... version.
As for making it required or not - we can debate that. Since we're close to releasing an Implementer Draft, I'm inclined to say no.
Overall, I'm not saying 'no' to the suggestion, but rather 'not now'. Suggest pushing it for review for a future version.

@webron:

At this point in time, arguing over the semantics of calling the field revision vs version but keeping it pretty much the same content - really pointless.

That is not what is being suggested. What's being suggested is to introduce a new field called revision that would mean something entirely different from version. The version field is currently described as such:

Provides the version of the application API (not to be confused with the specification version).

While the suggested revision could be described as:

Provides the revision of the API description document. Not to be confused with the specification version.

While that description could be used for the version field as well, I think developers are hard-wired to think that version means "the version number of my API (library)". There's also the the fact that the current version field is described to mean exactly that as well.
If the version field semantics stay unaltered and the field remains required, OAI is going to be less useful (or even useless) for APIs that have different compatibility strategies. The options I feel we're left with that can still fix the issue are:

Change the version field semantics to apply to the API description document instead of the API itself.
Rename the field to revision and make it apply to the API description document instead of the API itself.
Keep the version field semantics as is, but make the field optional.

Of these options, I would prefer the two first, since having a version number for the API description document is valuable regardless of what compatibility strategy you employ.

@asbjornu You bring up a distinction that I've never considered before.  I like to think of the OpenAPI definition as the "interface" and the API on the backend as the "implementation".  The Version property is the version of the "interface".  I would never consider exposing to consumers the version of the "implementation", that just seems unnecessary and confusing.
Perhaps a solution to this problem is to make it clearer in the specification that the version property is an identifier for definition of the API.  Unless of course I am wrong about that.

@webron Regarding tooling, even with some elaboration of version semantics, tools could improve the compatibility story. It would provide additional information for static analysis of the definition.
For example, semver has pretty well-defined rules about what constitutes which level of version rev. An OAI authoring tool could easily inform a user if a change they were making warranted a major, minor, or patch revision. Similarly, consumption of an OAI spec gives you machine-actionable information about whether compatibility is expected. You can only do that if you know the rules and semantics of the scheme being used.
For non-versioning approaches or approaches that need versioning at different levels (see the "hypermedia" ideas above), it let the tool enforce change management at the appropriate level and in the appropriate way.

@darrelmiller:

You bring up a distinction that I've never considered before.

I'm glad you see it, because it is an important distinction, I think. 😃

I like to think of the OpenAPI definition as the "interface" and the API on the backend as the "implementation". The Version property is the version of the "interface".

That's not how I interpret it.

I would never consider exposing to consumers the version of the "implementation", that just seems unnecessary and confusing.

That's how most people implement versioning in "Web" APIs today; by plunging a version number into the URI of all of the resources. That is most definitely the "implementation" and not the "interface". By not being explicit about this, I strongly believe implementers are going to equal these two concepts and use the same version number in OAI as they do in their URIs.

Perhaps a solution to this problem is to make it clearer in the specification that the version property is an identifier for definition of the API. Unless of course I am wrong about that.

Being explicit is good and important. Choosing the right words and semantics also is. To avoid having to redefine 50 years of existing baggage in the software industry related to the term "version", I think "revision" might be better. Being explicit that it applies to the "interface", "definition" or "description", however you choose to word it, would also help.
Explaining that the version property applies to the physical OAI document itself and not the API implementation, is an important distinction that I'm not sure everyone here agrees on and that I'm certain most people reading the specification is going to misunderstand.

We've modified the wording of the version property, but decided not to extend it with compatibility and such.

That's much better. Thank you. Do you know how the reference tool implementations will use it?

If I found the right document, that's much better indeed. Here's the new wording I found:

Required. The version of the API definition (which is distinct from the OpenAPI specification version or the API implementation version).

authors: asbjornu darrelmiller fehguy handrews srvance webron


text:
improved the css

its better now

good

source: gharchive/pull-request

authors: liamheckrodt lucasbenko

repo: OC-Capstone/HLCapstone

license: MIT


text:
travis_apt_packages produces bad .travis.yml entry

See this PR https://github.com/OCA/server-auth/pull/331
No matter how I pass travis_apt_packages to the answer, it always generate a quoted string.
I guess it has to deal w/ {{ package|tojson }} so I wonder: do we really need to call tojson?

Is there any problem in having it with quotes? I guess it could be needed for some packages that have spaces in the middle of the name...

I'd recommend converting the repo to GitHub actions.

authors: joao-p-marques sbidoul simahawk

repo: OCA/oca-addons-repo-template


text:
[#57] Modal title overflow fix

The overflow now shows up as ellipsis and a caption has been added on hover.
Also contains minor font adjustments and style changes.

Wrong target branch. Closing.


text:
Postman Collection format has changed, gives error in Postman

Hi
I am beginning to work with OData, and was going trough the Learning.
When I was going to download the Postman Collection in Postman at this link:
https://www.odata.org/getting-started/learning-odata-on-postman/
Postman reported that "Collection format V1" is no longer supported, an it have to be converted to format V2.
/Graves

I also stumbled in to this issue, and followed the conversion guidelines specified by postman.
The conversion seem to work fine; the converted collection is here (and can be pasted directly into Postman, just choose "Import ==> Raw text":
{
    "info": {
        "_postman_id": "09ddcd24-002e-e034-8e64-c4a60a80b91a",
        "name": "Postman OData Tutorial",
        "schema": "https://schema.getpostman.com/json/collection/v2.0.0/collection.json"
    },
    "item": [
        {
            "name": "01. Read the service root",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/",
                "description": "All REST APIs should have a single entry point from which a generic hypermedia client can navigate to the resources in the service. In the response we see links to three things: 1. The $metadata document that describes the schema of ther service 2. Links to various collections of objects like People and Airports 3. Links to other top-level items like Me (a singleton) and operations."
            },
            "response": []
        },
        {
            "name": "02. Read the service metadata",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/$metadata",
                "description": "$metadata is an endpoint in OData services that contains a machine-readable description of the service model including type schemas, available operations, etc."
            },
            "response": []
        },
        {
            "name": "03. Read an entity set",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People",
                "description": "One of the most common responses from a REST API is a collection of resources. In this case we asked for the People collection. For each response, the OData service writes a self-described response (another REST principle) by annotating the response with a context URL. This context URL tells the service that the contents of the response are a collection of things in the People entity set. The @odata.nextLink annotation is present because the server opted to split the result set across multiple pages. The client can also drive paging using $top and $skip, but server-side paging is a mitigation against DoS attacks. The value property contains the bulk of the response. Note that @odata.id and @odata.editLink should generally not be present in the payload unless they deviate from convention. In this case it appears that there is a bug in our sample service. Pretend those properties aren't there."
            },
            "response": []
        },
        {
            "name": "04. Get a single entity from an entity set",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')",
                "description": "To get a particular entity from a collection, append a key segment. By default, key segments in OData services are bounded by parens because they may be composite keys, e.g., OrderLine(OrderId=1,LineNumber=1) or alternate keys, e.g., Person(SSN='000-00-0000') and Person(2115) both address the same resource. Some OData services use normal URL segments for key segments, e.g., Orders/1. This is not recommended because of the scenarios mentioned above."
            },
            "response": []
        },
        {
            "name": "05. Get a primitive property",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')/FirstName",
                "description": "Even when fetching a primitive property, an object wrapper is returned rather than returning the raw primitive. This is to protect against a JSON vulnerability."
            },
            "response": []
        },
        {
            "name": "06. Get the raw value of a primitive property",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')/FirstName/$value",
                "description": "If you really want the raw value of a primitive property, you can get it by appending $value to the URL. Note that the Content-Type header indicates that the content is text/plain."
            },
            "response": []
        },
        {
            "name": "07. Navigate to related entities",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')/Friends('scottketchum')/AddressInfo",
                "description": "To navigate the resource graph, keep appending segments representing valid property names as defined in $metadata or in a full metadata response (see query x). In this case we have started from the service root, navigated to the entity set People, navigated to the resource keyed 'russellwhyte', navigated to the Friends property, navigated to the resource keyed 'scottketchum', and finally navigated to the AddressInfo property. Note that the @odata.context URL self-describes the payload."
            },
            "response": []
        },
        {
            "name": "08. Filter a collection",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$filter=FirstName eq 'Vincent'",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$filter",
                            "value": "FirstName eq 'Vincent'"
                        }
                    ]
                },
                "description": "The $filter system query option can be used to filter any collection of resources. Note that the response to a filtered collection is a collection of the same type, regardless of the number of matched resources."
            },
            "response": []
        },
        {
            "name": "09. Filter on enumeration properties",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$filter=Gender eq Microsoft.OData.SampleService.Models.TripPin.PersonGender'Female'",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$filter",
                            "value": "Gender eq Microsoft.OData.SampleService.Models.TripPin.PersonGender'Female'"
                        }
                    ]
                },
                "description": "You can filter any type of collection in OData services. When referring to a member of enum properties, please don't ignore the namespace for the enum property."
            },
            "response": []
        },
        {
            "name": "10. Filter on nested structures",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/Airports?$filter=Location/City/Region eq 'California'",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "Airports"
                    ],
                    "query": [
                        {
                            "key": "$filter",
                            "value": "Location/City/Region eq 'California'"
                        }
                    ]
                },
                "description": "You can use any related properties in a filter clause by using the same segments used in the path to traverse properties."
            },
            "response": []
        },
        {
            "name": "11. Filter using logic operators",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$filter=not(contains(FirstName,'Q')) and (AddressInfo/any(ai:ai/City/Region eq 'WA') or AddressInfo/any(ai:ai/City/Region eq 'ID'))",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$filter",
                            "value": "not(contains(FirstName,'Q')) and (AddressInfo/any(ai:ai/City/Region eq 'WA') or AddressInfo/any(ai:ai/City/Region eq 'ID'))"
                        }
                    ]
                },
                "description": "You can use and, or and not to create more complex filter clauses."
            },
            "response": []
        },
        {
            "name": "12. Filter using any/all operators",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$filter=Emails/any(e: endswith(e, 'contoso.com'))",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$filter",
                            "value": "Emails/any(e: endswith(e, 'contoso.com'))"
                        }
                    ]
                },
                "description": "You can use any/all lambda-style filters for collection properties."
            },
            "response": []
        },
        {
            "name": "13. Filter using built-in functions",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')/Trips(0)/PlanItems/Microsoft.OData.SampleService.Models.TripPin.Flight",
                "description": "Built-in functions may be leveraged to filter the collection."
            },
            "response": []
        },
        {
            "name": "14. Sort a collection",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$orderby=length(FirstName) desc,UserName",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$orderby",
                            "value": "length(FirstName) desc,UserName"
                        }
                    ]
                },
                "description": "You can use the $orderby system query option to specify ordering criteria. You can use many of the functions usable in $filter in $orderby as well."
            },
            "response": []
        },
        {
            "name": "15. Client-side paging",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$top=2&$skip=2",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$top",
                            "value": "2"
                        },
                        {
                            "key": "$skip",
                            "value": "2"
                        }
                    ]
                },
                "description": "There are two types of paging in OData services. Servers can enable server-side paging, returning nextLinks that clients can follow to subsequent pages. Clients can drive paging using $top and $skip."
            },
            "response": []
        },
        {
            "name": "16. Counting the elements in a collection",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People/$count",
                "description": "If you want to know how many items meet a condition, you can use the $count path segment. Note that the Content-Type header indicates that the content is text/plain. Although it doesn't work with system query options in the reference service, $count can typically be combined with $filter."
            },
            "response": []
        },
        {
            "name": "17. Expand related entities",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$expand=Friends,Trips",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$expand",
                            "value": "Friends,Trips"
                        }
                    ]
                },
                "description": "You can use the $expand system query option to include related resources. The expand clause can include many of the other system query options, enabling left-join type semantics. Also, you can expand <property>/$ref in order to get just the links to the related resources."
            },
            "response": []
        },
        {
            "name": "18. Select the properties",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$select=FirstName,LastName",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$select",
                            "value": "FirstName,LastName"
                        }
                    ]
                },
                "description": "You can use the $select system query option to only return specified properties."
            },
            "response": []
        },
        {
            "name": "19. Request full metadata",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": {
                    "raw": "http://services.odata.org/V4/TripPinService/People?$format=application/json;odata.metadata=full",
                    "protocol": "http",
                    "host": [
                        "services",
                        "odata",
                        "org"
                    ],
                    "path": [
                        "V4",
                        "TripPinService",
                        "People"
                    ],
                    "query": [
                        {
                            "key": "$format",
                            "value": "application/json;odata.metadata=full"
                        }
                    ]
                },
                "description": "By default OData services return an extremely compact JSON format. This happens by stripping out all of the metadata that should be calculable by \"smart\" OData clients. For generic hypermedia clients, you can request additional metadata by using the Accept header or $format system query option to request application/json;odata.metadata=full. In this case, we get a bunch of additional annotations in the payload indicating type information and relationships to related resources."
            },
            "response": []
        },
        {
            "name": "20. Casting types",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')/Trips(0)/PlanItems/Microsoft.OData.SampleService.Models.TripPin.Flight",
                "description": "Another way of filtering items is to use a type cast segment. In this case we are looking for all of the flights that are part of Russell's trip. A type cast also allows us to append additional path segments that are properties of the subtype."
            },
            "response": []
        },
        {
            "name": "21. Create an entity",
            "request": {
                "method": "POST",
                "header": [
                    {
                        "key": "Content-Type",
                        "value": "application/json"
                    }
                ],
                "body": {
                    "mode": "raw",
                    "raw": "{\n  \"UserName\": \"miathompson\",\n  \"FirstName\": \"Mia\",\n  \"LastName\": \"Thompson\",\n  \"Gender\": \"Female\"\n}"
                },
                "url": "http://services.odata.org/V4/TripPinService/People",
                "description": "To create a resource, send a POST to a collection."
            },
            "response": []
        },
        {
            "name": "22. Delete an entity",
            "request": {
                "method": "DELETE",
                "header": [
                    {
                        "key": "If-Match",
                        "value": "W/\"08D2931BACB7D7FD\""
                    }
                ],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('miathompson')",
                "description": "To remove a resource, send an HTTP DELETE to the resource URL. Note: since the People entity set has concurrency enabled, you will need to request the resource and set the If-Match header to the appropriate value to run this request."
            },
            "response": []
        },
        {
            "name": "23. Update an entity",
            "request": {
                "method": "PATCH",
                "header": [
                    {
                        "key": "If-Match",
                        "value": "W/\"08D2931BACB7D7FD\""
                    },
                    {
                        "key": "Content-Type",
                        "value": "application/json"
                    }
                ],
                "body": {
                    "mode": "raw",
                    "raw": "{\n  \"Emails\": [\"miathompson@contoso.com\", \"miathompson@example.com\"]\n}"
                },
                "url": "http://services.odata.org/V4/TripPinService/People('miathompson')",
                "description": "To update a resource, send a PATCH request with the properties you wish to modify. You can also use PUT, but the semantics for put require all properties to be either sent on the wire or reverted to their default values. Note: since the People entity set has concurrency enabled, you will need to request the resource and set the If-Match header to the appropriate value to run this request."
            },
            "response": []
        },
        {
            "name": "24. Invoke an unbound function",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/GetNearestAirport(lat = 33, lon = -118)",
                "description": "OData support unbound custom functions. The unbound functions can be invoked either with parameters or not and unbound functions can be viewed in the $metadata. Note: OData functions CANNOT have side effect, so only GET verb is allowed."
            },
            "response": []
        },
        {
            "name": "25. Invoke a bound function",
            "request": {
                "method": "GET",
                "header": [],
                "body": {
                    "mode": "formdata",
                    "formdata": []
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')/Microsoft.OData.SampleService.Models.TripPin.GetFavoriteAirline()",
                "description": "OData support bound custom functions. The bound functions are bounded to a resource. Note: OData functions CANNOT have side effect, so only GET verb is allowed."
            },
            "response": []
        },
        {
            "name": "26. Invoke a bound action",
            "request": {
                "method": "POST",
                "header": [
                    {
                        "key": "Content-Type",
                        "value": "application/json"
                    }
                ],
                "body": {
                    "mode": "raw",
                    "raw": "{\n\"userName\": \"scottketchum\",\n\"tripId\": 0\n}"
                },
                "url": "http://services.odata.org/V4/TripPinService/People('russellwhyte')/Microsoft.OData.SampleService.Models.TripPin.ShareTrip",
                "description": "OData support bound custom actions. Actions can have side effects. So the HTTP verb for an OData action can be GET,POST,PUT,DELETE according to the behavior of the action. In the example below, the action implies a POST."
            },
            "response": []
        }
    ]
}

Thanks @Kilsgaard & @alexbjorlig. I will take a look at this.

authors: Kilsgaard alexbjorlig marabooy


text:
Checkpoint name attributed may needs updated for OFA_large

I downloaded the pre-trained OFA-large checkpoint here: https://ofa-beijing.oss-cn-beijing.aliyuncs.com/checkpoints/ofa_large.pt
And try to load the model by
task = tasks.setup_task(cfg.task)
models, cfg = checkpoint_utils.load_model_ensemble(
    pre_trained_model_path,
    task=task
)

But it doesn't work and it shows didn't find the corresponding model name.
Then I check the checkpoint , found the name is m6_unify_large
Then I modify this line https://github.com/OFA-Sys/OFA/blob/main/models/ofa/ofa.py#L320 to replace ofa_large to m6_unify_large then everything works fine.
I guess maybe need to update a bit the checkpoint state and upload again

Thank you so much for pointing this out! We have updated and uploaded the OFA-large checkpoint.

authors: allanj logicwong

repo: OFA-Sys/OFA


text:
0.5.x: merge PRs

This merges the following PRs:

https://github.com/OISF/libhtp/pull/123
https://github.com/OISF/libhtp/pull/125

ping

Hello, the PR will be merged soon.
We need to run some QA on it.

Could you update this to include #129 ?

Add #122 while at it :)

authors: glongo inliniac socketpair

repo: OISF/libhtp


text:
tests: add tests for negated protocol matching

#615 with now passing tests

Merged in #1013

repo: OISF/suricata-verify


text:
Stats flow ctr 5769 v1

Requires https://github.com/OISF/suricata/pull/8328

Suricata PR was merged

Replaced by https://github.com/OISF/suricata-verify/pull/1061


text:
docker-compose up -d  so slowly

what I can do is just waiting after I run the command 'docker-compose up -d', the download speed get more and more slow tilll nothing speed at all.

I think it's a network or hub.docker.com issues and has nothing to do with our product itself.
You can download images via calling for example docker pull nextcloud:fpm for this line in docker-compose and same for others

I think it's a network or hub.docker.com issues and has nothing to do with our product itself.
You can download images via calling for example docker pull nextcloud:fpm for this line in docker-compose and same for others

I think it's your network or hub.docker.com issues and has nothing to do with our product itself.
You can download images via calling for example docker pull nextcloud:fpm for this line in docker-compose and same for others

yes,I have addressed this issue perfectly. thank you

I think it's your network or hub.docker.com issues and has nothing to do with our product itself.
You can download images via calling for example docker pull nextcloud:fpm for this line in docker-compose and same for others

yes,I have addressed this issue perfectly. thank you

In that case I'll close your issue

In that case I'll close your issue

authors: ShockwaveNN wqtb

repo: ONLYOFFICE/docker-onlyoffice-nextcloud


text:
Added print tracking to GA

What is the context of this PR?

Added the ability to track when a user opens up a print option (file > print || cmd + p) through Google Analytics

How to review

Try a print option in a survey on dev_mode and check that it comes through on Google Analytics
Suggest better place for code? (maybe in analytics.js?)

@hamishtaplin tried with dev_mode on Safari and Chrome and works, not sure about testing on other browsers.

@hamishtaplin where are we at with this one?

repo: ONSdigital/eq-survey-runner


text:
Remove multimode flag

What and why?
How to test?
Trello

/deploy manna

/deploy robinm3

authors: insacuri matthew-robinson-ons

repo: ONSdigital/response-operations-ui


text:
Revert "fpgad: fix issue identified by checkers"

This reverts commit f788a8ffefc383fd56363892e1a44ad72369e2fe.

Decided to tag this an "not an issue" in the tool.

repo: OPAE/opae-legacy


text:
DocsArchive-15.0.0.0Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target/pull/877 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-archive-test-target.git

Docs Build status updates of commit 52279e1:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-GitBranchDeletedOrForcePushed] Cannot sync git repo to specified commit because branch Release_Archive_master_2021-06-02-08-16-39 has been deleted or has been force pushed

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


text:
DocsArchive-15.0.0.0Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_a7e745e1-251d-481b-85ba-e9b3f325cd9c/pull/1 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-archive-test-target_a7e745e1-251d-481b-85ba-e9b3f325cd9c.git

Docs Build status updates of commit 9c36d10:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: RepositoryUnauthorizedWithSourceCommit] Git data access to 'https://github.com/opstest2/docs-archive-test-source' (branch: Release_Archive_main_2022-01-25-02-17-44) is not authorized.. It looks like this might be the first time user: v-alji submitted a pull request to this repo. Before user can run builds in a pull request, he/she can enable 'v-alji' GitHub account in Docs by visiting Docs Portal (https://ops.microsoft.com). After enabling his/her account (v-alji), close and then reopen this pull request to start another build.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


text:
DocsArchive-1.0.0.0Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_976b8e8b-4b64-4eba-b0a7-bd628c9e6315/pull/1 is merged into live branch.
Auto archive content to https://github.com/OPS-E2E-PPE/docs-archive-test-target_976b8e8b-4b64-4eba-b0a7-bd628c9e6315.git

Docs Build status updates of commit da4ac51:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-10-11-02-45-14 has been deleted or has been force pushed: fatal: Couldn't find remote ref Archive_master_2019-10-11-02-45-14

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

authors: VSC-Service-Account v-alji


text:
Remove abeg from tech companies

Abeg is now pocket app.

Hi I created a PR for this :) (#130)

authors: FreemRL gray-adeyi

repo: OSCA-Ado-Ekiti/tech-companies-in-africa


text:
In-Demand Skilling

Georgia DOL
Top In-demand skills with a real-time look at the power of data analytics, relational databases, and data science currently wield.
with Wind
principal chief and creative strategist c brennan poole holds

[x] Data Analysis
[x] Mathematics
[x] Data Management
[x] Data Warehousing
[x] Sales Modeling
[x] Data Mining
[x]Extraction, Transformation, & Loading (ETL)
[x] Relational Databases
[x] Spreadsheets
[x] Risk Management
[x] TK
[x] TK
[x] TK
[x] TK
[x]  TK

Best,
x._______
with Wind
+1 470-580-1515
gitactionable@chasingthewindllc.com

Source URL:
https://www.employgeorgia.com/jobseekers/explorer/report/degreecertification/613#
BrowserChrome 85.0.4183.83OSWindows 10 64-bitScreen Size2560x1080Viewport Size3840x1332Pixel Ratio@0.6666666865348816xZoom Level100%

[x] Business Analysis
[ ] Economics
[ ] Validation
[ ] Business Process
[ ] Risk Management
[ ] Underwriting
[ ] Database Administration
[ ] Database Design
[ ]
[ ]

repo: OUDcollective/Qualitative-Self


text:
allows to test mongodb uri via env vars

This restores the ability to pass in MONGOLAB_URI and MONGODB_URI as env vars to set the mongo db uri.
Fixes #173

@bizob2828 Thanks for the PR. LGTM

Thanks @bizob2828 this PR seems good to me. I will move the target branch to version-1.5. I will merge it tomorrow, so this PR will count you for Hacktoberfest 🎉

ok thanks @UlisesGascon.  When will 1.5 be released? I'm currently just using the fork in our test harness but would love to restore using this main repo

@bizob2828 not sure yet about the date. There are many issues and PRs on going. I will ping you back when we have an estimation 👍

authors: UlisesGascon bizob2828 ckarande

repo: OWASP/NodeGoat


text:
Fix Mongo version to before OP_QUERY deprecation

OP_QUERY was deprecated in 5.0. Fix Mongo version to 4.0 instead of "latest".

Looks good.

Thank you, this is great @Trawais 👍

authors: lirantal steverify


text:
Error in Travis

https://travis-ci.org/OWASP/django-DefectDojo

Should be fixed now.

authors: aaronweaver devGregA

repo: OWASP/django-DefectDojo


text:
.appveyor.yml: Retry Chocolatey installs and PhantomJS

This adds an appveyor-retry wrapper around parts of the AppVeyor build
that have intermittently failed in the past. Here are some example
failures:

https://ci.appveyor.com/project/josephfrazier/browser-extension/build/1.0.44
https://ci.appveyor.com/project/stefanbuck/browser-extension/build/1.0.177

See the commit messages for more details.

Good job 👍 Maybe we can move away from PhantomJS and replace it with Headless Chromium someday.

Another potential alternative is jsdom, assuming the tests only need to know about the DOM, rather than requiring layout/rendering or other "real browser" stuff. See here for more details on the differences between PhantomJS and jsdom: https://github.com/tmpvar/jsdom#jsdom-vs-phantomjs

The other day, I was thinking about using a headline chrome instance for testing. I know jsdom and I really like it. The only downside is that jsdom doesn't support web extension API's.
Right now, we use a fake api implementation in order to test the API, but this feels a bit messy.

authors: josephfrazier stefanbuck

repo: OctoLinker/browser-extension


text:
API for fetching channel/video information

Is your feature request related to a problem? Please describe.
I am trying to dynamically embed our videos on our company website so that new uploads will automatically be featured . It seems currently the only way to do this is using the RSS feature which is not ideal. It causes slow page loading, because the whole feed needs to be fetched. It also is not very fun working with XML. Aside from that, the RSS feature also appears to  have a strict CORS setting, making the only solution I've found is to use a proxy.
Describe the solution you'd like
Ideally, an API that can deliver a  smaller batch of channel/video information in JSON.
Describe alternatives you've considered
A faster solution would be to give the ability to whitelist a domain on our channel, so we can use the RSS feature. This, however, still won't fix the slow page loading issue.
Additional context
If there's any existing feature that can solve my problem that I don't know of, please let me know. Thank you!

Are you trying to embed multiple videos at a time, or only the latest one?

Multiple videos. For example, the 5 most recent videos will be shown, and the user can hit next to show the next 5.

Email us at hello@odysee.com and reference this chat + provide your channel, we'll get a query over that will give you the embeds via json. At this time we probably wouldn't support accessing outside embeds, and I know showing multiple embeds is a bit ugly right now. Eventually can maybe support a special embed type of multiple videos.

authors: highlanderdev tzarebczan

repo: OdyseeTeam/odysee-frontend


text:
Converting to HTML and back to WML causes loss of font type on bulleted lists

 If you convert to HTML and then back to WML the font type is lost in some cases.  If I create a bulleted list in Word my configuration uses “Symbol” size 11 font for the bullets by default.  It uses “Calibri (Body)” size 11 for the text following the bullet.

 If I convert this to HTML and then back to WML using the WmlToHtmlConverter and then the HtmlToWmlConverter both the bullets and the text turn to “Times New Roman” size 12.  This causes the bullets to appear as empty rectangle blocks instead of the traditional filled circle.

Libraries used,
DocumentFormat.OpenXml 2.6.0.0
OpenXmlPowerTools 4.2.0.0
System.Management.Automation 1.0.0.0 (6.1.7601.17515)
Code to reproduce
using DocumentFormat.OpenXml.Packaging;
using OpenXmlPowerTools;
using System.IO;

namespace HtmlConversionIssue
{
    class Program
    {
        static void Main(string[] args)
        {
            var documentBytes = File.ReadAllBytes("BulletedList.docx");
            using (var memoryStream = new MemoryStream(documentBytes.Length))
            {
                memoryStream.Write(documentBytes, 0, documentBytes.Length);
                using (var wordDocument = WordprocessingDocument.Open(memoryStream, true))
                {
                    RevisionAccepter.AcceptRevisions(wordDocument);
                    var convertedHtml = WmlToHtmlConverter.ConvertToHtml(wordDocument, new WmlToHtmlConverterSettings());
                    var convertedWml = HtmlToWmlConverter.ConvertHtmlToWml(string.Empty, string.Empty, string.Empty, convertedHtml, HtmlToWmlConverter.GetDefaultSettings());

                    convertedWml.SaveAs("ConvertedAndBackAgain.docx");
                }
            }
        }
    }
}
[BulletedList.docx](https://github.com/OfficeDev/Open-Xml-PowerTools/files/291519/BulletedList.docx)

Closing all issues as this repo is being archived and will no longer be maintained by Microsoft. The project is licensed for continued use and development by forking to your own repo.

repo: OfficeDev/Open-Xml-PowerTools


text:
Office gallery automation updates

I made the following changes

removed the YAML metadata from the readme file
added a YAML file with the metadata info

These changes allow us to automatically update the Office gallery (https://developer.microsoft.com/en-us/office/gallery) with information for this tool. This means whenever this tool is referenced in the Office / Teams Portals, the user will be seeing the most up-to-date information.

PR merged manually

authors: nokafor wictorwilen

repo: OfficeDev/generator-teams


text:
Messages Queued

Hi, I have deployed the Author App to a Team and added the User App to the Teams client, however when I send messages to either a Team or the Client App the messages are queued.
I have tried restarting the App Service and functions.

Hi @willcotton ,
Thanks for raising the query. There are multiple reasons for this issue.

What is the version of the app?
One of the reasons might be incorrect configuration. Please verify the configuration end-end.
Check whether the Supported type parameter for app registration is as per the deployment guide. Here is the reference.
Author-multiple
User-multiple
Graph-my organization

Hope it helps

Hi,
App is v5.3
App Registrations:

Author-multiple
User-multiple
Graph-multiple (I have just switched this to my organization and restarted the App)

I have deployed the App in a single tenant and I have used Front Door.  We have uploaded the author app package to a Teams channel and then uploaded the User App to the same Teams client and then attempted to send messages directly to the User App and the Team Channel.

Thanks

On switching the supported account type from multiple organization to my organization, able to send the message?

No exactly the same issue.

Hi @willcotton ,
Could you please share the deployment status of each prep-function. Here is the reference.

Please share the screenshot of the logs section of prep-function. Here is the reference.

@willcotton ,  It seems that function apps got failed/not connected to the repository. Please follow the below procedure.

To reach failed resources, Go to azure portal-->Go to resource group(Where the deployment has been done)-->Select  Data-Function from list of resources-->Go to Deployment Center-->Click on Settings

If the resource is not pointing to intended repository and  showing empty. Please connect to the external Git and point to the official repository.

Or Please click on refresh in the logs section to know the status of the resource. if the resource is connected to the intended repository and status showing as failed, please click on SYNC.

Please repeat the same for remaining function apps i.e., prep-function and function.

Once the status turns to Success(active) in the logs section, try sending a message.

Keep us posted

Hi, I have updated all functions to > https://github.com/OfficeDev/microsoft-teams-apps-company-communicator.
Messages are still not sending, however they are no longer queued.

Could you please share the screenshot of prep-function deployment status

@willcotton ,Could you please cross verify the secrets. Please refer to the issue no:992

Hi, I can confirm the secrets are correct in key vault for App, Author and User.
Thanks

Hi @willcotton ,
Please share the Zipped manifest files

manifest.zip
Hi, I have taken the company name out most places.
Thanks

@willcotton It appears to be a configuration issue. The quickest solution is to clean up the resources and start a fresh deployment. However, if you prefer not to redeploy, please double-check the authentication setup step. If the issue persists, please share your Outlook ID.

Hi, I have verified the authentication setup and this is configured as the deployment guide.

My Outlook ID > willcotton@hotmail.co.uk

@willcotton ,
Thank you for providing the mail id, will track the conversation internally.

Hi, are you wanting to do a remote session via my Outlook ID?
Thanks

Hope you received the message internally.

Hi, I have received the email notification from here to my work email but nothing else.
Thanks

Please let us know if you are still facing this issue and require assistance and we will be happy to discuss. If no further action is needed at moment and no response is received, we will close out the issue in 3 business days. You may also always open a new issue or respond here if something does come back up.

authors: gsv022 v-jaygupta v-royavinash willcotton


text:
Notifications not being sent to users even though they are in the correct groups

Hello,
We are currently using v5.3 of the company communicator, and have seen a few users having issues with receiving messages.
They don't have the bot blocked, muted or hidden, they have just never received the messages. Permissions in the teams admin center look ok and they have the user app installed.
When a message is sent they are not on the list of recipients at all even though it is going to their group (note below how the message sent to 3 users only, when there are 4 in the group)

Is there anything else we can try to resolve this for the affected users?

Hi @EMEAWebEnvironmentsTeam ,
Thanks for raising the query. Could you please try sending the message using 4th sending option-DL
Keep us posted

Hi @gsv022
Thanks for your response. These messages are being sent via the 4th option (DL), as below:

@EMEAWebEnvironmentsTeam , Could you please try other sending options now including 3rd option.

Hi @gsv022,
Thanks for your response.
Option 1: They are able to see the notifications when they are sent to the general channel of one of their teams
Option 2: They still don't receive the notifications this way (completely missing from the recipients when the results are exported, same as Option 4)
Option 3: We wouldn't be able to test this unfortunately as we are quite a large company and only send notifications to sub-groups. But I suspect the result would be the same as option 2 and 4

Hi @EMEAWebEnvironmentsTeam ,
Please share your email id(outlook id or teams id) so that we can continue discuss the issue internally.

Hi @gsv022,
I can be reached at rayner.obrien1@computershare.co.uk
I look forward to hearing from you.

Hi @EMEAWebEnvironmentsTeam ,
I have sent a procedure to the given mail. Please perform and keep us posted.


text:
Token App not available in a meeting on Linux/MacOS

I am using:

Microsoft Teams version 1.3.00.28779 (64-bit) on Windows 10
Microsoft Teams version 1.3.00.25560 (64-bit) on Ubuntu 20.04

I have added the Token app in a meeting created through the calendar app. During a meeting on Windows I can click on the token app:
Windows 10

Ubuntu 20.04
However, on Linux there is no such button:

MacOS / Web version
I tried on latest Mac OS desktop version - there is no button there. Web version also does not show the Token App.
.
Question
Are in-meeting custom side-panels only available on Windows, the desktop version?

Add the app from the desktop application of MS Teams

Try to add the app from the desktop application of MS Teams

The first part of my original post states:

I am using:

Microsoft Teams version 1.3.00.28779 (64-bit) on Windows 10
Microsoft Teams version 1.3.00.25560 (64-bit) on Ubuntu 20.04

This is the desktop version.


text:
Note availability of newer requirement sets

Do we need to note which Office applications support OpenWindowBrowserApi on the Open Window Browser API requirement sets page?

Docs Build status updates of commit e4e37bf:
:white_check_mark: Validation status: partially passed

File
Status
Preview URL
Details

:x:Error

Details

docs/overview/office-add-in-availability.md
:white_check_mark:Succeeded
View

[Error-RuningBuildFailed] Some unexpected errors happened when running build, please open a ticket in https://SiteHelp and include the error report for our team to troubleshoot

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit fb253c4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/overview/office-add-in-availability.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 6b28204:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/overview/office-add-in-availability.md
:white_check_mark:Succeeded
View

docs/reference/requirement-sets/open-browser-window-api-requirement-sets.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit afbdfdc:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/overview/office-add-in-availability.md
:white_check_mark:Succeeded
View

docs/reference/requirement-sets/open-browser-window-api-requirement-sets.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

repo: OfficeDev/office-js-docs-pr


text:
feat(fixtures) add function to locate relative fixtures

By providing a relative path from the current test file it will
return an absolute path to the fixture.
Closes #644

\o/

This PR introduced 15 warnings from Luacheck. Admittedly this wasn't easy to see before and at the time you branched the GitHub Action for this wasn't active so it didn't run on the PR, it was only evident after it merged to master.

🙈
fixed in #653

authors: DorianGray Tieske alerque

repo: Olivine-Labs/busted


text:
always need to rebuild chainstate after restarting omnicored

I am running a omnicore in a docker file, i was doing a backup over the blockchain data, and stopped the omnicored via omnicore-cli stop method (which is docker exec -it omnicore /omnicore/bin/omnicore-cli stop, executed from host machine.)
After stopping, here's my debug log,
2019-01-10 09:18:36 tor: Thread interrupt
2019-01-10 09:18:36 torcontrol thread exit
2019-01-10 09:18:36 addcon thread interrupt
2019-01-10 09:18:36 scheduler thread interrupt
2019-01-10 09:18:36 msghand thread interrupt
2019-01-10 09:18:36 net thread interrupt
2019-01-10 09:18:40 opencon thread interrupt
2019-01-10 09:18:40 Shutdown: In progress...
2019-01-10 09:18:40 StopNode()
2019-01-10 09:19:15 Shutdown: done

When it restarted, here's the log,
2019-01-10 09:28:51 Omni Core version v0.3.1
2019-01-10 09:28:51 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-01-10 09:28:51 Default data directory /root/.bitcoin
2019-01-10 09:28:51 Using data directory /omnicore/data
2019-01-10 09:28:51 Using config file /omnicore/data/bitcoin.conf
2019-01-10 09:28:51 Using at most 125 connections (1048576 file descriptors available)
2019-01-10 09:28:51 Using 16 threads for script verification
2019-01-10 09:28:51 scheduler thread start
2019-01-10 09:28:51 libevent: getaddrinfo: address family for nodename not supported
2019-01-10 09:28:51 Binding RPC on address :: port 8332 failed.
2019-01-10 09:28:51 HTTP: creating work queue of depth 16
2019-01-10 09:28:51 Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
2019-01-10 09:28:51 HTTP: starting 4 worker threads
2019-01-10 09:28:51 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-01-10 09:28:51 Using wallet wallet.dat
2019-01-10 09:28:51 init message: Verifying wallet...
2019-01-10 09:28:51 CDBEnv::Open: LogDir=/omnicore/data/database ErrorFile=/omnicore/data/db.log
2019-01-10 09:28:52 Bound to [::]:8333
2019-01-10 09:28:52 Bound to 0.0.0.0:8333
2019-01-10 09:28:52 Cache configuration:
2019-01-10 09:28:52 * Using 1024.0MiB for block index database
2019-01-10 09:28:52 * Using 8.0MiB for chain state database
2019-01-10 09:28:52 * Using 15352.0MiB for in-memory UTXO set
2019-01-10 09:28:52 init message: Loading block index...
2019-01-10 09:28:52 Opening LevelDB in /omnicore/data/blocks/index
2019-01-10 09:29:01 Opened LevelDB successfully
2019-01-10 09:29:01 Using obfuscation key for /omnicore/data/blocks/index: 0000000000000000
2019-01-10 09:29:01 Opening LevelDB in /omnicore/data/chainstate
2019-01-10 09:41:19 Opened LevelDB successfully
2019-01-10 09:41:19 Using obfuscation key for /omnicore/data/chainstate: c3af64913ad8eb65
2019-01-10 09:41:50 LoadBlockIndexDB: last block file = 1490
2019-01-10 09:41:50 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=12, size=8374351, heights=557854...557865, time=2019-01-10...2019-01-10)
2019-01-10 09:41:50 Checking all blk files are present...
2019-01-10 09:41:50 LoadBlockIndexDB: transaction index enabled
2019-01-10 09:41:50 LoadBlockIndexDB: hashBestChain=0000000000000000001f1ab17d82075248eb9791dcb0e626c4245d5b81bf0ff9 height=557331 date=2019-01-06 18:18:26 progress=0.999361
2019-01-10 09:41:50 init message: Rewinding blocks...
2019-01-10 09:41:54 init message: Verifying blocks...
2019-01-10 09:41:54 Verifying last 6 blocks at level 3
2019-01-10 09:41:54 [0%]...[16%]...ERROR: ApplyTxInUndo: undo data overwriting existing transaction
2019-01-10 09:41:54 ERROR: ApplyTxInUndo: undo data overwriting existing transaction
2019-01-10 09:41:54 ERROR: ApplyTxInUndo: undo data overwriting existing transaction
......
2019-01-10 09:41:59 ERROR: ApplyTxInUndo: undo data overwriting existing transaction
2019-01-10 09:41:59 ERROR: VerifyDB(): *** coin database inconsistencies found (last 7 blocks, 0 good transactions before that)

2019-01-10 09:41:59 : Corrupted block database detected.
Please restart with -reindex or -reindex-chainstate to recover.
2019-01-10 09:41:59 Aborted block database rebuild. Exiting.
2019-01-10 09:41:59 Shutdown: In progress...
2019-01-10 09:41:59 scheduler thread interrupt
2019-01-10 09:41:59 StopNode()
2019-01-10 09:41:59 Shutdown: done

and here's my getinfo, after running with -reindex-chainstate
{
  "version": 130200,
  "protocolversion": 70015,
  "walletversion": 130000,
  "balance": 0.00000000,
  "blocks": 263752,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 189281249.2810329,
  "testnet": false,
  "keypoololdest": 1546801596,
  "keypoolsize": 100,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": ""
}

I've been stuck at this step for over a week now, any help will be appreciated, thanks!!!

Hello, please upgrade to the newest version v0.4.0. If the issue still remains, please let me know.

repo: OmniLayer/omnicore


text:
Lang Server Client in C#

I am new to LSP and looks like all the example clients are in Node (JS / TS). Before I reinvent the wheel, is they're an LSP client sample anyone is aware of ?
Thanks
Jay

Interesting timing, just saw this now https://docs.microsoft.com/en-us/visualstudio/extensibility/adding-an-lsp-extension, a day old :-)

https://github.com/tintoy/dotnet-language-client :)
Interesting to see they are adding an LSP client for VS; my repo includes an example of that but it used to be kinda painful before the most recent release of the full .NET framework (.NET Standard dependencies).

BTW, I'm in the process of contributing that client into this repository (but feel free to use it from there in the meanwhile).

And feel free to chat on slack (if that's your thing) I'd like to hear more about this development. https://omnisharp.herokuapp.com/

Is anyone working on a visual studio sample testextension like the atom/vscode one now that VS2017 Update8 has native LSP support?

authors: david-driscoll japj jayonsoftware tintoy