Most environmental variables are settings, so we should only expose ones which are not:

• initial user
• root url
• instance ip

Thanks @geekgonecrazy for the suggestions

@graywolf336 commented on Mon Apr 09 2018

• Ability to predefine colors to pick from (could be a select but better?)
• Ability to use the system colors (needs to be defined/provided by Rocket.Chat)

Whenever an App is updated, none of the connected web clients get that App's updated i18n strings. However, a refresh of the page pulls the latest i18n strings.

Ref: RocketChat/Rocket.Chat.Apps-ts-definition#45

See: https://github.com/RocketChat/Rocket.Chat.Apps-ts-definition/issues/41

If an App was previously installed and enabled, whenever you update it and return false on the method onEnable then the commands and handlers correctly don't get registered but the status of the App isn't correctly updated to be disabled. Returning false on the method onEnable should disable the App.

Hi,

we are trying create an app that creates a room name dynamically via the usernames, but within the executePreRoomCreateModify we are not able to figure out the usernames.

We also first tried to use the usernames property but stumpled upon this issue #58

Is there a different way with an implemented method? Or any other idea on how to fix this?
:)

It also would help if we just had access to the IDs of the users within the room...

thanks in advance

Idea

A Rocketlet can register a url it would like to add additional information to the request of the oEmbed information request.

Example

Rocketlet which allows for a GitHub authentication information to be attached to oEmbed requests out to GitHub, this way links to private repositories can have their information shown instead of showing nothing.

See: https://github.com/RocketChat/Rocket.Chat.Apps-ts-definition/issues/40

The question is, will the Application have access directly to mongoose.

It would be nice, but a little dangerous anyway. On the other hand, Rest API or Realtime API access would be nice, but weird since application works locally inside RocketChat.

Currently our internally compiler doesn't complain/error out whenever an Application contains invalid code and references. For example, we moved over to each handler being a promise so the return type is Promise<T> but if an old App is uploaded that only returns T it should fail but it doesn't.

https://github.com/RocketChat/Rocket.Chat.Apps-engine/blob/master/src/server/accessors/Modify.ts#L40

Currently Rocketlets which error out during compile time, for any numerous reasons, are ignored and not added anywhere that they can successfully be removed or updated and doing so with their id will actually error out. So, special provisions need to be made for Rocketlets which error out during compile time and enable time.

Right now it's not possible to prevent a message to group with previous messages

Ref: cardoso/Rocket.Chat.Dropbox.Paper#3

@marceloschmidt commented on Sun Jul 29 2018

Add setting types such as roomPick, userPick, multiline text, roles picker.

Currently there are only two ways to query/request data from the persistent storage. First is via the id of the stored object and the second is if the data was associated with other objects. However, there is a need for some query support that is database agnostic (since Rocket.Chat will be moving away from Meteor in the next year or two and that opens the door for different backing database support). The idea here is to create either a query builder and/or provide classes/interfaces which will allow the database query to be built for the current database type being used.

An Application needs the ability to schedule a task that runs at a configurable interval or at a specific time. This can be useful for several instances, such as a /remind command or a daily stand up question.

A task should only run on one server when there are several instances of Rocket.Chat running. To do this I am thinking of the following terminology (with more details coming later, as this is a rough brain dump issue post):

• Workers
• Worker IDs
• Worker Grabbers
• Manager
• Queue
• Time to Live

Some projects to look into that handle these things currently (reminder: the Apps are an abstraction layer from the database and backing system, thus all of these details are required even if the backing system already has it). meteor-syncd-cron and SteveJobs

As an app developer, I'd like to add an app which provides a dashboard of current activities in Rocket.Chat.
As this is a "global" (room independent) feature, I want to place it into the directory / discovery.

Is there an API for that?

@rodrigok commented on Fri Jun 01 2018

1. We are about to remove the usernames property if we merge this PR

Code affected
https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-apps/server/bridges/rooms.js#L27
https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-apps/server/converters/rooms.js#L40
https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-apps/server/converters/rooms.js#L67

2. The code called to create rooms is, probably, not working since the params are different

Auto prune logs for Apps after an extended amount of time.

