Stefano & Simone,
Hey guys. Have been doing some more review on Userstats today. I force-pushed a
couple small changes to origin/si/5453, so make sure you pull those.
I ran into an error in the stats code after pushing a commit. It was a Ming
schema validation error:
208 [Tue Mar 05 22:29:05 2013] [error] [client 127.0.0.1] File
'/var/local/env-allura/lib/python2.7/site-packages/Ming-0.3.2dev_20121101-py2.7.egg/ming/schema.py',
line 327 in _validate
209 [Tue Mar 05 22:29:05 2013] [error] [client 127.0.0.1] raise Invalid(msg,
d, None, error_dict=error_dict)
210 [Tue Mar 05 22:29:05 2013] [error] [client 127.0.0.1] Invalid:
general:[0]:messages:Not a list or tuple
211 [Tue Mar 05 22:29:05 2013] [error] [client 127.0.0.1] tickets:notdict: []
Here's the mongo doc:
{
"_id" : ObjectId("5136502261b3b44a93a7b36f"),
"lastmonth" : {
"assignedtickets" : [ ],
"commits" : [
{
"programming_languages" : [ ],
"lines" : 1,
"categories" : [ ],
"datetime" : ISODate("2013-03-05T22:28:22.341Z")
}
],
"solvedtickets" : [ ],
"messages" : [ ],
"revokedtickets" : [ ]
},
"user_id" : ObjectId("510ad21c61b3b426260e7586"),
"lastmonthlogins" : [ ],
"tot_logins_count" : 0,
"registration_date" : ISODate("2013-03-05T20:05:54.676Z"),
"general" : [
{
"tickets" : [ ],
"commits" : [
{
"lines" : 1,
"number" : 1,
"language" : null
}
],
"category" : null,
"messages" : {
"assigned" : 0,
"solved" : 0,
"totsolvingtime" : 0,
"revoked" : 0
}
}
],
"visible" : false,
"last_login" : null
}
As you can see, `general.tickets` is a list, not a dict, but it's defined as a
dict in the schema. Maybe you guys could track that down?
Tim
On Sunday, March 3, 2013 at 4:35 AM, Stefano Invernizzi wrote:
> Thanks Dave for your suggestion! I modified the bootstrap.py file, so that
> when the Users neighborhood is created, our tool for userstats is set as an
> anchored tool, and it perfectly works. However, that way, if you do not run
> the bootstrap.py, you have to manually add the tool to the anchored ones.
> And this is what happens in most cases for users who don't want to
> re-initialize the forge.
>
> I was also thinking about the setting in the .ini file to enable userstats.
> I think it doesn't make sense to disable them now that stats are
> implemented as a tool. By setting userstats.enable = false, the tool is
> still installed for users who were using it, therefore I think it's better
> to remove this option, since it would be confusing. That way, a user who
> wants to install the forge without using userstats can simply avoid
> installing the ForgeUserStats tool. I committed this change too, but if you
> think it's better to think again about it, I'm open to different proposals.
> Thanks again,
>
> Stefano
>
>
>
> 2013/3/2 Simone Gatti <[email protected]
> (mailto:[email protected])>
>
> > Dear Dave,
> > I have changed the preference page in order to meet these requests.
> > I created two new pages to collect data about contacts and availability.
> > In the preference page, over the links, it is now indicated that these
> > personal data are not compulsory.
> > In this way, the preference page will no more become so long due to data
> > about contacts and availability precedently inserted by the user, and the
> > forms not necessary are not disclosed.
> > About general personal data, I decided to leave its original form in the
> > preference page, because it has fixed size and refer to general
> > information, but I put an explicit indication that they are discretionary.
> > Please, let me know what do you think about these modifications.
> > Thanks,
> > Simone
> >
> >
> > 2013/2/18 Dave Brondsema <[email protected] (mailto:[email protected])>
> >
> > > Cory, I think Stefano is referring to user stats, which his feature
> > branch
> > > starts collecting, not user profile data (gender, location, etc).
> > >
> > > But on the topic of user profiel data, we've had a least one SourceForge
> > > user
> > > communicate to use that he/she thought the fields were required. I can
> > > see how
> > > this might be inferred since they're the first thing you see on the
> > > /auth/prefs/
> > > form. We might consider labelling those optional, or putting them on a
> > > separate
> > > page from "subscriptions" and other sections on that page.
> > >
> > > -Dave
> > >
> > >
> > >
> > > On 2/18/13 9:55 AM, Cory Johns wrote:
> > > > Stefano,
> > > >
> > > > Could a user simply not fill in the personal info fields they don't
> > wish
> > > to
> > > > share? What is the value of entering that info but then not displaying
> > >
> > > it;
> > > > to encourage users to enter it if only for our edification?
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Cory
> > > >
> > > >
> > > > On Sat, Feb 16, 2013 at 9:53 AM, Stefano Invernizzi <
> > > > [email protected] (mailto:[email protected])>
> > > > wrote:
> > > >
> > > > > Dear all,
> > > > >
> > > > > I recently pushed some new commits allowing a single user to hide his
> > or
> > > > > her personal statistics. I and Simone implemented it since some users
> > > >
> > >
> > > may
> > > > > prefer not to show this data. In that case, data is still available
> > > >
> > >
> > >
> >
> > for
> > > > > their personal use. However, if you think we should not allow users to
> > > >
> > >
> > > do
> > > > > this, we can simply put it back as it was.
> > > > > As usual, we hope to get some feedbacks from you about this, as well
> > > > >
> > > >
> > >
> > >
> >
> > as
> > > > > about the rest of submitted code.
> > > > > It would be great for us if the code could be reviewed and, if you
> > > > >
> > > >
> > >
> > > think it
> > > > > would be useful, included on the forge before we complete the thesis
> > > >
> > >
> > >
> >
> > we
> > > are
> > > > > working on.
> > > > > Thank you very much!
> > > > > Stefano
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > Dave Brondsema : [email protected] (mailto:[email protected])
> > > http://www.brondsema.net : personal
> > > http://www.splike.com : programming
> > > <><
> > >
> >
> >
>
>
>
