Open-Xchange - User contributions [en]

Yahoo Bundles

2017-07-31T16:19:51Z

John-david.henderson: /* Preparation */

= Using Yahoo with Open-Xchange =

== Preparation ==

The application keys for yahoo need to be replaced by ones gotten from an application managed at yahoo.

* Go to https://developer.yahoo.com/apps/create/ and sign into Yahoo. It is recommended to use a company-account for this where the credentials are known to more than one person.

* You will see a list of all yahoo-projects associated with the current account. Click "Create a Project" on the right

[[File:Yahoo_11.png | 800px]]

* Enter a name and description for the yahoo-application in fields "Application Name" and "Description" respectively. Both will be shown to your users when allowing access to Yahoo later.

* Enter the domain of your company website in field "Home Page URL"

* Select "This app requires access to private user data." under "Access Scopes"

* Enter the domain where your Open-Xchange server will run in field "Application Domain". This is important as the Api-Key and -Secret generated later and used with Open-Xchange will only work for this domain.

* Check "Contacts" under "Select APIs for private user data access:"

* Check "I have read and agree to the Yahoo! Developer Network Terms of Use." under "Terms of Use"

* Click "Create Project"

[[File:Yahoo_12.png | 800px]]

[[File:Yahoo_13_2.png | 800px]]

* Enter the value next to "Consumer Key" into file "/opt/openexchange/etc/groupware/yahoooauth.properties" as value for the parameter "com.openexchange.oauth.yahoo.apiKey". Please click the value to highlight the text.

* Enter the value next to "Consumer Secret" into file "/opt/openexchange/etc/groupware/yahoooauth.properties" as value for the parameter "com.openexchange.oauth.yahoo.apiSecret". Please click the value to highlight the text.

[[File:Yahoo_05.png]]

[[File:Yahoo_06.png]]

* Click "Verify Domain"

* On the next screen click the button "Verify" next to the domain of your application

[[File:Yahoo_14.png | 800px]]

* Do what is described on screen to verify your domain.

[[File:Yahoo_15.png | 800px]]

{{InstallPlugin|pluginname=open-xchange-oauth open-xchange-messaging|toplevel=products |sopath=appsuite/stable/backend |version=App Suite}}

{{InstallPlugin|pluginname=open-xchange-oauth-yahoo open-xchange-subscribe-yahoo|sopath=stable}}

== Configuration ==

If your OX server is reachable only via one host name, you won't have to do anything. If it is reachable by more than one host name, create or open the file "/opt/openexchange/etc/groupware/deferrer.properties" and set the properties therein as such:

com.openexchange.http.deferrer.url=https://mymaindomain.invalid

substituting the value of the property for the domain for which you registered the yahoo-application above (Parameter "Application Domain", see above under Preparation).

Spamexperts

2016-07-29T11:55:59Z

John-david.henderson: /* Provisioning */

= Introduction =

