Add possibility to create Mobile Apps in Sites Management (and later any type)

[tsteur]

This issue needs to be solved for #7131 and #4734

A "type" could be a plugin that defines a type "Website" or "MobileApp". Different types need not only different reports and different naming of reports but also different fields in the Sites Manager. The Sites Manager might become at some point a Property Manager or something else. Naming is not important for now.

A mobile app would not define any URLs but an App-ID such as org.piwik.mobile or 737216887.

We would maybe also allow to select an App store? Eg Google Play, ... Not needed by core actually but by a App Analytics plugin later. Not sure how to handle this!

Things to consider

• In the Sites Manager are currently columns shown like "URLs" which does not apply to all kind of types. After New design for Administration screens #7587 was implemented we could maybe show only columns that apply to actually all "types" like "Excluded IPs" etc. URLs would not be shown in the overview but when the site is expanded. I know this lowers the usability a bit since it is nice to see the URLs at a glance. We could do this only if there are different types etc.
• The type "Website" would define a URLs field. This would be not shown to other types by default.
• The "JavaScript Tracking Code" would be only needed for sites but not for mobile apps. Here we would want to see either nothing (when no SDK is available) or links / code for Android / iOS SDK tracking generator code refs Tracking code generator: Allow to generate tracking code for mobile apps etc. #7803
• We would detect if a plugin defines a "Type". If so, when creating a new type/property/website, we would also show all available plugins on the marketplace defining a new type. This means the user will be directly able to install new plugins from there etc. (in a later version)
• When a type defines a new field such as "App identifier" then we need to create a column in the site table for that. Alternatively we will store such things as JSON in a "custom" field (more likely we go with this).
• We might want to open a new page when clicking on "Add a new website". This will let the user focus on the task of website creation. Also we can make it a bit nicer this way and let the user choose what kind of type the user wants to create.
• TBD how to handle URLs for Mobile Apps. I think some features depend on URL's.
• Where can which settings be accessed "savely"? eg different types define different settings/fields. If there's an AppId setting for a type Mobile App. How can anyone know about that? And for other types this property does not exist...
• Should we store site settings in option table or site table? Super easy to implement for options, if we store it in site table all information would be in one place and we can easier return it in API calls of SitesManager but: it would be still slow since we'd have to check read permission for each type of each site and create many instances etc
• A type can define a link for Tracking Code. But core does not know anything about Tracking code. Therefore it would be maybe kinda wrong to have a tracking code link definition in Type class? Same might apply for other things. In theory a developer would have to listen to an event on top for this, but that's complicated to do
• Site Urls are only Website specific. Shall we remove methods like SitesManager.getSiteUrlsFromId? Site URLs are not as much used in general. But we'd also need to remove main_url
• What if multiple plugins define same "setting". --> we can detect that and mark plugins as incompatible or prefix them with PluginName.SettingName (might be difficult or impossible)
• Custom TypeSetting via postEvent (more flexible) or classes auto detection (one setting would always apply to all types)
• Note for myself: configureSettings might get pretty long
• It would be actually nice to have everything based on TypeSettings and have everything reusable. Meaning one could use new NameSetting(), new ExcludedParameterSetting() etc.
• Type could be also named View

[tsteur]

We actually need the possibility to require plugins. See #4485

[tsteur]

So far we came to the following definition.

A property (eg Piwik Mobile 2) has a name, a created timestamp, some other fields but also it has a type (eg MobileApp).

Some more of my thoughts:

In general we might differentiate between attributes, setting and feature:

• A feature would be for example "Site Search" as it provides new functionality
• An attribute would be for example "Currency" or "App-ID" as a property has a currency or app-id and it is just a plain attribute more or less.
• A setting or config could be for example action_title_category_reverse as it changes existing functionality. Eg it reverses the action titles but it doesn't provide the feature of action titles itself.
• note for myself: A report or archiver could be a feature, and if one disabled a feature "action titles" one might actually disable a couple of reports, dimension, and other things.

A type (eg MobileApp) can define which attributes it consists of and which features make sense for this type.

Any plugin can extend any type and define custom attributes and features. For example the Ecommerce plugin provides an EcommerceFeature and the Actions plugin provides a SiteSearchFeature. If a plugin wants to access an attribute/feature/setting that it not defines itself, it needs to require the other plugin. For example an Ecommerce plugin might require the Goals plugin as it wants to use the Currency attribute defined by the Goals plugin.

It will be quite hard to differentiate between those 3 things (feature/attribute/setting) for some people and can be overwhelming. Also it is in general not really a good idea to have too many solutions for a problem. That's why we want to maybe simplify it. Eg we could merge setting and attribute to attribute. For example we could say a property has an attribute of reversed action title categories (actually it doesn't really make sense to say this is an attribute).

On the other side we need to think about what is actually used in which context. This means we might be actually able to use the different terms:

• A setting would be usually only defined by a plugin that also defines and implements a feature since it changes existing behaviour. That means the setting is bound to the feature and a setting is most likely not defined by a type (eg MobileApp).
• A type rather defines attributes, such as "App-ID" or "Currency" and features that it supports, for example a "Site Search". Thinking more about it a type might rather not define whether it supports a certain feature as it can't know which features exist etc. Maybe a type should mainly or only specify attributes.
• A single plugin then might provide a certain feature (one feature might has one or more settings) and that feature can be required by other plugins. Meaning ideally plugins should be able to require types and features eg in plugin.json. It should not care by which plugins those types or features are actually provided. This would be the ideal solution that we cannot really implement most likely since we can't tell which plugin defines which types and features. The workaround would be to develop plugins that only define a type or only a feature. Meaning "Site Search" should not be in the "Actions" plugin but it should be a plugin itself. Also "CoreHome" should not provide a "MobileApp" and "Website" type. Rather those should be independent plugins so they can be required.

