1 
 2 09/21/87  forum
 3 Known errors in the current release of forum.
 4 #         Associated TR's
 5 Description
 6 
 7 134  phx20946
 8 When the unprocessed transaction is mailed, the headers that Forum adds
 9 show transaction 0 entered at midnight, Jan 1, 1901 GMT.  This is not
10 pleasing to the eye.  The mail request should be changed in such a way
11 that it is clear that what is being mailed is intended to be a forum
12 transaction.  This might be done by doing what the print request does:
13 replace the date with "*UNPROCESSED*".
14 
15 133  phx20898 phx20899
16 The enter request does not handle transactions created with "reply
17 -mtg" properly.  It tries to chain the new transaction to the specified
18 transaction in the new meeting.  If that transaction does not exist in
19 the new meeting, an error emssage is generated,; if it does exist, an
20 improper chain is created.
21 
22 132  phx20810
23 Errors from forum_$check_user are reported regardless of the use of
24 -inhibit_error in the list active request.
25 
26 It should suppress no_trans_for_user in this case.
27 
28 130  phx20627
29 V1 forum_ entries incorrectly return error_table_$badstar when they
30 really mean error_table_$nostars.
31 
32 128  phx20579
33 The apply request will operate on the current transaction instead of
34 creating an unprocessed transaction when no transaction specifier is
35 given, another non-specifier control argument to forum is given, and no
36 unprocessed transaction exists.
37 
38 parse_flags.default_to_unproc requires an unprocessed transaction to
39 exist in order to select it.
40 
41 127  phx20578
42 Transactions created with the apply request don't record the entryname
43 portion of the meeting they are being entered in.
44 passport.unprocessed_m,eeting_len is not set.
45 
46 126  phx20585
47 remove_project tries to turn of participating switches, whcih is silly,
48 since it only has a project name.  Also, remove_participant will try
49 and turn off participating switches if the user is not chairman biut
50 has 'm' permission.  This is OK, but the message that comes out should
51 be made clear that it is a warning, and that the user's access was
52 deleted.
53 
54 124  phx20563
55 The chairman request uses a 22 character string to hold the chairman
56 user/project ids.  This is inadequate and can result in truncation.
57 
58 123  phx20549
59 The -user control argument to lsu should be incompatible wiht -idl,
60 -odl, and -ondl, probable -asc and -desc too.
61 
62 The -project controla rgument should be treated as a filter, not as an
63 absolute judge of acceptance.
64 
65 120  phx20314
66 The sort_by_chain operation does not retain chaining information,
67 causing incorrect transaaction trailers to be printed.  The routine
68 should be fixed to use information already gathered by trans_specs
69 anyway.
70 
71 92  phx18764
72 The expunge request creates a copy of the meeting in the process
73 directory.  If there is insufficient quota in the process directory,
74 the expunge will fail.
75 
76 88  phx17955
77 Notifications are not sent when a user with privileges enabled enters a
78 transaction in a meeting at a lower access class.
79 
80 60  phx17354
81 init_notifications fails if the AS process is running above system_high
82 as defined in installation_parms.
83 
84 A fix for this problem is discussed in the TR.
85 
86 53  phx16749
87 V2 forum doesn't recognize ".control" as a valid meeting suffix.  This
88 will be fixed as time permits, however compatibility with V1 forum at
89 this level is not really planned.
90 
91 52  phx17169
92 Other interactive instantiations of a user should be notified when a
93 transaction is entered into a meeting, even if by the same userid (ie.
94 when an absentee enters transactions).