The IDE allows you to make your models available to other users in order that they can work with on the development and deployment of your connected products. Such participants are called ‘collaborators’ and are those Electric Imp account holders to whom you have expressly granted access to your own account. Which models a collaborator can view and which IDE functions they can make use of will depend on the permissions associated with the ‘role’ you assign them. This role does not affect what they can do with their own account’s models, only with yours.
The system is intended to enable multiple account holders to collaborate on the development and deployment of shared models without the need to share account login credentials. You should note that if you simply need a collaborator to participate in the development and testing of one or more models, that this can also be achieved by making use of the Build API. However, the Build API does not yet provide access to the IDE’s production tools, so for production-related tasks you will need to use the collaboration system.
Clicking on the ‘Collaborators’ button in the Tab Bar at any time will place a list of your account’s current collaborators in the Workspace. Initially, you will see only yourself listed, as the account owner. The owner is the ‘super user’ and the only user able to access and alter the account’s settings, and manage the account’s Build API keys.
New collaborators can be added by clicking on the Workspace’s circled
+ icon. This presents the ‘Add Collaborator’ panel in which you enter the email address of the collaborator you wish to invite and the initial role you would like them to take. Click on the ‘Add Collaborator’ button to begin the invitation process:
As you can see from the image above, the IDE provides five roles:
An account’s owner and Administrator(s) can add as many contributors as they require. Collaborators may be granted any of the roles, including Administrator, and can be assigned multiple roles. For example, a collaborator who you wish to have access to both development and operations functionality but not to be able to manage your collaborators need not be granted the Administrator role but instead can be assigned the Developer and Operations Manager roles jointly.
Here is a summary of the key functionality each role has access to:
|Add/Manage Collaborators and Roles||Y|
|Development Tools and IDE access||Y||Y|
|Manage Production Configurations||Y||Y|
|Manage Factory Configurations||Y||Y|
|Access Shared Devices||Y||Y||Y||Y||Y|
|Manage Shared Account Settings**|
* Factory Operator’s unassigned devices can be added as a Factory Imp by the account owner, Administrator and Operations Manager.
** Account owner has all privileges that an Administrator has plus access to account settings.
Not all the roles need be assigned. If, for example, you are happy as the account’s owner to administer the account too, you might decide not to invite any collaborators to become Administrators.
For a full description of each role’s capabilities, please see ‘Collaborator Roles in Detail’.
After you have clicked in the ‘Add Collaborator’ button, the invitee will receive an email containing a link they can click to accept your invitation. You will receive an email notification if they do so. The acceptance link expires 48 hours after it was issued, and you will be notified by email if this happens.
Invitees do not need to have an Electric Imp account to accept your invitation, but they will need one to log into the IDE and access your models. If they do not have an Electric Imp account, they will be asked to sign up after accepting your invitation.
Clicking on the ‘Collaborators’ tab at any time will present you with a list of current collaborators, showing their email address and username and the role(s) they have been assigned. The ‘Actions’ column provides tools to edit their role assignments (the pencil icon) and to revoke their access to your account (the trashcan icon):.
Editing a collaborator’s settings allows you to change their assigned roles: just click on appropriate checkboxes. There is one restriction: Administrators can’t change the role(s) of other Administrators — only the account owner can perform this action.
Click on ‘Collaborators’ in the Workspace’s title to return to the list of users with access to your account.
On a collaborator’s settings page, click on the trashcan icon to revoke the collaborator’s access to your account. There are some limitations to this action:
Click on ‘Collaborators’ in the Workspace’s title to return to the list of users with account access.
As a user who has been invited to access at least one account other than your own, you will see a menu of accounts at the left end of the Menu Bar. This menu is not shown if you only have access to your personal account. Initially, the menu will titled with your own username; clicking on it pops up a list of all the accounts you have access to. The accounts are listed by the account owner’s username in alphabetical order; your account is always placed at the bottom of the list for consistent access. The currently selected account is highlighted green. Click on any account name to select it:
When you select an account, the list presented by the ‘Models’ in the Tab Bar will update to present the selected account’s models. Depending on the role you have been assigned, you may see all or a subset of the selected account’s models. For example, if you have been assigned the role of Operations Manager, you will not see any of the shared account’s Development Models or Inactive Models — you will only see Production Models listed.
You will also not see the model’s ‘Code’ Workspace tab, only the ‘Factory’ and ‘Report’ Workspace tabs. This is because the Operations Manager’s activities center on running the production process, not on software development. Holders of the Developer role conversely can not access Production models, only Development Models, Factory Firmware and Inactive Models.
If a Developer needs access to operations tools, you can assign them the Operations Manager role in addition to their Developer role.
When a collaborator has selected a shared account and then selected one of that account’s models, it will appear in the IDE’s Workspace ready for editing. Multiple users can access the same models simultaneously. The IDE provides a limited notification mechanism to help collaborators ensure that changes they make to a model are not overwritten by other collaborators.
When a fellow collaborator creates a new build in a model that you are currently editing, you will receive a notification indicating who has created the new build and the new build number. In these circumstances, you should communicate with your fellow collaborator and discuss how to proceed to ensure your changes are in harmony. You may click on ‘Build’ to save a further new version of the code, or you might simply reselect the model via ‘Models’ in the Tab Bar to view the updated code, assuming you have made any changes:
At any time you can click on the ‘Build’ dropdown in order to view any build number, including the one that triggered the notification. You will also be able to see when the revision was build and by whom:
When you make any changes to the code, the ‘Build’ dropdown will be renamed ‘Draft’ to indicate that you are working on an unsaved version of the code. Clicking on ‘Draft’ will present the usual list of builds, this time headed by your unsaved draft version. If you select an earlier code revision, you will not overwrite your draft unless you hit the ‘Copy to New Build’ option.
Whenever you hit the ‘Build’ or ‘Build and Run’ button to create a new version of the code you have been working on, the IDE will inform you if a new build has been created since you began working on your code draft. It will also ask you to confirm if you are sure you wish to proceed. If you decide to continue and create a new build, your code will be saved as the latest build (and other collaborators accessing the model at the same time as you will receive the notification described above). Your new build will not contain any changes any previous build has, nor will it overwrite other collaborator’s code.
For example, Developer A opens a shared model, makes some changes and then clicks ‘Build’ to save them. There are no recent builds, so A receives no notifications. He then begins to make further changes. However, at this point Developer B accesses the shared model and begins to make changes of her own. A’s and B’s views are now out of sync. Should either A or B click on ‘Build’ or ‘Build and Run’, the other will be notified immediately.
When you associate a development device to your own account using the Electric Imp app (Public impCloud) or your own development BlinkUp app (Private impCloud), it appears in the list of your unassigned devices, accessed from the devices menu in the Top Bar (the chip icon).
If you are a collaborator on a shared account, selecting that account and then clicking the devices menu lets you see the shared account’s unassigned devices.
To assign one of your own development devices to a shared model, the device must initially be unassigned. You assign such a device to a shared model in the usual way: click on its settings icon from the ‘Actions’ column and, in the ‘Device Settings’ panel that now appears, you select the shared model you wish the device to run. The device will now be assigned to that model and appear in the model’s device list at the bottom of the Workspace when you view that model’s code. Select the device and you will see its logs in the usual way.
Although the device is now running a shared model, the account with which it was originally associated retains ownership. The device owner’s account can’t have its access to the shared account revoked until the device has been deleted or reassigned by its owner to a personal model or a model from a different shared account.
Under the multi-user system, factory BlinkUp fixtures and their on-board factory imp modules are handled in the same way they have always been: the factory manager adds the fixture to their Electric Imp account by using BlinkUp and the Electric Imp mobile app (or a custom development BlinkUp app if you are are Private impCloud customer). This sets up the fixture to connect to the Internet via the factory’s WiFi network.
Typically, the owner of the customer account (or one of the account’s Administrator collaborators) will invite the factory manager to become an account collaborator, and will assign to them the specific role of Factory Operator. This role ensures that any factory BlinkUp fixtures that the factory manager adds to their Electric Imp account may then be assigned by an account owner, Administrator or Operations Manager as the production model’s factory imp. This is done by entering the fixture’s MAC address into the production model’s IDE ‘Factory’ tab. The fixture will be listed in these collaborators’ ‘Unassigned Devices’ lists.
This assignment ensures that the factory BlinkUp fixture will always run the production model’s factory firmware to correctly prepare production devices on the assembly line for the Electric Imp factory process.
Once the production run is complete, the factory manager may wish to use the factory BlinkUp fixture for other products — the account owner, an Administrator or an Operations Manager should now remove the fixture’s MAC address from the production model’s list of factory imps. The factory BlinkUp fixture is now once again available to the factory manager for re-use: it is now included in their ‘Unassigned Devices’ list. The factory manager can be removed as a collaborator to the customer account, if required.
If the account owner does not wish to allow the factory manager to become an account collaborator, the manager must provide the account owner (or an Administrator or Operations Manager collaborator) with the fixture’s MAC address. This address can then be entered by the account owner (or suitable collaborator) into the production model’s settings under the IDE’s ‘Factory’ tab. Alternatively, the owner, Administrator or Operations Manager can configure the fixture themselves (using WiFi credentials supplied by the factory manager) and send the configured device to the factory for installation on the assembly line.
The following table shows which devices a shared account collaborator can mark as a factory imp:
|Own Device||Collaborator-Owned Device|
|Role on Shared Account||Unassigned||Assigned to Own Model||Assigned to Shared Account Model||Unassigned||Assigned to Collaborator’s Own Model||Assigned to Shared Account Model|