Posts in GroupServer Development
What do you folks think of this as it relates to GroupServer down the road?
http://www.opensocial.org
Cheers,
Steven Clift
Audit-trails are working on GroupServer.org, and the rest of
OnlineGroups.Net, with a few caveats.
* The first is very little is that logged to the audit-trail:
setting passwords, and changing profiles is it at the moment.
* Second, I have not linked to the profile, so you have to go to
the log manually. It is "log.html", and is located under your
profile.
* Finally, I cannot break the log down on a site-by-site basis
(yet).
We will be adding different modules to the audit-trail system as
time goes by, converting some of the existing logging functions.
I have committed, and have running, the start of the Audit Trails system. The two screenshots below show a prototype view of the audit-trail log. On Monday I will make the new system live on GroupServer.Org (and the rest of OnlineGroups.Net). The audit trails system records what the users do when using GroupServer. The first screen shot below shows a log for a user (me) on my test system. As I edited my profile and changed my password GroupServer recorded the events in a log. Viewing the log allows me to see the changes that have been made to my profile. (Because it is a test, some of the entries are out of order.) A successor to this page will be the fix for Ticket 257 https://svn.iopen.net/projects/groupserver/ticket/257 Once we record the changes made to the profiles we will be able to relax the rules about who can edit profiles https://svn.iopen.net/projects/groupserver/ticket/258 The second screenshot below shows what happens when a user (me) alters the profile of another user (Mr Lem). In addition to stating what the changes were, the system also states who made the change. This can be used to identify nefarious activity, and (hopefully) allows the change to be undone. In the future we can show logs for groups, so the changes made to a group over time can be seen. The database for the audit-trails system records all the fields that Richard suggested in his earlier post [beneath the disclosure] http://groupserver.org/r/post/oLCBka5103TWEYZ8WrGCr A little voodoo is used to marshal the data from the database back into classes that can render each line item. These classes are needed because they know the specific meaning of some of the generic data that is stored in the database (specifically the "code", "instance datum" and "supplementary datum" fields). Most of the future work will be in writing the little classes that render each event type. Most of the points where we want to audit events are already marked by calls to the existing Python logger.
The following files were added to this topic:
I am working on an interface to allow users of GroupServer to add multiple
files from the Web. The use-case is as follows.
Kate wants to share some photos from the face to face meeting the
group held yesterday. As she is already logged in to the website,
she decides to use the Web interface. Going to the Meeting topic,
she finds the Add a Post interface. She writes a short message,
and adds the first photo to the post, repeating the steps for adding
the file for each of her photos.
There are two prototype interfaces that we have developed.
1. http://groupserver.org/file-upload-prototypes/attach.xml
2. http://groupserver.org/file-upload-prototypes/attach2.xml
The first is based on a paper prototype that Dan and I worked on, a picture of
which I have posted below. It uses JavaScript to pop up a file-selector field
for every file.
The second interface is based on the jQuery Multiple File Upload Plugin
http://www.fyneworks.com/jquery/multiple-file-upload/
It shows a single file-selector field, but keeps a list of files that it
displays below the file-selector field.
I have no preference for either, with each having advantages and disadvantages.
I am going to conduct some user-trials with each interface, as I have *no*
idea which is better. As ever your opinion is sought, and valued, Dear Reader.
The following file was added to this topic:
Registration on GroupServer now works with the latest version of WebKit — the
code that underlies Safari. I have made some tweaks to GroupServer so posting
using WebKit also goes, so long as files are not attached. Why files cause 413
(Request Entity Too Large) errors is a mystery at the moment, but we are making
progress.
The latest build-out of GroupServer works for me. I have uploaded the tar-ball http://groupserver.org/downloads/groupserver-1.0alpha-20080923.tar.bz2 and I will announce it tomorrow.
Steve, There are plans to rework the way the membership list is displayed: https://svn.iopen.net/projects/groupserver/ticket/272 http://groupserver.org/r/post/2wbglIk9Y93zuielw2WIWO
Are there any plans in the works to rework the way the membership list is
displayed? I recall some discussion in the past.
(Like adding some sortable elements from the profile like organisation or
country?)
Cheers,
Steven Clift
E-Democracy.Org
GroupServer now hides (redacts, obscures, censors) email address that are shown
on the web pages of public groups. Instead of the address, GroupServer writes
"<email obscured>". Email addresses shown on the web pages of private or secret
groups are shown in their full glory, and are made into "mailto:" links, so you
can send someone a message by clicking on the address. We did consider
redacting all email addresses that are shown to people who are not logged in,
and then showing them to logged in users, but this confused some people in the
past.
The redacting code itself works with the same code the displays YouTube movies
in messages on the Web, such as the one below.
The message that is stored by GroupServer is not altered. Rather, GroupServer
marks up the message before displaying it on the Web. The email messages that
are sent out by GroupServer are not touched by the email-address redacting
code, or the code that inserts YouTube movies into posts.
GroupServer has far better image handling, thanks to Steven Clift, e-Democracy.org, http://e-democracy.org/ and Advanced Business Education Limited. Images, such as the one below, are now displayed on a Web page, rather than being treated like any other file. The page shows a scaled image, so you can look at it without having to download the full image, which can be quite large. The image-page also links to the other images in a topic, so you can view, say, the evolution of an interface from design to implementation. http://groupserver.org/r/img/1101-2008-06-24T030606Z The image-page is linked to from email messages, the view of the post on the Web, and from file searches http://groupserver.org/s/index.html?t=0&f=1 The view of a post also has a thumbnail of the image to the left of the link to the image page. The images are resized by the Python Imaging Library (PIL) http://www.pythonware.com/products/pil/ Richard did the hard-yards integrating PIL with GroupServer, with what is our first component to only rely on Zope 3. The same code that resizes the images that are posted to groups also resizes the peoples profile images, so the uploading code can be far more tolerant of oddly sized profile-images.
The following file was added to this topic:
I have to concur with Mike's analysis here -- the problem is we can't
just keep adding things to interpret 'automagically' because at the end
of the day, it's an email. It isn't an environment designed to support
multiple variations of a command -- what if I want to discuss digests?
I *fully* appreciate, Steve, that you want to assist the users in
getting their job done -- but while digests are a *very* highly used
feature, consider this:
- over 1/3 of users in the MPLS group of forums.e-democracy.org have it
switched on
- how many of those 330 odd users have needed help in switching it on?
I can see 2 emails in the MPLS which look like digest related accidents
since October 2004, roughly 4 years. Add the one you had recently, and
then triple it. That would be 9 out of 330 (and in a group of 900 odd).
So less than 1% of the group has experienced digest command issues (and
actually, the issues I can see are with leaving the digest mode).
> I know GroupServer catches many partial commands, here is one more to
> add to the list - the word digest by itself.
The mailing-list interface is a command-line interface that is, and
should be, intolerant of mistakes. If you try and be cleaver, you end up
with a Do What I Mean (Dwim) interface, which is a BAD THING®. If the
people want an easy to use interface, that is tolerant of mistakes, then
we have a lovely Web page for doing what they want.
How about adding a link to turn the digest on in your footer?
mailto:<email obscured>?Subject=digest%20on
I know GroupServer catches many partial commands, here is one more to add to
the list - the word digest by itself.
I created a new version of GroupServer, and it seemed to build ok.
However
* I lost it in a reboot, so I need to check it out again
* I used my old Zope data
* I used my old PostgreSQL data
So I take its "going" status with a grain of salt!
On Mon, 2008-07-28 at 16:48 +1200, Michael JasonSmith wrote:
> /headdesk
>
> There is no a in bed.
Not the last time I looked :-)
Hi Michael,
It looks like you've misspelled "testbed" as "testbead" ...
A.
On Mon, 2008-07-28 at 16:35 +1200, Michael JasonSmith wrote:
> Ask me why I hate databases. Go on, ask me!
>
> mpj17@manu:~$ createdb -U testbed -E UTF8 testbed
> createdb: database creation failed: ERROR: database "testbed" already
exists
Ask me why I hate databases. Go on, ask me!
mpj17@manu:~$ createdb -U testbed -E UTF8 testbed
createdb: database creation failed: ERROR: database "testbed" already exists
mpj17@manu:~$ psql -U testbead testbead
psql: FATAL: database "testbead" does not exist
Richard,
I was trying to set up, or connect, to a local database on my new
(Alice's old) machine, but as *%# %$@# always, database security gets in
the way of doing anything strait forward ☺ Any suggestions?
Thanks for the advice, Richard. I will keep it in mind as I think about
where the different methods should go ☺
On Thu, 2008-07-24 at 17:15 +1200, Michael JasonSmith wrote:
> I have finished the conversion and testing of the new Can the User Post
> code, which I have been working on. I have come across some rather
> interesting properties of GroupServer mailing lists that I had not
> seen before.
>
> One is the ability to block messages from a particular email address.
> Currently, if this happens, the message is dropped, without any
> notification. Should I change it so that any post from the *user* that
> has that email address is blocked? This way the user would be
> prevented from posting via the Web, or we could also send the user a
> notification by email. Bonus question: should we still block these
> messages from unclosed groups?
Quite possibly it should be any post from a user who has that email
address is blocked. e-democracy use this feature to prevent users who
have been abusive from posting. It should definitely block these
messages from 'unclosed/open' groups too. (in that case the email
address check would still be very important).