From 6421ccd7f8c3a57b953fa23fbe87e900f8ae2359 Mon Sep 17 00:00:00 2001 From: Frédéric Buclin Date: Sun, 14 Oct 2012 12:55:09 +0200 Subject: Bug 781314: The behavior of tags changed r=wicked a=LpSolit --- docs/en/xml/using.xml | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) (limited to 'docs/en/xml') diff --git a/docs/en/xml/using.xml b/docs/en/xml/using.xml index 3bf0558fc..bed776dd3 100644 --- a/docs/en/xml/using.xml +++ b/docs/en/xml/using.xml @@ -665,14 +665,10 @@ Adding/removing tags to/from bugs You can add and remove tags from individual bugs, which let you find and - manage them more easily. Creating a new tag automatically generates a saved - search - whose name is the name of the tag - which lists bugs with this tag. - This saved search will be displayed in the footer of pages by default, as - all other saved searches. The main difference between tags and normal saved - searches is that saved searches, as described in the previous section, are - stored in the form of a list of matching criteria, while the saved search - generated by tags is a list of bug numbers. Consequently, you can easily - edit this list by either adding or removing tags from bugs. To enable this + manage bugs more easily. Tags are per-user and so are only visible and editable + by the user who created them. You can then run queries using tags as a criteria, + either by using the Advanced Search form, or simply by typing "tag:my_tag_name" + in the QuickSearch box at the top (or bottom) of the page. To enable this feature, you have to turn on the Enable tags for bugs user preference, see . This feature is disabled by default. @@ -684,9 +680,7 @@ these bugs and mixing all these reasons, you can now store these bugs in separate lists, e.g. Keep in mind, Interesting bugs, or Triage. One big advantage of this way to manage bugs - is that you can easily add or remove bugs one by one, which is not - possible to do with saved searches without having to edit the search - criteria again. + is that you can easily add or remove tags from bugs one by one. -- cgit v1.2.3-24-g4f1b From aa7fbd9b8f7264d131aa53ae2b3f867b4e7b8fc7 Mon Sep 17 00:00:00 2001 From: Frédéric Buclin Date: Fri, 2 Nov 2012 18:35:38 +0100 Subject: Bug 806012: Installation docs need to be updated with instructions for bzr r=dkl a=LpSolit --- docs/en/xml/customization.xml | 8 ++++---- docs/en/xml/installation.xml | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) (limited to 'docs/en/xml') diff --git a/docs/en/xml/customization.xml b/docs/en/xml/customization.xml index 9b62b1d0b..c1524e07d 100644 --- a/docs/en/xml/customization.xml +++ b/docs/en/xml/customization.xml @@ -110,14 +110,14 @@ The first method of making customizations is to directly edit the templates found in template/en/default. This is probably the best way to go about it if you are going to - be upgrading Bugzilla through CVS, because if you then execute - a cvs update, any changes you have made will + be upgrading Bugzilla through Bzr, because if you then execute + a bzr update, any changes you have made will be merged automagically with the updated versions. - If you use this method, and CVS conflicts occur during an + If you use this method, and Bzr conflicts occur during an update, the conflicted templates (and possibly other parts of your installation) will not work until they are resolved. @@ -143,7 +143,7 @@ The second method of customization should be used if you use the overwriting method of upgrade, because otherwise your changes will be lost. This method may also be better if - you are using the CVS method of upgrading and are going to make major + you are using the Bzr method of upgrading and are going to make major changes, because it is guaranteed that the contents of this directory will not be touched during an upgrade, and you can then decide whether to continue using your own templates, or make the effort to merge your diff --git a/docs/en/xml/installation.xml b/docs/en/xml/installation.xml index e9830e29c..2da3a8e79 100644 --- a/docs/en/xml/installation.xml +++ b/docs/en/xml/installation.xml @@ -191,8 +191,8 @@ Download a Bugzilla tarball - (or check it out from CVS) and place - it in a suitable directory, accessible by the default web server user + (or check it out from Bzr) + and place it in a suitable directory, accessible by the default web server user (probably apache or www). Good locations are either directly in the web server's document directories or in /usr/local with a symbolic link to the web server's -- cgit v1.2.3-24-g4f1b From fbbd624a0d0958b1b7ece2e4286d2a4c73af0bc2 Mon Sep 17 00:00:00 2001 From: Dave Lawrence Date: Tue, 13 Nov 2012 15:00:43 -0500 Subject: Bump version to 4.2.4 https://bugzilla.mozilla.org/show_bug.cgi?id=805644 --- docs/en/xml/Bugzilla-Guide.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/en/xml') diff --git a/docs/en/xml/Bugzilla-Guide.xml b/docs/en/xml/Bugzilla-Guide.xml index 1ed72f64a..e8497962d 100644 --- a/docs/en/xml/Bugzilla-Guide.xml +++ b/docs/en/xml/Bugzilla-Guide.xml @@ -32,9 +32,9 @@ For a devel release, simple bump bz-ver and bz-date --> - + - + -- cgit v1.2.3-24-g4f1b