As the title says, better consistency with names of permissions. Some are add while others are create. See app/classes/Dandelion/Permissions.php .

The fields in the the search query are case sensitive. They should be strtolower() before processing.

Implement support for the PostgresSQL database. Most of the structure is already in place. The following would be needed:

• Add option to <select> box on install page
• Add driver statement in the DB class
• Evaluate current SQL statements to see if they can be compatible with all three (MySQL, SQLite, Postgres) or if additional SQL statements will be required

Firefox 44.0.1 shows the "changing ceesto" popup a little too narrow so it wraps part of it to be below the part where you select how long you will be gone.

Version Affected: 6.0.3

It appears that if a user edits a log the 'is_edited' field in the database isn't being updated. It appears to be happening for all users, admin and non-admin alike.

In the new interface, a reset password page for a user's first login wasn't created. It needs to be created...

PHP 5.4 is end of life leaving 5.5 and 5.6 as the current supported versions. Thus it is proposed to drop active support for PHP 5.4. There aren't too many new features in 5.5 that would probably be utilized, and for a while Dandelion may still work just fine in 5.4. But, in order to ensure a secure installation, 5.4 should be dropped from the active supported versions list.

This would affect Dandelion 6.1.0+.

When editing a category for a log, if the category was beyond the first level it jumps to the initial state of one level with 'Select:' selected. The cause is the categoryManage JS file doesn't know where it is in the categories so when it asks the server for the next level, it thinks it's at the beginning with 0:0. The script needs to scan the fields to determine its current state.

Right now there are several places authorizing and validating for the exact same actions. These should be centralized to reduce redundancy and possibility of error or security leaks.

The whole project is now in the Dandelion namespace, the database class is the only one in a sub namespace. It would make sense to have the other classes/functionality in their own namespace. Making sure to add 'use' statements in the scripts that need them.

Changing the select boxes' value doesn't update the other select boxes.

The update URL should be http://blog.onesimussystems.com/dandelion/versioncheck.json.

Issue appears only in Firefox.

If editing a log and all that's done is a right-click correction of a misspelled word with no other interaction in the textbox, the text will not be saved. I think this is caused by Firefox's handling of the jHtmlArea syncing between the underlying textarea and the formatted frame. This is most likely a non-issue in version 6.1 but it should be checked before release.

When possible, the theme should be saved as a cookie that can be referenced when generating the CSS links. This way the login page can be themed appropriately even when not logged in. The cookie can be updated when the user logs in as well as when they change their theme preference. As usual, if the theme doesn't exist or is otherwise inaccessible, fall back to the global default theme.

Have a web address (eg onesimussystems.com/dandelion/versioncheck) that will return the latest version of Dandelion which can be compared to the running instance and notify an admin if a new version is available. Maybe create a system that will update itself without having to manually copy and move files.

With the current system, the only time the status code can be changed is within the api module itself. Any classes it calls usually return a string message indicating success or failure, but these are human readable and not good for error handling in the backend or api caller. I propose creating an exception class that could be thrown by any called classes. This would first be handled by the module then rethrown to be handled by the api controller. The module would add it's name to the exception. The message and code would be be added by the initial exception throw.

Coworker's suggestion: It would be nice to have a history of Cheesto status changes.

The old software we used that was eventually replaced by the Cheesto system in Dandelion kept a history of status changes. This could be used to keep track of time sick, vacation, etc.

It will be considered but may be outside the scope of the Dandelion core. Perhaps when the plugin system is implemented, an official plugin could be created that would manage that.

Implementation:

Database: new table of cheesto_history. The fields would be id, uid (user ID), state (PHP serialized array of status, message, time, etc.), date (date the history record was created).

Configuration file: new setting of 'cheestoHistoryKeep' which will be the number of days to keep a history.

Code: A garbage collector would be implemented to run that would clean up the history table from time to time to enforce the keep length. Any UI would only show the set number of days regardless of if there are older records in the history table.

UI: new template page would be created that would show the history for the logged in user. History is not editable, or deletable. The only time it will disappear is if it's older than the set days to keep.

API: new API endpoint to retrieve history in JSON format. The API would take a start index and a limit of records to return.

There are several permissions that fall under the "admin" flag. These need to itemized and implemented as separate permissions. These new permissions need to be implemented where appropriate. This will completely remove the admin flag.

Considerations: This will require a change to the group structure as stored in the database. A conversion function will be needed to upgrade the old format to the new.

