Closed
Bug 233398
Opened 21 years ago
Closed 15 years ago
Section 4.2: CVS prevents hooks documentation from being accurate
Categories
(Bugzilla :: Extensions, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.6
People
(Reporter: justdave, Assigned: mkanat)
References
Details
Attachments
(1 file)
12.44 KB,
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
The current documentation states there are directories for the hooks files to be
placed in already. We can't create empty directories in CVS for the hooks.
Either checksetup.pl needs to create them (automatically by grepping for
Hook.process?), or we need something in them (a README file?) or we need to
change the documentation to indicate that the user needs to create it. Our
tarball-producing scripts and the cvs command line that we tell people to use
will cause empty directories to be removed on checkout.
Assignee | ||
Comment 1•21 years ago
|
||
You could put an empty hidden file in there, called .dir. -M
Comment 2•21 years ago
|
||
Max: such a file wouldn't be hidden on Windows.
I say we change the documentation to tell the user to create it. We'd need to
explain it quite carefully, but I'm sure we can manage that.
Gerv
Comment 3•21 years ago
|
||
Making users create these directories makes things harder for them
unnecessarily. Of the options, the README sounds best to me, since it's the
simplest, lowest-tech approach (i.e. doesn't rely on possibly buggy code), and
we could put a brief note in it explaining where hooks in the directory get
placed in the UI.
Note that a README file only needs to be placed into the lowest-level
directories (f.e. extension/hook/global/useful-links/edit), since other
directories'll have child directories within them.
Comment 4•21 years ago
|
||
Yeah, OK. Sounds sensible.
Something like:
"Templates in the directory are hooked into <part of the UI>.
For more information on the "hooks" customisation mechanism, see the Bugzilla
Guide."
Gerv
Reporter | ||
Comment 5•21 years ago
|
||
Preliminarily moving all docs bugs to 2.18, we should make a valiant attempt to
have the docs as up-to-date as possible when 2.18 releases.
Target Milestone: --- → Bugzilla 2.18
Updated•19 years ago
|
QA Contact: mattyt-bugzilla → default-qa
![]() |
||
Updated•18 years ago
|
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
![]() |
||
Comment 6•16 years ago
|
||
Is this bug still relevant? I have no idea what justdave is talking about in comment 0.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Assignee | ||
Updated•15 years ago
|
Component: Documentation → Extensions
Assignee | ||
Updated•15 years ago
|
Assignee: documentation → extensions
Assignee | ||
Updated•15 years ago
|
Assignee: extensions → mkanat
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•15 years ago
|
||
Documentation for the extensions system now lives entirely in the POD for Bugzilla::Extensions, so we should just point people there instead.
Target Milestone: --- → Bugzilla 3.6
Assignee | ||
Comment 10•15 years ago
|
||
This removes the existing hooks docs in favor of just pointing at the POD of Bugzilla::Extension.
Attachment #415288 -
Flags: review?(LpSolit)
![]() |
||
Comment 11•15 years ago
|
||
Comment on attachment 415288 [details] [diff] [review]
v1
r=LpSolit
Attachment #415288 -
Flags: review?(LpSolit) → review+
![]() |
||
Updated•15 years ago
|
Flags: approval+
Assignee | ||
Comment 12•15 years ago
|
||
Checking in docs/en/xml/customization.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/en/xml/customization.xml,v <-- customization.xml
new revision: 1.48; previous revision: 1.47
done
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•