This is the job of nitpo’s brore. Brore is report centred. For each subscribing email address, henceforth subber, it generates an XML file that has the profiles as the root and the report configuration as its child. This XML can be inspected for a member picked at random by using
ernad@
server:~$ brore -x -r
repcode
This XML code is transformed by an empro that is specified at invocation time. The current version Thomas concocted is called vacre.
ernad@
server:~$ brore -t
email -r
repcode vacre
This will create a test vacre email for the address of a randomly selected subscriber of the report repcode. There are four differences with a real run. First, the bore stops after the first email. Second, the email is sent te the address email. Third, the subject is prefixed with "DRAFT: ". Fourth, the email file for the subscriber is removed. See the end of this section for what the email file is.
If you leave the -t
email out then
the real send is performed.
You can send the draft to nep-technicians
ernad@
server:~$ brore -t nep-technicions@lists.openlib.org -r
repcode vacre
The details of the emails are specified in the “vacre” empro. The required
files are in NEP empro directory, as specificed in etc/nitpo.ini
.
ernad@
server:~/ernad/var/nep/nitpo/empros/vacre_text.xslt.xm/
for the text version of the body and
ernad@
server:~/ernad/var/nep/nitpo/empros/vacre_head.xslt.xm/
for the headers.
ernad@
server:~ crosu
nep-one nep-two nep-fri …
prints a symmetric matrix of cross subscriptions.
The mail file is an important feature of nitpo. When nitpo sends an email, it creates a mail file. When it is asked to send an email, it first checks whether the mail file is already there. When it seems the mail file, it will not proceed further. Thus, the mail file is an essential saveguard against sending users duplicate mails.
It is important to understand when the mail file is located. For a brore, it is in
ernad@
server:~/var/opt/nitpo/mail/
empro
By inspection of this path, it is clear that if we have a different empro, it is considered a duplicate email. If we have a different empro, it is considered to have a different email. Thus if you use the same empro on subsequent brore to, say, different reports, you need to clear the brore mail directory
ernad@
server: rm -r ~/var/opt/nitpo/mail/
empro
where empro is the empro used. Otherwise if you send, say empro vacro to report nep-foo, and then to report nep-bar, the readers of nep-bar that are also subscribed to nep-foo will not see it.
For the sake of this argument, assume we want to change an empro in the empros directory. Say the empro is creva, for example.
ernad@
server:~/ernad/var/nep/nitpo/empros$ cp vacre_head.xslt.xml creva_head.xslt.xml
ernad@
server:~/ernad/var/nep/nitpo/empros$ cp vacre_text.xslt.xml creva_text.xslt.xml
say, and test with to the nep-technicians with
ernad@
server:~$ brore -t
nep-technicions@lists.eponlib.org -r
repcode creva
but be aware that that creva_head.xslt.xml
creva_text.xslt.xml
inherit from creva_fras.xslt.xml
. Thus is is good practice to
ernad@
server:~/ernad/var/nep/nitpo/empros$ cp vacre_fras.xslt.xml creva_fras.xslt.xml
and change the include
locations inside the new files, with something like
ernad@
server:~/ernad/var/nep/nitpo/empros$ perl -pi -e 's/vacre/creva/' creva_*
Since 2016‒08‒07, we run Yanabino protocol for issue smoothing. The queue is public.
Thomas Krichel will, over the next few years, set up NEP_Watch, a comprehensive system that will allow to monitor what editors are doing, and who NEP as a whole performs. We already have
When a report issue is mailed, the RSS file is generated automatically, when a new report issue is produced. It can be generated manually
ernad@
server:~$ make_rss
report
At this time, the automatic generation does not work for nep-all. Therefore it has to be done manually.
You have to edit ~/ernad/etc/nep/reports/available
report.amf.xml
and
comment out the information about the editor. Change
<ernad:password>...</ernad:password> <haseditor>
with
<ernad:password>...</ernad:password> <!-- <haseditor>
and
</haseditor> </collection>
with
</haseditor> --> </collection>
If you want to make sure that the old editor can not get back in, you need to restart ernad.
ernad@
server:~$ kill_ernad nep
To put the report back, put the information for the new editor, including the correct shortid in RAS, change
<ernad:password>...</ernad:password> <!-- <haseditor>
with
<ernad:password>...</ernad:password> <haseditor>
and
</haseditor> --> </collection>
with
</haseditor> </collection>
At that point you don’t need to restart ernad.
They are