Move tags page to /admin and add public flag

Just to be clear, is the issue that aims (among other things) to provide for per-user tags?

While that is not the main aim of it, #442102: Replace tag checkboxes with autocomplete textfield does make tags appear as per user to the end user without mucking about with the current database schema.

If need be to go further than that, that can be made to happen in a follow up issue, however IMO that will add unnecessary restrictions to the module with no visible change to end users.

(so the answer to the asked question is "no, but it should not matter to the end user either")

On the above list of tasks, I do not think we need to do:

- add administer tags permission (we still need "create tags" permission for the on-the-fly creation of tags)

As we should IMO just use "administer privatemsg" permission for this. Also to expand on the role of:

- Add a flag "public" to the {pm_tags}, default to 0/FALSE

The way I understand it is that in addition to the user's used tags from #442102: Replace tag checkboxes with autocomplete textfield, we may also want to expose a set of other tags to the user in the interface, probably through #444264: Add tagging actions to message listing

So 442102 will result in tags that are--as far as users can tell--their own... and they will not see anyone else's?

A question Do we want to auto prune tags that are unused and NOT system tags?

If so, what would the valid sql be?

SELECT * FROM pm_tags WHERE tag_id NOT IN (SELECT pmt.tag_id from pm_tags pmt INNER JOIN pm_tags_index pmti on pmt.tag_id = pmti.tag_id WHERE pmti.uid = %d)

^^ shows all unused tags, but replacing "SELECT *" with "DELETE" is invalid syntax according to phpmyadmin.

Looks good - a few observations

1. privatemsg_filter_sql_taglist and privatemsg_filter_sql_used_tags and pretty similar - not identical but close, so maybe merge them into one with some way to switch for the extra arguments?

2. Do we want privatemsg_filter_sql_tags_autocomplete to be altered to show only public tags, or tags used by the user in the drop down?

3. For tags created on the view messages page, the tags will always be private - maybe have an option on the settings page to toggle this to TRUE or FALSE?

4. When adding a tag from admin/settings/messages/tags/add, the public checkbox is always checked. It would be good if 3 is handled to then also work off that same variable?

5. The pager_query has a default $limit of 10. in core, for taxonomy they had to change this to a larger value as such small pages were almost unuseable in large taxonomies - they moved to 100. Should this patch do the same?

6. in privatemsg_tags_form_submit maybe add comments along the lines of "since there is a tag id this is an existing tag, we want to update" and "no tag id implies we are creating a new tag" ?

None of these are really bugs though - just enhancements, looking for better integration etc. so leaving as cnr.

from irc, 3 and 4 from the above list are "features not bugs" and understandably so, so they are to be ignored. Number 2 can be done in a followup patch as other infrastructure parts of the filer module are also added/committed.

Do we want this to be as so?

+    $row['public'] = $tag['public'] ? t('Yes') : '';

I can see how having yes and no in there could get crowded, but yes and blank seems to be weird. It is also possible to create duplicate tags.

I still think 3 should be configurable while 4 is correct...

Other than that, it seems to be good. leaving as cnr for the above - but they are minor and this can be committed as is with them left as follow ups.