Create a plugin system that would allow third-party extensions to interface with Dandelion. This would require several things. The first being a hook system. Proposed main application hooks: before run, after run, before route, after route, before api dispatch, after api dispatch. Each API module, and controllers can also have their own hooks if desired. This can be a gradual roll out. The data given to the hook's callbacks would differ depending on which hook is being called. A base plugin class could be created that would provide basic necessities such as database access and configuration access. This would allow plugins to have their own custom configurations as part of the Dandelion main config file. Each hook can have multiple callbacks and will called in the order they were registered. The main configuration would have a new property called plugins which would be an array of plugin names. They would be loaded in the order of this array. The called file would be something like [dir-to-plugins]/{plugin-slug}/main.php. This main.php file would be responsible for registering its hooks and including any files necessary for it to run. A new exception class can be created specifically to be thrown by plugins and handled gracefully by Dandelion.

Switching to Typescript was an unnecessary change to the project. It did help me refactor the category selects module, but beyond that it's proven to be unnecessary. Beyond that, it would be better to use pure JS (newer features provided via Babel) rather than some compile-to-js language like TS. Since Dandelion doesn't use TS too heavily the transition shouldn't be too bad. The categories module will need to be refactored again but I don't think it'll be difficult. Although not using Babel may be a good idea due to not needing the extra requirement, I feel it would be better to utilize the newest JS features as they come out and as the project dictates.

This transition will be slated for the version 7 release in June 2016.

I noticed in the new version, cheesto.statusOptions is merging instead of replacing.

There are a few places in the API that similar functions for different modules have different names and different parameters. There needs to be more consistency between modules to ease development and memory. One example is to create a new log the endpoint is "create", for users it's also "create", but for categories it's "add". Likewise, editing logs and categories uses the endpoint "edit", but for users it's "save". One name should be choose and used for similar tasks. Either all create or all add, likewise for the rest.

For some reason only the first line of a log body is inside the log-body classes

tag. This is causing an awkward space between lines.

Affected version: 6.0.3

Create a system to allow permalinks for a particular search. Or maybe a views system per user to save frequent searches.

If a default theme is defined that doesn't exist, the layout is terrible and several warnings are produced.

Search needs some care. Ideas: Consolidate all search and filter to a single endpoint. Use a query syntax to distinguish search fields, example below. Consolidate UI to a single search query textbox perhaps with a query builder tool.

Proposed syntax: [field]:"search phrase"
Fields: title, body, log (both title and body), category (cat1: cat2:cat3), date (mm/dd/yyyy), author (username)
Each field/phrase combo would be separated by a single space. E.g.:
body:"administration" date:"02/15/2015" author:"joesmith"

This query would be sent as a single string to Dandelion to be parsed and queried

Add support for YubiKey's OTP. This would of course be in addition to the normal password (maybe have and option that the user can disable password?) As for database changes, new table called dan_yubikey_id with two columns id and uid. The id column will hold the unique piece of the OTP while the uid will be a foreign key to the user table id column. Setup will be in the settings tab and by default will be voluntary for each user. Perhaps make a config option to force YubiKey use. Extra configuration options include

"yubikeyOtp" => [
    "enable" => true,
    "clientId" => "",
    "secretKey" => "",
    "servers" => [], // By default use Yubico's cloud servers
    "useHttps" => true,
    "validateHttps" => true
]

An extra textbox would show up on the login page for users that have two factor enabled and the OTP would be sent with the password and username.

Currently, the date and time of an event is stored in local time. This needs to be changed to UTC and converted for display. Nothing exceptional is done with the datetimes so storing them as a simple Unix timestamp will suffice. A conversion will need to be done for existing events when the system is upgraded.

Currently API access is a global on/off switch. It may be beneficial to have a per-user switch allowing only come users access, but not all. This could help shrink the number of possible users that could be attacked via the api.

As for implementation, a field could be added to the User table called apiOverride that would be set 0/1 (true/false) depending on the status of the user. This field could be set to 2 to indicate "use the global setting". By default this would be 2. Thus if the global setting is false, and the user's setting is true (1) then the user's setting will take over. The reverse would be the same if global is true but user is false (0) then the user's will take over.

DB change: New field in User table "apiOverride", small int, 0 - api disabled, 1 - api enabled, 2 - use global setting. Defaults to 2.

User class: New method - setApiOverride(int i); The repo class will need to be changed appropriately.

API: New endpoint POST /users/apioverride - Parameters: override - int, defaults to 2

UI change: User management page will need a new select box labeled "API" with options "Enabled, Disabled, Use Global".

The root level renders fine but any sub levels will show the option text and regular concated text.

Between commits 927a9a6 and 7930beb dealing with the new dashboard in v6, I unintentionally failed to re-add the modified time from Cheesto's data on the dashboard. It should be a simple fix of adding to line 72 in cheesto.ts.

If Dandelion is not in the root of the web server, it doesn't act properly. Redirects don't use the FQDN, AJAX requests are using paths absolute to the root, and the navigation bar is using absolute paths. All of these need to the relative. The redirects need to use the FQDN.