Some conclusions:

• The PluginSettings API supports currently SystemSetting and UserSetting. This needs to be extended by a PropertySetting. We will pick those PropertySettings in Sites Management (later Property Management) and display them there. This way we can still use the term Settings and it makes sense. Meaning the Actions plugin would define a new PropertySetting('action_title_category_reverse'). If it can't be define in a plugin this way, then we're talking about an attribute which is defined by a type
• When we speak of features we actually speak of plugins. Eg SiteSearch plugin, Ecommerce plugin. A plugin then defines the plugin settings as it can do already.
• A type can define attributes. There will be for example a configureAttributes API and any plugin will be able to enrich a certain type by adding more attributes. For example the type MobileApp will define an attribute App-ID. Then another plugin could enrich this type and add two more attributes App Store Login and App Store Password. They cannot really be a Setting for a feature since those attributes make only sense for the type MobileApp. Otherwise it would be actually a setting! It is maybe too difficult to have both. What do you think? Update: We will not use the wording attributes but instead PropertySettings as well.

To be decided

• How would a type define which feature it supports? By enabling/disabling entire plugins? Or would we always use attributes for features? For me personally the natural step would be to say a type can disable features by disabling other plugins but the platform doesn't support this currently. For example we'd have to recreate asset_manager_global.css whenever one changes the property. Also caches assume that always the same plugins are loaded etc. Maybe we can somehow "ignore" plugins

[tsteur]

If someone deactivates a plugin that configures a type, how shall we handle that? I'd say we assign the type universal to them but we currently do not have that type yet. website will be always activated so plan for now will be to always assign type website if someone eg deactivates type mobileapp .

Update: Turns out it is not as easy to handle this. Instead we will default to a "universal" type if a specific type cannot be found. This also allows people to deactivate and activate a plugin again without losing any information

[tsteur]

I wonder if developers want to create a "UserSetting" that is connected with a particular site/property. We currently have SystemSettings (global setting, can be usually configured only by a super user) and a UserSetting (can be changed by any user, affects only the user). Meaning at some point I reckon there might be the need to let users configure something per property (per website).

Imagine the LiveTab plugin. There we have a UserSetting which metric to show in the browser tab. The metric that you want to see might be different per website though. This means we might want to show regular users (not having admin permission) the Sites Manager and let them change some settings per website? (maybe not MVP but at some point). Any thoughts?

[mattab]

This means we might want to show regular users (not having admin permission) the Sites Manager and let them change some settings per website? (maybe not MVP but at some point).

My thoughts: good point, but it is not needed in MVP but maybe interesting later (likely we won't need this feature for a while, ie. until we have one or two use cases)

[tsteur]

It will be pretty important for the code / design as it changes quite a lot. So I reckon we need to find a solution that will allow something like this at some point

[tsteur]

Note: We might have to integrate this into the installation as well (once Mobile Apps plugin is enabled by default) as we currently always let users create a website during installation. TBD

[mattab]

@tsteur a lot of progress was made on this issue - what is the current status? what work is left for 2.15.0 or for 3.0.0?

[tsteur]

We need to implement everything properly for 3.0.0. Especially the Settings API needs a lot of refactoring and rethinking. Also we need to agree on final naming etc. We should talk about this stuff in Berlin/Poland maybe as well.

[tsteur]

I've continued working on this one and been thinking about it a lot re changing our setting API's to make sure it's still possible to refactor, to understand it easily, to get easily values for these settings, easy to use via DI, performance, and been thinking about who wants to use it and now. Ideally it was possible to generate each individual setting etc. Problem is re Measurable settings we do not know enough about it yet and current way of doing things works kind of well so I came to conclusion I don't want to change too much.

Possibly I will move $plugin/Settings.php to $plugin/Settings/Plugin.php and also have a class $plugin/Settings/Measurable.php. They will both work similar as before. Measurable Types will be able to define Measurable settings too.

I will try to expose all Settings via an API and try to render settings via Angular instead of Twig if possible. Otherwise we always have some kind of hidden requests like iframes in "Manage Measurables" when editing a "measurable" and many settings like "URL" would load very delayed after a measurable was already opened. In order to do this there might be some more changes to the API needed but will try to keep them to a minimum.

I might create a table piwik_plugin_settings similar to piwik_site_settings and no longer store plugin settings in Option table just for consistency with piwik_site_settings and to be able to reuse code here maybe. Will see.

I will try to convert many of our existing measurable settings like URLs, exclude query parameters etc to settings but need to see how it goes. Main problem here is that we need some kind of different storage for these fields as they are stored in piwik_site whereas new settings will be stored in piwik_site_settings.

[tsteur]

FYI: I also thought of just using .json files to define settings. However, it's a bit problematic with refactoring and autocompletion in IDE and such stuff. Also some settings and whether someone has access to read or write a setting depends on access, sometimes one setting is only available after another one was enabled, often a custom validation of input values is needed etc and in many cases we would still need a solution in PHP. Last but not least it would be possible for anyone to open/read these json files (shouldn't be critical but can become a problem). It would be possible to allow to define validators etc via JSON but it would be a lot of effort to build and maybe not worth it for now as we do not really have problems with current settings API.

[tsteur]

@mattab could we move this into the backlog? or maybe it can be even closed?