@graywolf336 commented on Tue May 15 2018

Currently Apps can not bring in third party packages in a supported manner (yes there are ways around it), however this is a big need and if we don't allow this then Apps will be severely limited. However, just allowing Apps to include any and every npm package will open the door to security issues and even malware packages.

So, we need a way to provide "secure" way for Apps to define the npm packages they use. This will be a multi-step process. First up, we will add a npmDepends configuration section of the App.json configuration file. Then whenever someone submits an App to the Marketplace we will look through that section and ensure they seem to be trusted modules. After it has been marked as reviewed and "trusted", an automated system will package in the npm modules (we will need to look into the license restrictions here) into the App.

However, there will be Apps that want to not distribute themselves via the Marketplace for various reasons (let's say an in-house App). Due to this, we will provide a way for Apps to package the npm modules themselves but a big, not so nice, warning will be displayed when installing and enabling the App that warns of potential risks associated with that App.

I would like the thoughts of any and everyone on this manner. Does this make sense and is it logical to do this? Yes, the Apps Marketplace will already have a manual review process so adding one more task to it just makes sense.

@timkinnane commented on Wed May 16 2018

Hey Bradley, on a technical note, is npmDepends a common approach or specific to Meteor? My understanding is that the apps will not be Meteor packages, so why not just use standard package.json manifest? Seems like reinventing the wheel otherwise?

Generally, I would err on the side of less restriction rather than the tight controls you're suggesting. Every node package is just the tip of its own tree of dependencies, there's no feasible way to enforce security standards for all the code in use, so it seems arbitrary and unnecessarily restrictive to enforce oversight at that level. Not to mention an intensive task for manual reviewers.

I'd suggest just listing the included dependencies on the app's marketplace profile, perhaps with some stats for each package, e.g: number of downloads, number of dependents, up to date dependencies (david-dm.org badge). There's services available to link to or integrate, for auditing an NPM package too, e.g. packagequality.
Just found this article sharing some similar approaches: https://bytearcher.com/articles/evaluating-packages-1-check-community/

I think, in the interest of keeping the system open for app creators, it's reasonable to assume some responsibility lies with the people installing the app to make their own determination on it's quality. If you make the controls too restrictive, the approval process will become a bottleneck and add to the cognitive load of how to navigate this ecosystem and get something out there, which is already high coming in.

@JSzaszvari commented on Thu May 17 2018

@timkinnane Agreed ++

@graywolf336 commented on Fri May 18 2018

Thanks for the input guys 👍 we will keep this in mind when actually starting to work on this. :)

@graywolf336 commented on Wed May 30 2018

To do: Evaluate how vscode's extension manifest (as the App.json was influenced by it) https://code.visualstudio.com/docs/extensionAPI/extension-manifest

See https://github.com/RocketChat/Rocket.Chat.Apps-ts-definition/issues/37

It would be useful to have some capability for running code in the client-side with local storage and external request options.

The first use case that comes to mind is custom E2E encryption solutions, but also other things would be possible like local translation.

I think we can begin by implementing some hooks like:

function preMessageSend(Message, IRead, IModify, IPersistence) {
    // client will run this code when sending a message and possibly transform it
    return Message // return false to prevent message from being sent
}

function onMessageReceive(Message, IRead, IModify, IPersistence) {
    // client will run this code when message is received and possibly transform it
    return Message // return false to filter out the message?
}

This should not be hard to implement on iOS or Android, since both have powerful native JavaScript interop.

@graywolf336 commented on Tue Apr 03 2018

Right now there is a discussion which needs to happen about how various UI pieces will be implemented and structured. For example, the contextual bar is now ready inside of Rocket.Chat however we need to decide how we are going to have them activated inside of Rocket.Chat.

• Are we going to use a framework?
  • Polymer
  • React
  • Shadow dom
  • iframe
  • or..?
• How focused on security are we going to be?
• Do we limit the scope of the App's JavaScript for the element?
• How will icons be generated? See: RocketChat/Rocket.Chat.Apps-ts-definition#19

These are all questions which come to my mind at this current point in time, however there are more that I need to dig up. Feel free to append other questions.

