Feature Proposal: TagMePlugin with multiple tag namespaces support

Motivation

Current TagMePlugin is not so suitable for a large site having thousands of webs because

• tags put on topics are stored under a single directory
  • This doesn't suite well with RepositoryForSiteAndWebMetadata
• there is only one tag name space
  • A large site may provide each web with autonomy, which conflicts with a single tag name space on a site
• tagging is not disabled on a read-only (ReadOnlyAndMirrorWebs) web
• tags are not user agnostic. User can't remove a tag added by someone else.

Description and Documentation

Multiple namespaces

Originally it has only one tag name space. By setting $TWiki::cfg{TagMePlugin}{SplitSpace} to true, each top level web has its own tag name space. Tag data files are stored at: pub/TOP_LEVEL_WEB/.tags

When a page is copied or moved The tag data of the page is copied or moved if needed. If the target web has no sign of tag use (no tag data directory), tag data is not copied or moved. The list of all tags (_tags_all.txt) gets expanded if necessary.

Disable tagging on read-only web

For a read-only web, tagging operation should be disabled.

User agnostic tags

TWiki sites can have user agnostic tags by setting $TWiki::cfg{TagMePlugin}{UserAgnostic} to true. The tag T put to the page P1 by the user U1 and the tag T put to the page P2 by U2 are equally the tag T for everybody. This allows user to remove a tag added by someone else.

Permission for user agnostic tags

Tag change permission and tagging permission

There are two sorts of permissions - 1) permission to create/rename/delete tags (let's call it tag change permission here); 2) adding and removing tags to/from a page (let's call it tagging permission here).

A user having tagging permission to a page (2) but not having tag change permission (1) can add an existing tag to the page and can remove a tag. A user having tag change permission is guaranteed to have tagging permission to all the pages of the site. This may sound unnecessary. The logic behind this is as follows.

• If you have tag change permission, you can add and delete tags. Only unused tags can be deleted. As such, when you delete a tag, you need to remove the tag from all pages having it.
• If you have tag change permission, you can rename an existing tag. A rename operation ends up changing tags of multiple pages.

For these, if you have tag change permission but you don't have tagging permission, it's strange.

Tag change permission is a site-wide permission whereas tagging permission is either site-wide or page by page.

How tag change permission and tagging permission are determined

By default, users who can edit WebPreferences has tag change permission. Also by default, users who can edit a page can add and remove tags to/from the page.

You can explicitly specify tag change permission by setting ALLOW_TAG_CHANGE and/or DENY_TAG_CHANGE variables on WebPreferences. The way they work is similar to other access control variables ALLOW* and DENY*. You can find out the details of TWiki's access control at TWiki.TWikiAccessControl.

Tagging permission can be explicitly set by the DENYTOPICTAG, ALLOWTOPICTAG, DENYWEBTAG, and ALLOWWEBTAG variables.

Because of the way tag change permission and tagging permission behave, if you want to restrict who can tag pages by setting ALLOWWEBTAG, ALLOWTOPICTAG, DENYWEBTAG, and DENY_TOPICTAG, while allowing people to edit pages, you need to restrict who can change tags by setting ALLOW_TAG_CHANGE and/or DENY_TAG_CHANGE.

Regardless of these settings, the members of the contact mail group of a site have tag change permission. Hence they can add and remove tags on any page of the site.

Examples

Tag name space example

Each top level TWiki site has its own tag name space. Let's say Site1 has the following tags:

• apple
• orange
• lemon

Another site Site2 can decide what tags it has on its own. e.g.

• kiwi
• durian
• mango

This is what it means by each top level TWiki site has its own tag name space. Sub sites share the same tag names as its parent site. The site Site1/Sub1, which is a sub site of Site1 has the same exact tags as Site1:

• apple
• orange
• lemon

Impact

Implementation

-- Contributors: YaojunFei - 2012-11-13

Discussion

Looks feasible.

One thing though, an older version of this plugin used the pub directory for plugin internal data. The recommended place to store is the plugin's working directory, that is why recent versions of this plugin store tag data in twiki/working/work_area/TagMePlugin/.

I recommend to define a structure for plugin working area in regards to data replication. It could be a sub-directory called webdata for web-specific data. Plugins place data in that directory matching the name of the TWiki root webs, e.g. the Main web tag data would be stored in twiki/working/work_area/TagMePlugin/webdata/Main/. The replication would be done only if a /webdata/ directory exists.

-- PeterThoeny - 2012-11-14

Putting tagging data under work area can be a little difficult for copying, moving and mirroring a site, while pub folder is processed by default. Tagging data will be saved under /pub/web/.tags which is a different place from that older version. I think it should be OK since this multiple namespaces feature is switched off by default.

-- YaojunFei - 2012-11-14

It looks a bit like a hack to me to have data by default in the working dir of the plugin, but to have the same data under pub dir for special case when multi-site is used. I basically disagree and commit to this feature, meaning OK to implement as proposed.

-- PeterThoeny - 2012-11-21

Accepted by consensus reached at JerusalemReleaseMeeting2012x11x22.

• For later, better to enhance the Func API to support two types or working data: Transient data, and persistent web specific data
• One idea is to add a new getWebWorkArea( $pluginName, $web ) -> $directorypath, another idea is to add a new parameter: geWorkArea( $pluginName, $web ) -> $directorypath

-- PeterThoeny - 2012-11-22