[Phpmyadmin-devel] Error reports

[Dieter Adriaenssens]

2013/7/10 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
> On Wed, Jul 10, 2013 at 12:04 PM, Dieter Adriaenssens
> <dieter.adriaenssens at gmail.com> wrote:
>> 2013/7/9 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>> On Tue, Jul 9, 2013 at 10:53 AM, Dieter Adriaenssens
>>> <dieter.adriaenssens at gmail.com> wrote:
>>>> 2013/7/8 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>>>> On Mon, Jul 8, 2013 at 5:56 PM, Dieter Adriaenssens
>>>>> <dieter.adriaenssens at gmail.com> wrote:
>>>>>> 2013/7/8 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>>>>>> On Mon, Jul 8, 2013 at 4:33 PM, Dieter Adriaenssens
>>>>>>> <dieter.adriaenssens at gmail.com> wrote:
>>>>>>>> 2013/7/7 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>>>>>>>> On Sun, Jul 7, 2013 at 12:34 PM, Dieter Adriaenssens
>>>>>>>>> <dieter.adriaenssens at gmail.com> wrote:
>>>>>>>>>> 2013/7/5 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>>>>>>>>>>> For the server side component of the error reporting system. What are
>>>>>>>>>>> the things you want to do with the reports. like for example comments,
>>>>>>>>>>> or storing status of the reports. what other things do think you would
>>>>>>>>>>> want to do on the error reporting server.
>>>>>>>>>>>
>>>>>>>>>>> What I am thinking is commenting, changing status, searching and of
>>>>>>>>>>> course viewing all the details of the report as well as related
>>>>>>>>>>> reports.
>>>>>>>>>>>
>>>>>>>>>>> Do you want the ability to delete error reports or just mark them as
>>>>>>>>>>> resolved. and while we are on the matter what are the statuses that
>>>>>>>>>>> should exist for the error reports. I am thinking at least new and
>>>>>>>>>>> resolved but I cant think of anything else;
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I see this server as a go-between for getting error reports into our
>>>>>>>>>> existing bug-tracker [0] at Sourceforge.
>>>>>>>>>>
>>>>>>>>>> I think it should gather error reports, group them and have the
>>>>>>>>>> possibility of inserting it in the bug-tracker, no need to mimic the
>>>>>>>>>> functionality of the existing bug-tracker.
>>>>>>>>> I was going to do something like that for github issues since I am
>>>>>>>>> already using github authentication. I think that doing this for
>>>>>>>>> sourceforge issue tracker is better since it the one you actually use.
>>>>>>>>> I however cannot use sourceforge authentication because it doesn't
>>>>>>>>> provide an api to get user info so I will have to both have github and
>>>>>>>>> sourceforge connection
>>>>>>>>>>
>>>>>>>>>> F.e. when a error report comes in, the server should check if it is
>>>>>>>>>> similar (= identical) to existing reports. If it is, group them, and
>>>>>>>>>> give the new report the same status as the existing one(s).
>>>>>>>>>> If it is new, mark as to review, and/or send it to the bug-tracker.
>>>>>>>>> the problem with automatic submission is spam. I think that alot of
>>>>>>>>> error reports that are very similar but not identical would be
>>>>>>>>> submitted if automatic submission is followed. due to the different
>>>>>>>>> ways browsers send their stacktraces and handle errors in general some
>>>>>>>>> reports with the same problem appear to be different thus submitted
>>>>>>>>> individually. I think that it should be done manually when a member
>>>>>>>>> requests it.
>>>>>>>>
>>>>>>>> Unless you can make a very clever system that links reports for the
>>>>>>>> same issue, but from different browsers. ;)
>>>>>>>>
>>>>>>>> It's always a bit of a trade-off. Doing things automatically, reduces
>>>>>>>> the need for human intervention (and linking similar/identical reports
>>>>>>>> to each other can get very time consuming and cumbersome), but of
>>>>>>>> course this might result in spam, like you mention. Time will tell (or
>>>>>>>> after some tweaking of the link algorithm) if it can work
>>>>>>>> automatically.
>>>>>>>> I'd say to provide both systems (manual selection and automated linking).
>>>>>>>
>>>>>>> do you want any access control on the submission as well as linking on
>>>>>>> the reports like for example only core developers or do you not mind
>>>>>>> and want any authenticated user to do that
>>>>>>>>
>>>>>>>>> also should the bug submission in sourceforge come from the account of
>>>>>>>>> the user who submitted it (requiring a sourceforge connection) or from
>>>>>>>>> a separate account for the error reporting system which would render
>>>>>>>>> the sourceforge connection no longer required.
>>>>>>>>
>>>>>>>> Bug reports will be anonymous anyway, so they can't be linked to an
>>>>>>>> account. I'd say to use a fixed account for the error reporting
>>>>>>>> system.
>>>>>>> I think error reports need an account on sourceforg so they are not
>>>>>>> exactly anonymous but I will see what I can do
>>>>>>
>>>>>> I meant that the error reports by the pma-client are anonymous, so
>>>>>> using the account of the original reporter to create a ticket in the
>>>>>> sourceforge bug tracker is not possible.
>>>>>> Using the account of the developer who transfers the error report to
>>>>>> the bugtracker does not make that much sense, because that person is
>>>>>> not the one who experienced the error and is not the one to ask
>>>>>> questions about how to reproduce, etc.
>>>>>> So if possible, we could use an account for the error reporting
>>>>>> system, to clearly indicate that it is an anonymous/automatic bug
>>>>>> report, not one done by a person.
>>>>>>
>>>>> ok I understand now. I am actually still in contact with the support
>>>>> staff at sourceforge about how to implement the authorisation using
>>>>> their api. They seem oddly unhelpful however since the docs are not
>>>>> clear enough for me in order to implement the authentication I have no
>>>>> choice but to wait for them to answer with something a bit more
>>>>> helpful.
>>>>
>>>> Did you open a ticket at the sourceforge support site? Can you send the url?
>>> https://sourceforge.net/p/forge/site-support/4618/
>>
>> >From what I read here, I understand that you have some experience with OAuth.
>> Although the example on the sourceforge webpage uses a python library,
>> there is also one for php [0]. Did you try that one?
>>
>> I think it is best you use a library, not only because the sourceforge
>> dev team suggests it, but because readability/maintainability of the
>> code would be better. This way you don't have to write similar code
>> than what the library already does. By using an existing library the
>> maintenance and bugfixing is done by the maintainers of that library,
>> so we can benefit from it.
>>
>> What do you think?
>
> ok, with further reading it seems that they are using a different
> version from oauth than the one that I have been used to. It looks
> more complicated than usual which I think is why they wanted me to use
> the library. I didnt know there is a php class, that could smooth
> things over. I will try to use the class within my code.

Ok, good that you found this out. I guess it should get you going now.

I read that for actual accessing a project, you will need an access
token. If a test tracker needs to be set up, please let us know.

Happy coding!


> The reason I did not want to use the library is because the oauth
> authorizations that I have been used to (OAuth v2.0) didnt require
> anything other than redirects and json decode which was simple to
> implement. I actually created a component in cakephp to do the hard
> work make the code more readable. however it seems that this oauth
> implementation (OAuth v1.0) requires sending the params in the headers
> which is why a library required.
>
> I always new there were two versions of oauth but I didn't realize
> they were so different.
>>
>> [0] http://be1.php.net/manual/en/class.oauth.php
>>
>> Kind regards,
>>
>> Dieter




--
Kind regards,

Dieter Adriaenssens