afdaniele / compose Goto Github PK

It looks like API calls with App ID/Secret do not work on HTTP when HTTPS is enabled.
The server returns app_id is mandatory. Maybe the arguments are not forwarded to HTTPS.

All the API calls to the duckiebot API service are open to the guest user to avoid PHP session lock. Fix this when the PHP session lock is fixed.

For package store package version comparison, devel should be always larger than any available version and should not prompt for update.

If you pass page=0 to a page with a TableViewer object, the results count will go negative.
For example, in the page aido_dashboard:submissions, with page=0, I see

Results:
( -9-6 )  |  16 total	

Make sure that we remove the symbol / at the end of all the paths stored in configuration.json.

Use session_write_close(); to suspend the session, save the file and release the lock for those API calls that do not change the $_SESSION variable. Add a boolean parameter 'read-only' to web-api-specification.json for each action.

When running \compose\ in docker, it would be useful to read the Google Sign-In Client-ID from an environment variable.

Every time we confirm a step in setup/, the page reloads up to the tab we confirmed, then stops for a while and reloads to the next step. Add a loading gif to the body of the tab for this intermediate load. This will show that something is happening.

When the Duckiebot name has numbers at the end, the name parameter is declared as 'not valid'

In web-api/index.php, it seems that nobody is checking $action['access_level'] against Core::getUserRole(). Investigate this.

TODO: try to run an administrator-only action while logged as a simple user and see what happens and in case who/what complains.

In the Settings page, opening and closing the Cache section multiple times will have the effect of expanding the canvas size of the two pie charts.

If you select a package for an update in the package store and then you click on cancel, the action turns into a uninstall for that package.

If we install compose in a directory that does not belong to www-data (very common when the code is mounted from outside a Docker container), compose cannot create the configuration file for the core package at boot. This prevents the default value of maintenance_mode from metadata.json to be written, and the user is redirected to maintenance since the default value passed to Core::getSetting('maintenance_mode', 'core') is true.

We either show an error in this case or make it easier for the user to figure out what the issue is. Perhaps, we could use the entrypoint script to check and notify the user somehow (on-the-fly written page?).

Error reported at 2018-11-12 07:02:17 GMT.

Error message:
An error occurred while talking to the challenges API. The server returned the code <strong>500</strong>.

For packages that already exist in the package directory. If it is an incompatible package, it should not prompt the user to update, but rather uninstall only.

Hello! I no longer need the documentation myself but I figured I'd give you the heads up that the full documentation link on the README (http://compose.afdaniele.com/docs/latest/) is not working and just redirects to your home page.

Cheers!

Website compose.afdaniele.com, the page build_markdown from the package doxygen does not have a menu entry but qualifies as child_page of the page docs. The menu entry of the page docs does not highlight when build_markdown is visited.

When an error is thrown (i.e., Core::throwError()) but there is no message, the error page will refuse to render and redirect to the default page. When the default page generates the error (with no explanation) a weird loop situation arises.

A possible solution would be to change the error page so that a default error message is shown when there is no message.

It is possible (smoehow) to access pages that are disabled.

In Settings, Codebase tab, the code provider shown is http:////.git. Something is wrong with the way *\compose* is retrieving the origin from git.

The configuration file for the core package (and I guess the others packages too) are dumped with the values not formatted according to the metadata of the configuration.

For instance, the file metadata.json of the configuration for the core package reads:

{
    "configuration_content" : {
        "maintenance_mode" : {
            "title" : "Mainteinance mode (NOT YET IMPLEMENTED)",
            "type" : "boolean",
            "default" : false,
            "details" : "Whether the platform is in maintenance mode"
        },
        . . .
    }
}

whereas after pushing a new configuration from the browser, this is what the file configuration.json looks like:

{
	"maintenance_mode": "1",
	"navbar_title": "Welcome",
	"logo_white": "http:\/\/compose.afdaniele.com\/images\/compose-white-logo.svg",
	"logo_black": "http:\/\/compose.afdaniele.com\/images\/compose-black-logo.svg",
	"admin_contact_email_address": "[email protected]",
	"cache_enabled": "0",
	"guest_default_page": "login",
	"user_default_page": "profile",
	"supervisor_default_page": "profile",
	"administrator_default_page": "profile"
}

It is clear that maintenance_mode should be formatted to be true rather than 1.