This package connects the [http://www.spamexperts.com/ SpamExperts] system with Open-Xchange.
It allows to access your SpamExperts settings from within Open-Xchange and use the spam- and ham
learning mechanisms of SpamExperts directly from within the Open-Xchange UI.

{{InstallPlugin|pluginname=open-xchange-spamhandler-spamexperts open-xchange-spamhandler-spamexperts-gui|sopath=6.22/backend|version=v6.22.x}}

{{InstallPlugin|pluginname=open-xchange-spamhandler-spamexperts open-xchange-appsuite-spamexperts|toplevel=products|sopath=appsuite/stable/backend|version=App Suite}}

=Components=

== OX UI Plugin ==

The UI plugin extends the OX settings tree with a new subtree to access the "Antispam" management WEB UI of Spamexperts.com

== OX Backend Plugin ==

The backend plugin consists of a servlet which can create an authentication ticket for the currently active OX user by using the
Spamexperts.com API and then sends the ticket back to the UI plugin which will do the redirect to the external Spamexperts.com management WEB UI.

= Configuration =

You need to adapt the settings in <tt>/opt/open-xchange/etc/spamexperts.properties</tt>

Settings can be separated in two sections:

== SpamExperts UI integration ==

Define your custom parameters in order to integrate your branded SpamExperts UI into Open-Xchange

== SpamExperts SPAM/HAM learning integration ==

'''Note: This requires backend version 7.6.0 or newer.'''

Configure you personal parameters to access the SpamExperts IMAP server in order to use the SPAM/HAM
learning mechanism.

In addition, you have to tell the Open-Xchange mail backend what spamhandler to use for SPAM/HAM learning.
This must be done in the configuration file <tt>/opt/open-xchange/etc/imap.properties</tt>. You have to set

com.openexchange.imap.spamHandler=SpamExperts

exactly like this, or the SPAM/HAM learning mechanism will not work.

= Provisioning =

'''Note: This requires backend version 7.6.0 or newer.'''

In order to activate SPAM/HAM learning in OX Webmail, you have to turn that on for the users.

Using create- or changeuser, provide the option <tt>--gui_spam_filter_capabilities_enabled true</tt>

In order to add the spamexperts link to OX Webmail, provide the option <tt>--capabilities-to-add com.spamexperts</tt>

[[Category: Administrator]]

[[Category: OX6]]
[[Category: AppSuite]]

[[Category: Spamhandling]]

AppSuite:Configuring portal plugins

2016-04-15T13:59:24Z

John-david.henderson: /* Configuring the portal */

{{Stability-stable}}
{{VersionFrom|7.4.0}}

= Configuring portal plugins =

''Synopsis:'' This article covers how to configure which plugins ("tiles") are shown, whether they are mandatory or just suggested to the user.

__TOC__

== Configuring the portal ==

When running OX AppSuite you may want to specify a starting configuration for which tiles the portal shows and whether certain tiles are mandatory or not. This is especially useful when you are introducing your own tile implementations. To make this possible, the portal consists of three types of tiles: User tiles, eager tiles and protected tiles. User tiles are tiles that the user added herself to the portal page, eager tiles are those suggested by the installation which can be removed and protected tiles are set by the backend.

In order to specify a tile, you will have to know about the configuration data to enter. You can use an appsuite installation to do that. If you want to configure a tile as eager or protected, navigate to the settings area of the portal page, add the tile you want and, in the JS console, enter:

require("settings!io.ox/portal").get("widgets/user")

and in the list find the tile you want to suggest to or force on your users. As an example, we'll use the birthday widget:

birthdays_0: Object
color: "lightgreen"
enabled: true
id: "birthdays_0"
index: 6
inverse: false
plugin: "plugins/portal/birthdays/register"
props: Object
type: "birthdays"

In order to configure widgets on the backend we have to turn the above into a valid YAML structure:

birthdays_0:
color: "lightgreen" # one of black, red, orange, lightgreen,
# green, lightblue, blue, purple, pink, gray
enabled: true # Has to be true
index: "first" # Where the widget is supposed to show up.
# Possible values are numbers, "first" or
# "last"
inverse: false # If true, the color is applied to the body
# of the tile and not the title. Can highlight
# particular tiles
plugin: "plugins/portal/birthdays/register" # The source file that contains the tile code
type: "birthdays" # The id of the widget type. Not the id above
# has to have the form [type]_[someNumber]

Now we can use this snippet to configure the birthday widget in a variety of ways

== I want to suggest a widget, but the user can remove it, if they don't like it ==

For this, you can use the "eager" configuration method. Not that if you specify an eager or protected widget, all default widgets from Open-Xchange will not be configured as defaults anymore, so you might want to configure them as eager tiles as well. But let's stick to the birthday widget for now.

* Add a file /opt/open-xchange/etc/settings/portal.yml

io.ox/portal//widgets/eager/gen_0:
birthdays_0:
color: "lightgreen"
enabled: true
index: "first"
inverse: false
plugin: "plugins/portal/birthdays/register"
type: "birthdays"

This means the widget will be enabled for users, but users can still disable it. If you want to, at a later time and since you've made significant improvements to the tile, want to show it to the user again, you have to increase the "generation" of the widget configuration and offer it again:

io.ox/portal/:
generation: 1

io.ox/portal//widgets/eager/gen_0:
birthdays_0:
color: "lightgreen"
enabled: true
index: "first"
inverse: false
plugin: "plugins/portal/birthdays/register"
type: "birthdays"

io.ox/portal//widgets/eager/gen_1:
birthdays_0:
color: "lightgreen"
enabled: true
index: "first"
inverse: false
plugin: "plugins/portal/birthdays/register"
type: "birthdays"

All the "gen_[number]" entries up the tie io.ox/portal//generation will be used for this configuration. If a tile is deleted it is deleted only in that generation so can be reintroduced in a later portal configuration generation. If you want to keep the default tiles as used as a fallback for App Suite, you need this configuration to start out with:

io.ox/portal//widgets/eager/gen_0:
mail_0:
plugin: 'plugins/portal/mail/register'
color: 'blue'
enabled: true
index: 1
calendar_0:
plugin: 'plugins/portal/calendar/register'
color: 'red'
enabled: true
index: 2
tasks_0:
plugin: 'plugins/portal/tasks/register'
color: 'green'
enabled: true
index: 3
birthdays_0:
plugin: 'plugins/portal/birthdays/register'
color: 'lightgreen'
enabled: true
index: 4
twitter_0:
plugin: 'plugins/portal/twitter/register'
color: 'pink'
enabled: true
index: 5
linkedin_0:
plugin: 'plugins/portal/linkedin/register'
color: 'lightblue'
enabled: true
index: 6

And then modify this as wanted for your deployment

== Forcing a tile ==

Similarly to the eager tiles, tiles can be "protected", i.e. they can not be moved, removed and disabled. The configuration for this looks like that:

io.ox/portal//widgets/protected:
birthdays_0:
color: "lightgreen"
enabled: true
index: "first"
inverse: false
plugin: "plugins/portal/birthdays/register"
type: "birthdays"

If you want to allow movement of the widget, you can enable this in the following way:

io.ox/portal//widgets/protected:
birthdays_0:
color: "lightgreen"
enabled: true
index: "first"
inverse: false
plugin: "plugins/portal/birthdays/register"
type: "birthdays"
changeable:
index: true

In which case, users will be allowed to move the tile.

One caveat in all this: After changing any of the above configuration, you will have to reload the UI *twice*, since App Suite uses read-through caching for the settings data.

== Disabling a tile completely ==
The combination of making a tile both protected and disabling it makes it impossible for the user to enable it. From 7.6.0 on, this means it is not shown in the settings either. Before that, it was greyed out but still present.

io.ox/portal/:
widgets:
protected:
quota_0:
color: "red"
id: "quota_0"
enabled: false
index: 1
inverse: false
plugin: "plugins/portal/quota/register"
type: "quota"

[[Category:UI]][[Category:AppSuite]]

[[Category:Portal]]

[[Category:Administrator]][[Category:Developer]]