Mediawiki

At service activation,

• Tuleap will asynchronously call a REST endpoint on Mediawiki to do all the initialization workflow (db, storage & co).
• Until the DB is fully created there is an empty state when ppl load the MW endpoint
• If the service was already previously activated, it's un-suspended

At service deactivation,

• Tuleap will asynchronously call a REST endpoint on Mediawiki to suspend the MW instance (as when the project is suspended)

When project is created with MW service activated

• Same as service activation

When project is deleted

• Tuleap will asynchronously call a REST endpoint on Mediawiki to delete the instance

When project is renamed:

• Mediawiki supports rename as well (POST /tuleap/instance/rename/{oldname}/{newname})

Services change

This story also covers a bunch of changes in the way Services are managed. This is mostly internal work but it has consequences visible to users:

1. Introduce a new way to instantiate services in existing project. The problem exists since we create projects based on XML templates: some services cannot be activated in those projects because there is no entry in the services table in DB. It's the source of all the services changes done in the context of this story. In order to be able to activate Mediawiki Standalone service in all project, this has to be fixed.
2. Solving the previous issue introduce yet another event to be implemented by plugins to properly have services.
3. In order to limit the added the complexity, an existing event (ServiceUrlCollector) is removed
4. As ServiceUrlCollector also ensured that services urls were not modified by project administrators, this protection is now native to services and all services enforce it. We know this can be a source of regression at update for people that abused the previous way of working (for instance updating Agile Dashboard url to make point somewhere else but keeping the icon). This is wrong at many level:

• First the UX is inconsistent from one project to another. A user expect to click on something called "Agile Dashboard" (for instance) and go to the agile dashboard of the current project, not be moved somewhere else.
• It could also be used by an attacker to redirect people to a fraudulent service and capture information.
• It's source of nightmarish bugs when those kind of changes are made in a template project.

5. Finally as it's almost impossible to do it right, a new interface for plugins is proposed with all the events that should be listened to have service done right.