EXT – The add-on should support the Lime CRM web client.
EXT – All calls to Lime CRM should include the HTTP header parameter User-Agent and set it to something unique for this add-on, for example the name of the external party responsible for it. Lime Technologies should be informed about which name was chosen.
EXT – If the add-on contains a LIP package:
The structure of the LIP package should follow what the LIP package builder creates. Basically that follows these rules:
A lip.json file. Should include all localization records and database structure for new fields.
actionpads: contains any Actionpad html files for any new tables created by the add-on.
actionpads\resources: contains any Actionpad header icon images needed.
apps: contains one subfolder per Lime Bootstrap app that is part of the add-on. The app folders must never contain any files that are only for installation, since these will make the Actionpad folder unnecessary large in a Lime solution.
lisa\icons: Contains any icons needed for new tables added by the add-on.
lisa\optionqueries: One file per option query with a filename on the form: <table name>.<field name>.txt.
lisa\descriptives: One file per new table containing the descriptive expression. Should be named: <table name>.txt.
lisa\sql_expressions: One file per field having an sql expression.
lisa\sql_for_new: One file per field having sql for new.
lisa\sql_on_update: One file per field having sql on update.
vba: Contains all complete VBA modules, forms, class modules necessary as well as separate .txt files with any code that must be inserted in existing VBA modules when installing.
The content of the LIP package should be added to a zip file and published somewhere where Lime Technologies employees can access it.
EXT – Versioning:
The version number of the add-on should follow semantic versioning, i.e., it should be a string on the format x.y.z. Breaking changes increase x, added features increase y and bug fixes or minor improvements increase z. Start on 0.1.0. When the first stable version is released, mark that as 1.0.0.
All changes in every version should be specified shortly as a bullet list in a file called CHANGELOG.md in the docs folder. It should be part of the documentation page. Should be written for non-developer eyes. The CHANGELOG.md file should also contain Release date for every version.
EXT – Code written and structured according to current best practices, including but not limited to the examples listed here.
EXT – All UI texts are translated to all languages important for the relevant markets for the add-on. Use .po files for localizations. Only in very specific edge cases are localize records OK to use. Relevant languages are any of the following: English, Swedish, Norwegian, Danish, Finnish, Dutch, German and French.
EXT – The following naming conventions are followed:
The python package is named limepkg-<your system name>.
If the add-on contains VBA code: Any VBA modules, class modules or forms should be named AO_*<name of add-on>*. If the name of the add-on is too long to fit, then use a unique abbreviation.
If the add-on contains localize records: The field owner on the localize records should be on the form addon_<name of add-on>. Only use lowercase letters in the fields owner and code.
If the add-on contains a Lime Bootstrap App: The name of the app folder should only contain lowercase letters and be on the format addon_<name of add-on>.