Development Notes

Work in progress to try to define some coding standards & rules to make things easier

• ALL Code must be commented. (PRs without code comments will not be merged till added)
• Code is Tabbed 4 Spaces (can be fixed if it's not)
• Any Javascript where possible must be stored within a separate file within assets/js/sections unless otherwise not suitable.
• New Controllers must have an associated method to match, this must contain ALL features for this item, do not add items to other models.
• SQL queries must be limited and designed to be fast as possible this keeps Cloudlog fast as possible
• Pull Request must be tested and if they aren't they will be rejected, no time frames given for merging its best efforts only.

Contribution:

• Is always welcome ;)
• Must be based on the lastest dev (e.g. git clone [your fork],git checkout dev, git pull, git checkout -b my_contribution)
• PullRequests must be created against dev (e.g. git request-pull my_contribution https://github.com/magicbug/Cloudlog.git dev - or via the github gui (recommended))

Security guidelines:

• Never trust userinput. Means: doublecheck posted Variables for scope. e.g.: Page for Logbook-Editing shows only Logbook of logged in User. If you want to edit the book you pass the id of the Log to a function within the controller. the passed ID MUST be checken (if it belongs to the User) before processing
• All controllers, which modify data and which are invoked only by Users/Admin, MUST check if the User is authorized to call the functions. This is best done at the constructor.
• All other controllers for visitors MUST check not to leak (protected) data
• All other controllers, invoked by cron, MUST not disclose any data to the User/cron which invokes the script. e.g.: LotW-Upload invoked by cron MUST not show which QSOs are uploaded
• Never assume default-values to critical functions.

Global Options

If you have a feature that requires a global configuration option that is something that is needed for logged in or logged out but isn't for just one user only then this should be placed in the Global 'options' table

The table has the following fields

• option_name - the name of the option.
• option_value - the options value
• autoload - this is either "yes" or "no" and will mean the options loaded for everyone or not, things like usernames and passwords shouldn't be autoloaded.

Version Info Dialog

The Version Info Dialog is triggered only by the database. Data is stored in two datatables

Datatable options - Contains basic configuration of the version dialog

option_name	option_value	autoload
version_dialog	release_notes, custom_text, both or disabled	yes
version_dialog_header	Contains the header, can be edited in admin menu	yes
version_dialog_text	Contains the custom text	yes

Datatable user_options - Contains the trigger, if false dialog will shown to the user. If the user click's "Don't show again" the option_value will be overwritten to true

option_type	option_name	option_key	option_value
version_dialog	confirmed	boolean	true or false

To trigger/overwrite the database for all users remotely (for an update) just use the following three lines in a migration script in the functiopn up().

// Trigger Version Info Dialog
$this->db->where('option_type', 'version_dialog');
$this->db->where('option_name', 'confirmed');
$this->db->update('user_options', array('option_value' => 'false'));

Page Design

• Page functional headings are H2

button colours

• Blue Solid = Add something, activate something, or perform any other primary action.
• Blue Outline = Edit, change or update something.
• Red = Delete something or make an irreversible change.
• Grey = Deactivate something.
• Yellow = Reset something or clear a field (no permanent delete).
• Green = Search.

Assets

Assets must be stored locally not CDNs and placed correctly within the /assets folder