[Bug 13157] support flag to indicate whether MUC subject is writable

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=13157





--- Comment #4 from Will Thompson <will.thompson at collabora.co.uk>  2009-11-09 11:00:37 PST ---
+            assert prop_flags[name] == cs.PROPERTY_FLAG_WRITE, \
+                    (name, prop_flags[name])
+        else:
+            assert prop_flags[name] == 0, (name, prop_flags[name])

Use assertEquals please.

+        assert (props['subject-contact'], cs.PROPERTY_FLAG_READ) in e.args[0]
+        assert (props['subject-timestamp'], cs.PROPERTY_FLAG_READ) in
e.args[0]

assertContains.

+    x = query.addElement(('jabber:x:data', 'x'))

ns.py

Do no servers implement muc#roominfo_subject?

Why do you join a different room for the second test in 50c1556? Surely it
should work just as well if you re-join the same room.

     for change_subject in (None, True, False):
         for send_first in (True, False):
-            test_subject(q, bus, conn, stream, change_subject, send_first)
+            for moderator in (True, False):
+                test_subject(q, bus, conn, stream, change_subject, send_first,
+                        moderator)

One problem with this is that python backtraces don't show the values of
arguments, so it's harder to see which test is failing. While 3×2×2
duplicated calls to test_subject offend a small part of me, it'd just be 10
lines rather than 5.

+  if (self->priv->self_role >=
+      (self->priv->mortals_can_change_subject
+       ? ROLE_PARTICIPANT
+       : ROLE_MODERATOR))
+    {

Maybe it'd be clearer to store ->change_subject_level, and put the explanation
into properties_disco_cb, the point where the disco reply is actually
interpreted?

Otherwise looks good, these are all nit-picks. Did you test it against real
servers?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.