With the new Repo system it should be a somewhat simple task to create new repos using SQLite synax. Some of the more complicated statements will need to be changed to execute multiple statements and them aggregate the results to return.

Search results beyond the log limit aren't shown and there's no next button to get the next page of results.

Steps to reproduce: Go to Settings -> click Save without changing anything. An error is returned. It should return a success.

It would be trivial and I believe more logical to combine the "read" and "readone" endpoints in the API and have an optional uid parameter that would dictate whether to return a single status or all statuses.

The icons for the messages could very easily be transformed into an SVG. It would be quicker to load, look better at any size, and wouldn't require extra network requests.

IE doesn't support initial and inherit properly. Many styles use these values.

After installer a few test instances I found myself constantly forgetting to install Composer. It would be nice to have an error text displayed saying something like "Please make sure Composer has been been installed". Otherwise, the only way to find out is by looking at the web server logs to see the error that the PHP interpreter spit out. This is more of a convenience than anything.

Have the ability to create separate "sites" in a single Dandelion instance. Users would have permissions to determine which site they can see and interact with. All logs would be stored in the same table but have an extra field called "site" which would be a simple int. A new table would be created called Sitenames with fields "id, name" where the name is user defined and the id is a foreign key for the Log table's site field. This will require several changes to how logs are handled, stored, and the user permissions system. A new system will be needed to manage sites. By default one site would be created called "Default Site".

With the use of Normalizer, the table on the user management looks terrible. It's needs to not look terrible. Preferably pretty.

There are several libraries for creating/verifying TOTP secrets and tokens. It would be trivial to make such a library. QR codes can be created by a few PHP libraries or even by requiring a linux package named "qrencode" and use a shell_exec to generate the image. The secret should be encrypted in the database and decrypted when the user enters the correct password. Or a site secret could be used so the TOTP secret could be used as verification at other times without asking for a password again. Ideally the secret isn't in plaintext.

Add feature to upload files along with logs.

The mail system is not very prominent in version 5. Actually, if it weren't for the small mail icon on the dashboard even I would forget Dandelion has a mail system. As such, it needs to be overhauled. Suggestion: Create a Message Center which would be a separate page with a link in the navbar. It would combine an expanded view of Ĉheesto plus a redesigned "mail" system renamed to messages. Messages would be more streamlined and operator like the messages on sites such as Facebook or Google+. Perhaps even adding the capability for group messages. The mini Ĉheesto would remain on the dashboard, but the button to popout would be removed. The mail icon would also be removed in favor of an unread count next to the Messages text in the navbar.

Part of issue #16 with plugins, the configuration needs to be reformatted into different sections. The defaults sections would be "core", where most of the current configuration would go, and "cheesto", which already exists. Eventually sections would be added for individual plugins. The "core" section could be split to "core-internal" for stuff like session timeout, session name, etc. And just "core" for stuff like the tagline, appTitle, and publicApiEnabled. Or the ApiEnabled setting could go in a section called "api". The cheestoEnabled setting would move to the Cheesto section of course and probably be renamed to simply "enabled". Basically provide some namespacing for settings.

Due to wanting to use the domain for mail, the original CNAME DNS record had to be removed that pointed to the OS Github Pages website. It has been moved to blog.onesimussystems.com. Eventually a real website will be put on the root domain, but for now it's barren. Existing installations will simply display "No update available" so the only impact will be no in-application notifications of new releases.

Implement a simple builder for the UI that will generate a search query for the user. The user would add what fields and keywords to search, a place to pick a date from a calendar, as well as categories. There would be no changes to the back end just a modal with text boxes, category selects, and jQueryUI time pickers. A simple icon can be added to the dashboard UI between the Search and Create New Log buttons.

If a user opens a page before logging in, they're redirected to the login page then to dashboard. Instead, they should be redirected to their original destination. For example, if I go to /new/log and get redirected to login, I should be redirected to the same /new/log after login.

Session expiration isn't quite reliable. It's really enforced application side as it should be. The only surefire way to expire a session is to deliberately log out. A simple last_accessed key would suffice plus a check to see if the session has expired. Checks will also need to be handled client side for ajax calls to redirect the client if ever a request is returned as not logged in.

On occasion, an entry can be exceptionally long. Whether it's because a lot was done or simply a lot of detail was given. When these show up on the dashboard it interrupts the flow of the page due to the wall of text. Long entries should be truncated on the dashboard with a "Show more" link to expand the entry. Or maybe open the entry in a new tab. This way, all entries are no taller than a pre-defined height and the page flows better.

How to achieve a faded overflow: http://stackoverflow.com/questions/22808040/fading-out-text-on-overflow-with-css-if-the-text-is-bigger-than-allowed