bfarber

This is part of what archiving does, specifically. The content remains present in an archived state, but is not available for searching or interacting with (replying, editing, etc.).

If you choose to "delete" a member, then you delete the member. You are not "deleting from a group". I'm afraid this is simply how it works. When you go to delete a member, do you not get a popup similar to the following? Is there a way to make this modal clearer that might help prevent confusion in the future perhaps?

Command line php and the php engine used by the webserver are not always the same. You may need to check your webserver configuration to figure out which PHP library it is currently using.

There's some good discussion in here about the behavior of invoice generation so I've moved the topic to the feedback forum.

Widgets are not specific to a node, but rather to a page "type". If you add a sidebar widget in a forum, it will show in all forums. Unfortunately, to show different images in different forums you would need a customization of some sort to accomplish this.

You can Create a product which issues a license key Generate an invoice for a user for that product Give the user account credit, mark the invoice as paid, or add a negative value adjustment to the invoice so that $0 is due. In this case, the user will then have an instance of that product "purchased", and an associated license key.

We did not integrate Grammarly, however it does not work correctly with CKEditor 4 so we had to explicitly disable Grammarly in editor fields in a past release.

Imagine that your files are stored above the web root directory, basically. 🙂

This is an issue that should be rectified in an upcoming release.

Yes, keys are automatically generated when an instance of the product is purchased.

Typically you can mass-delete things across pages. This behavior may not exist within support requests, but the reality is most support systems don't have pages of content they intend to delete so it's likely the suggestion has simply never come up before. I would recommend cross-posting in the feedback forum if you'd like to see this behavior implemented. There may even already be a suggestion topic there you can add your voice to.

If the custom email isn't working, I would recommend submitting a ticket as that sounds like a bug.

No, there is no difference in behavior behind the scenes. We serve the same HTML output, same caches, etc. regardless of the device. There are minor javascript differences (i.e. there are some areas of javascript that do like "if( mobile ) { do this }") but those instances are minimal. The legwork of the difference in display comes from responsive CSS.

AdminCP > Commerce > Products > Edit Product > Purchase Benefits tab.

We use "ipsColumn ipsColumn_narrow" to hold the image which has a limit of 120px, and then on the image we are using "ipsThumb ipsThumb_bg ipsThumb_medium" which is limited to 125px. You'd likely need to adjust the appropriate template(s) to change these classes to allow for larger images.

Well, unlike most areas with a unique error code I can see this error code is repeated a few times in our code base (an issue I'll address shortly). For the combination of this error code and the response NO_PERMISSION, it would indicate that either (1) you are using an OAuth access token but hitting an endpoint tagged as "apiclientonly" (meaning only an API key can access the endpoint), or (2) you are not using an OAuth access token and are hitting an endpoint tagged as "apimemberonly" (meaning an API key cannot be used to hit this endpoint). The /core/me endpoint is tagged as "apimemberonly". This makes me think you are making your request using an API key and not using the OAuth access token. Take a look at this page: https://invisioncommunity.com/developers/rest-api . If using an OAuth access token, you should be setting an authorization header like so: Authorization: Bearer {$accessToken} $accessToken in this case is the access token that was returned.

You will need to allow whatever domain chatbox and Google are being served from if you are using a content security policy.

That topic is from 2012 and references code from an older code base that is no longer relevant. My recommendation is to use OAuth (as Interferon is doing) for this purpose. Our software can act as an OAuth client and an OAuth server, and supports different modes (grant types) for different purposes.

No, however we've written these in-house for managed clients so I know it's entirely possible. As a general rule, you'll be creating a hook on \IPS\Login\Handler\OAuth2\Custom::_processAccessToken(). Call the parent (which returns the member object you're working with), check the user data and adjust the member's custom field values, then return the member object you obtained from calling the parent.

You would need to use the framework methods for storing and retrieving files. $file = \IPS\File::create( "core_Theme", $filename, $fileData ); print $file->url; /** * Create File * * @param string $storageExtension Storage extension * @param string $filename Filename * @param string|null $data Data (set to null if you intend to use $filePath) * @param string|null $container Key to identify container for storage * @param boolean $isSafe This file is safe and doesn't require security checking * @param string|null $filePath Path to existing file on disk - Filesystem can move file without loading all of the contents into memory if this method is used * @param bool $obscure Controls if an md5 hash should be added to the filename * @return \IPS\File * @throws \DomainException * @throws \RuntimeException */ public static function create( $storageExtension, $filename, $data=NULL, $container=NULL, $isSafe=FALSE, $filePath=NULL, $obscure=TRUE )

Our developer documentation here is the fundamental source for learning our framework, but naturally we encourage you to browse through the source code to be familiar with it if you are working to write addons for our software. I'll raise your suggestion of training sessions/workshops internally for consideration.

Our repository is not public and we do not accept public PRs. You can, however, describe what you are suggesting to change here and we'll tackle the leg work if we're in agreement. 🙂

You will probably want to create a "Custom public OAuth client" which has the description Note the "native app which will be installed on a device an end-user does have access to" bit. From there, I agree you will want to use "Resource Owner Password Credentials" as the grant type. "Redirection URI" won't mean much in your case so you can set it to whatever you want. Here's a generic description of how it works: https://auth0.com/docs/flows/resource-owner-password-flow You'll send the details to the /oauth/token/ endpoint as a POST request with client_id: The client ID for the OAuth client username: The user's username password: The user's password scope: Space separated list of scopes to grant access to grant_type: "password" This should return the access token, which you can then use to make REST API calls authenticated as the end user.

You will need a custom plugin to accomplish this.

This isn't a commonly used feature so it's probably largely undocumented. You almost certainly don't need to create a Library class. These classes define how to translate data from a converter into the applications installed (e.g. blog, forums, downloads, etc.). Unless you are wanting to convert data from an external source into a new application within Invision Community, the library class would be unnecessary, because we already have libraries for all of our core applications. A Converter class is needed for each type of content you wish to convert, and translates to the files you see under applications/convert/sources/Software/*. You'll see there are folders for each app (which are each defined by Library classes), and then underneath each folder is a class for each type of software supported. If you want to allow conversions of blog, calendar and forum content from "Some Random Made Up Forum v2.0", then you'll want to create software classes for Core, Blog, Calendar and Forum. From there, you will need to define certain mapping methods that outline what is convertable, and you will need to create the methods that actually get called to perform the conversion. Your best option is to copy code from one of the existing software classes and modify it to suit your needs in most cases.