@mrsimpson commented on Tue Apr 03 2018

I'm definitely not the one to make a decision on that. Still, as you pointed me to it:

I don't know all the frameworks nor their pros and cons. However, I feel that going for React is a good choice: React native, native ES6, components which can be defined by an interface, high traction on the dev commmunity, similar paradigms compared to Blaze...

I'd expect a React component I can derive from for each location (the sidebar, primarily, maybe also a message-oriented view as implemented here) the component shall appear in (maybe a stateless in the beginning, a stateful later on).

Imho, React is a safe bet (maybe except licensing, I'm not an expert on that) and it's more important to start soon than finding a 1% better match.

Just my 5 cents

@mrsimpson commented on Tue Apr 03 2018

ad how to limit the scope: I'd go for constructor injection on the component. Of course, somebody requiring an unwanted lib can hardly be prevented - unless you prevent and loading of libs in general. So one opportunity was to only bind dependencies via npm. Those, you can at least parse and patch more easily

@mrsimpson commented on Tue Apr 03 2018

ad icons: I'd expect each Rocketlet to provide some assets from which the icons can be loaded (CSS should come via an API). A set of icons which are already loaded for all of them was convenient for a start though.

The first version could be only setting up custom OAuth providers, being able to set all its fields should be enough (see screenshot bellow).

But the ideal implementation for me should be being able to register loginHandlers like this

To get around #70, I am now disabling and enabling the slash command based upon a setting instead of just disabling the entire App. However, when the App disables the Slash Command it doesn't get disabled in the clients web browsers or anything. Watching the websocket and no messages/frames come through which tell it to disable commands, so something is missing server side.

@graywolf336 commented on Wed Apr 11 2018

Add documentation which states that storing items in memory inside of the App is not recommended at all because a Rocket.Chat server can have several instances and each server has its own instance of an app. If the data, such as confirmation for context, needs to be shared between the different instances then the persistence accessor needs to be used.

Right now an App is enabled without any thought for the settings it provides and their required property. If an App contains settings which are required and the user has not provided them, or the packageValue isn't provided by the App, then don't enable the App and don't allow the user to enable the App.

@theorenck commented on Thu Jun 07 2018

Based on a discussion with @thiagosanchz about what information we need to have in the app description page, we would like to suggest some improvements:

• description: this one could be a long description limited to just one or two paragraphs long
• summary: just a brief description, possibly just one line, just about one or two phases long
• website: If the author want to better "sell" his app idea, he should do this in a page of his own
• categories: on the Marketplace designs we have the concept of categories, shouldn't them be inside the descriptor file?

Thoughts?

@graywolf336 commented on Fri Jun 08 2018

See the discussion on #49. We will be moving to package.json and taking a page out of VSCode Extension manifest file book on how to approach this. However, due to moving away from app.json file as the manifest file, we will have to change the properties and thus this will change the internals of the framework system which is not a small change.

As this project gets worked on more and more, sometimes being able to step through and debug the code would be beyond useful. However, due to the project setup the configuration of the debugger isn't exactly the easiest.

There are technically two typescript projects in this repository. The first one is the actual engine code, located under the src folder which compiles down to the dist folder. Then the second one is the testing server piece which is used to try out various pieces of the engine while development happens (such as loading, installing, and updating apps). The development server piece is located under dev folder and compiles down to dev-dist. Then gulp will launch the generated dev-dist/server.js file.

What all settings inside of Rocket.Chat should be exposed?

• Message size limit

Suggestions would be fantastic.

• List files
• Create/Upload files
• Remove files
• etc

@graywolf336 commented on Thu Apr 12 2018

Create, read, and update the user's preferences.

Unable to run RocketChat under Windows due exception:

...
 Exception in callback of async function: Error: Could not find the Apps TypeScript Definition Package Version!
...

because of AppPackageParser.ts@151

...
        const prodLocation = __dirname.split('@rocket.chat/apps-engine')[0] + '@rocket.chat/apps-ts-definition/package.json';
...

Splitting path by substring contains / - bad idea.

@graywolf336 commented on Fri May 04 2018

Allow Apps to provide message attachments/uploads.

Ability to create, get, and check permissions.

This would be amazing for commands that only need to be given to certain people.

The only ways I found to send messages with Apps were:

Via User or Bot User. Con: They need to be added to groups & don't work on DMs
Via notifyRoom() or notifyUser(). Con: Messages are not persistent & say 'only you can see this message' even if you used notifyRoom()

I think we need an APP user type that can send messages in channels, groups & dms without having to be explicitly invited.

Ref: cardoso/Rocket.Chat.Dropbox.Paper#1

See: https://github.com/RocketChat/Rocket.Chat.Apps-ts-definition/issues/38

@graywolf336 commented on Mon Apr 30 2018

• Reactions
• Stars
• Etc

The right hand side panel is the place in Rocket.Chat where additional information for the context of the current conversation are being displayed (e. g. who are the current members, what are the pinned messages and so on).
Informative Apps should be able to claim space in there.

For a better illustration, here's an "app" which we provide in our custom fork:

The app detects via NLP what the conversation is currently about and performs implicit search.
As of today, we implemented this widget independent of Rocket.Chat: It's a jQuery based UI which simply attaches to a DOM node provided as a tab and then interacts via DDP with Rocket.Chat.

Personally, I believe that this would be an option for most desktop apps. Would providing an (empty) tab be a first step in the apps as well?

One of the major USPs of Rocket.Chat compared to others is it's availability on premise with enterprise features for companies. I'd not install a single Rocketlet if I was unsure what it can do.

In my app I'm using ${context.getSender().username} to get the "lfirst", which works on desktop and Android. When you look at the same message on an iOS device, it does "Full Name" instead of "lfirst"

Extending ISlashCommand
const text = https://company.com/test/${context.getSender().username};

Android & Desktop Return: https://company.com/test/lfirst
iOS Returns: https://company.com/test/First Last

Allow endpoints for Rocket.Chat Apps which will be fully functioning webhooks which support get, post, put, delete, etc.

TypeScript Definition: https://github.com/RocketChat/Rocket.Chat.Apps-ts-definition/tree/master/src/webhooks

I have written a small app which replaces chat messages which contain specific strings with links to our issue tracker. When you install the app, it has a URL which you need to provide. Once you have updated the url in the onSettingUpdated will send a request to the issue tracker's rest api and fetch all of the active projects so that when you write ABC-123 it would replace it with a link to the issue.

The issue I'm facing is that when RocketChat restarts, the projects are not preserved. I decided to create another configuration setting in the extendConfiguration which is hidden and store the data there, but I'm receiving the following exception:

  "{\"stack\":\"Error: Method not implemented.
    at Promise.asyncApply (/app/bundle/programs/server/packages/rocketchat_apps.js:1245:13)
    at /app/bundle/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40
\",\"message\":\"Method not implemented.\"}"

Am I doing it wrong or is this really not implemented? Is there any actual documentation of how all this should be working - I don't seem to be finding it on the website?

Here's my code:

import {IConfigurationExtend,IConfigurationModify,IEnvironmentRead,IHttp,IHttpResponse,ILogger,IMessageBuilder,IPersistence,IRead} from '@rocket.chat/apps-engine/definition/accessors';
import {App} from '@rocket.chat/apps-engine/definition/App';
import {IMessage, IPreMessageSentModify} from '@rocket.chat/apps-engine/definition/messages';
import {IAppInfo} from '@rocket.chat/apps-engine/definition/metadata';
import {ISetting, SettingType} from "@rocket.chat/apps-engine/definition/settings";

export class YouTrackApp extends App implements IPreMessageSentModify {

    readonly SETTING_YOUTRACK_URL = 'Youtrack_URL';
    readonly SETTING_YOUTRACK_PROJECTS = 'Youtrack_PROJCETS';

    private projects = [];

    protected constructor(info: IAppInfo, logger: ILogger) {
        super(info, logger);
    }

    public async checkPreMessageSentModify(message: IMessage, read: IRead, http: IHttp): Promise<boolean> {
        const url = (await read.getEnvironmentReader().getSettings().getValueById(this.SETTING_YOUTRACK_URL));

        if (url !== null && url !== '' && this.projects.length > 0 && message.text) {
            const match = message.text.match(this.getRegex());
            return match !== null && match.length > 0;
        }

        return false;
    }

    public async executePreMessageSentModify(message: IMessage, builder: IMessageBuilder, read: IRead, http: IHttp, persistence: IPersistence): Promise<IMessage> {
        const url = (await read.getEnvironmentReader().getSettings().getValueById(this.SETTING_YOUTRACK_URL));

        if (!url || this.projects.length < 1) {
            return message;
        }

        if (message.text) {
            const regex = this.getRegex();
            const match = Array.from(new Set(message.text.match(regex)));

            if (match && match.length > 0) {

                let text = message.text;

                for (let i = 0; i < match.length; i++) {
                    const issue = match[i];
                    let title = await this.getIssueSummary(issue, url, http);

                    // This could happen on error or if the issue is private.
                    if (title === false) {
                        title = '';
                    }

                    this.getLogger().debug(title);
                    this.getLogger().debug(message.text);

                    // @ts-ignore
                    text = text.replace(new RegExp(issue, 'gi'), '[' + issue.toUpperCase() + ' ' + title + '](' + url + '/issue/' + issue + ')');
                }

                return builder.setText(text).getMessage();
            }
        }

        return message;
    }

    public async onSettingUpdated(setting: ISetting, configurationModify: IConfigurationModify, read: IRead, http: IHttp): Promise<void> {
        if (setting.id === this.SETTING_YOUTRACK_URL) {
            // Ignore this error - setting is actually an array of settings.
            const url = setting.value;

            this.getLogger().debug(setting);
            this.getLogger().debug(setting.value);

            read.getPersistenceReader().read('test');

            if (url !== null && url !== '') {
                const fetchProjects = await this.getProjects(url, http);

                if (fetchProjects) {
                    this.projects = fetchProjects;
                } else {
                    this.projects = [];
                }
            } else {
                this.projects = [];
            }

            await configurationModify.serverSettings.modifySetting({
                id: this.SETTING_YOUTRACK_PROJECTS,
                type: SettingType.STRING,
                value: JSON.stringify(this.projects),
                packageValue: null,
                required: false,
                public: false,
                hidden: true,
                i18nLabel: ''
            });

            this.getLogger().debug("Projects:");
            this.getLogger().debug(this.projects);
            this.getLogger().debug("Regex matcher:");
            this.getLogger().debug(this.getRegex().toString());
        }
    }

    private getRegex() {
        const expr = '(' + this.projects.join('|') + ')-([0-9]+)';
        return new RegExp(expr, 'gi');
    }

    private async getIssueSummary(issue, url, http: IHttp) {
        const restUrl = url + '/rest/issue/' + issue;

        const response = await http
            .get(restUrl, {headers: {"accept": "application/json"}})
            .then((response: IHttpResponse) => {
                try {
                    if (response.content) {
                        const summary = JSON.parse(response.content).field.filter(v => v.name === 'summary').map(v => v.value);
                        this.getLogger().debug("Youtrack issue (" + issue + ") summary retrieved: ", summary);
                        return summary;
                    } else {
                        this.getLogger().error("Response content cannot be parsed!");
                        this.getLogger().error(response.content);

                        return false;
                    }
                } catch (e) {
                    this.getLogger().error("Failed to parse response from " + restUrl);
                    this.getLogger().error(e);

                    return false;
                }
            }, (reason: any) => {
                this.getLogger().error("Failed to request " + restUrl);
                this.getLogger().error(reason);

                return false;
            });

        if (response !== false) {
            return response;
        } else {
            this.getLogger().error('Could not fetch youtrack issue summary!');
            return false;
        }
    }

    private async getProjects(url, http: IHttp) {
        const projectsUrl = url + '/rest/project/all';

        const response = await http
            .get(projectsUrl, {headers: {"accept": "application/json"}})
            .then((response: IHttpResponse) => {
                try {
                    if (response.content) {
                        this.getLogger().debug("Youtrack projects: ");
                        this.getLogger().debug(this.projects);

                        return JSON.parse(response.content).map(v => v.shortName);
                    } else {
                        this.getLogger().error("Response content cannot be parsed!");
                        this.getLogger().error(response.content);

                        return false;
                    }
                } catch (e) {
                    this.getLogger().error("Failed to parse response from " + projectsUrl);
                    this.getLogger().error(e);

                    return false;
                }
            }, (reason: any) => {
                this.getLogger().error("Failed to request " + projectsUrl);
                this.getLogger().error(reason);

                return false;
            });

        if (response !== false) {
            return response;
        } else {
            this.getLogger().error('Could not fetch youtrack projects!');
            return false;
        }
    }

    protected async extendConfiguration(configuration: IConfigurationExtend, environmentRead: IEnvironmentRead): Promise<void> {
        await configuration.settings.provideSetting({
            id: this.SETTING_YOUTRACK_URL,
            type: SettingType.STRING,
            packageValue: null,
            required: true,
            public: false,
            i18nLabel: this.SETTING_YOUTRACK_URL,
            i18nDescription: 'Youtrack_URL_Description',
        });

        await configuration.settings.provideSetting({
            id: this.SETTING_YOUTRACK_PROJECTS,
            type: SettingType.STRING,
            packageValue: null,
            required: false,
            public: false,
            hidden: true,
            i18nLabel: ''
        });

        try{
            this.projects = JSON.parse(await environmentRead.getServerSettings().getValueById(this.SETTING_YOUTRACK_PROJECTS))
        } catch (e) {
            this.projects = [];
        }
    }
}

@graywolf336 commented on Thu Jan 11 2018

Allow the Rocket.Chat Apps to register a user, aka a bot, that will then populate the auto-completes when you go to tag a user. This will allow applications to "impersonate" a user and "converse" with them.

@mrsimpson commented on Thu Jan 11 2018

I believe that this property (reading messages and impersonating a response) could turn RocketChat into a bot platform and give a spin at the Rocket.Chat Apps even with the limited (text-only) scope. Feature-wise, it’s not much more compared to a slash-command (a textual interface), but it would allow bot developers to even capture a conversational state inside or outside of Rocket.Chat

@timkinnane commented on Thu Jan 11 2018

@mrsimpson Most of what you're talking about is how the platform already works to support Hubot for instance. Via the hubot-rocketchat adapter, which uses Asteroid to log in and set up channel subscriptions and send/receive.

@graywolf336 +1 on this. But I'll also flag that it ties into something I'd like to do for general bot support and testing. I think the creation process could be streamlined for bots, such as core issue 3818 and other mods to register bots programatically more simply than users.

For both bot and app testing, I'm thinking about a feature that would support creation of temporary users in private channels. So that neither the channel or users are visible to the community and they can be easily wiped away. I know this is overloading this particular ticket, just giving some context before anyone jumps to a solution.

@mrsimpson commented on Wed Jan 17 2018

@graywolf336 funny enough, guggy itself has pictured it like that
http://s3.amazonaws.com/guggyresources/guggyexample.gif

Right now a user can bypass an IPreMessageSentPrevent by sending a message then editing it

So we would need something like IPreMessageUpdatedPrevent etc

Such as disabling reading/listening to private messages, etc.

Example taken from the modern permission management in Android.

The age old question is being asked already, how can we improve the performance of the entire Apps framework? Sure the work being done on making everything "async" and using "promises" is great, however Rocket.Chat is more or less single threaded and also one instance of Rocket.Chat shares one message queue with everything happening. Thus when a Rocket.Chat App runs, and since we are promising everything it is now harder to enforce a timeout on execution of an App, what can we do to improve the performance and ensure one single App doesn't negatively effect, on purpose or accident, the performance of a server.

I hereby propose that we look into using this package: https://www.npmjs.com/package/threads

Some R&D is required before we go and "blindly" start using it...who knows, maybe we can use this in other areas of Rocket.Chat...integrations anyone? 🤔

Messages: https://github.com/RocketChat/Rocket.Chat.Apps-ts-definition/tree/master/src/messages

Rooms: https://github.com/RocketChat/Rocket.Chat.Apps-ts-definition/tree/master/src/rooms