View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001042Main CAcert Websitesource codepublic2012-05-31 03:502015-10-20 21:17
ReporterINOPIAE Assigned ToEva  
PrioritynormalSeverityminorReproducibilityhave not tried
Status needs review & testingResolutionopen 
Summary0001042: Review the code regarding the new point calculation
DescriptionCheck if the point calculation is adjusted according to the new points calculation.
TagsNo tags attached.
Reviewed by
Test Instructionshttps://bugs.cacert.org/view.php?id=1042#c5383

Relationships

related to 0001043 needs review & testingEva Review the code regarding the new point calculation in ./stamp/common.php 
related to 0001044 needs review & testingEva Review the code regarding the new point calculation in ./scripts/addpoints.php 
related to 0001045 closedNEOatNHNG Review the code regarding the new point calculation in ./scripts/cron/removedead.php 
related to 0001046 needs review & testingEva Review the code regarding the new point calculation in ./scripts/cron/updatesort.php 
related to 0001047 needs review & testingEva Review the code regarding the new point calculation in ./www/index.php 
related to 0001048 needs review & testingEva Review the code regarding the new point calculation in ./www/api/ccsr.php 
related to 0001049 needs review & testingBenBE Review the code regarding the new point calculation in ./www/api/cemails.php 
related to 0001050 needs review & testingBenBE Review the code regarding the new point calculation in ./www/wot.php 
related to 0001051 needs review & testingBenBE Review the code regarding the new point calculation in ./www/stats.php 
related to 0001052 needs review & testingEva Review the code regarding the new point calculation in ./includes/loggedin.php 
related to 0001053 needs review & testingEva Review the code regarding the new point calculation in ./includes/account.php 
related to 0001054 needs review & testingTed Review the code regarding the new point calculation in ./includes/general.php 
related to 0001055 needs review & testingEva Review the code regarding the new point calculation in ./includes/lib/account.php 
related to 0001056 needs review & testingEva Review the code regarding the new point calculation in ./pages/account/43.php 
related to 0001057 needs review & testingEva Review the code regarding the new point calculation in ./pages/account/52.php 
related to 0001058 needs review & testingEva Review the code regarding the new point calculation in ./pages/account/55.php 
related to 0001059 needs review & testingEva Review the code regarding the new point calculation in ./pages/wot/9.php 
related to 0001060 needs review & testingEva Review the code regarding the new point calculation in ./pages/wot/1.php 
related to 0001061 needs review & testingEva Review the code regarding the new point calculation in ./CommModule/usbclient.pl 
related to 0001062 needs review & testingEva Review the code regarding the new point calculation in ./CommModule/client.pl 
related to 0001063 closed Review the code regarding the new point calculation in ./scripts/nearest.php 
related to 0001064 closedNEOatNHNG Review the code regarding the new point calculation in ./scripts/areacheck.php 
related to 0000827 closedegal Tverify points to be deprecated 
related to 0001355 needs reviewBenBE Remove Tverify 
parent of 0001316 needs review & testingBenBE Adjust the old point calculation while revoking an assurance 
related to 0001134 closedNEOatNHNG Delete the board flag thourougly in all parts of our software 
Not all the children of this issue are yet resolved or closed.

Activities

felixd

2015-05-05 21:59

updater   ~0005383

Last edited: 2015-06-02 20:03

 Test Instructions:

to create new test accounts please look at https://wiki.cacert.org/Software/TestTeam/WelcomePack/02-CreateAccounts as the test management server shows some strage behaviours with the batch assurances and the adminsitrative increase.

General fix in points calculation:
Experience points are not counted as "points" where this is appropriate (e.g. checking if someone is an assurer).
This situation might arise as the following.
An user receives 100 points and passes CATS.
An user assures some people receiving experience points.
An assurance to that user (one of the 100 points) gets deleted, so that his assurance + experience points are still over 100, e.g.:
90 assurance points + 10 experience points = 100 points.

the user now may for example not assure others.

Or a user with 40 assurance + 10 experience points may not include his name in certificates.


Check that the following actions still work:
- Create a certificate (client or server) and check that it is issued with the correct validity period (with respect to more or less than 50 points).
- the correct number of max assurance points is displayed when assuring someone (checking that two values are correct should suffice)
- the assurer flag gets set and unset correctly
- the 3 texts on account/55 (your trainings): "are assurer" "have 100 points but need test", "have passed challange but need 100 points" are displayed correctly. (100 points are only 100 assurance points, please test that experience points do not count here)
- only 'real' (see 'General fix') assurers are listed in wot/1
- only listed 'real' assurers may be sent contact mails through wot/9
- stats work calculate the points (now) correctly (see 'General fix')
- "api/ccsr.php" and "api/cemails.php" are removed.
- the mail sent to assurees is correct:
   no 'rounding down' anymore
   you have now 'x' assurance points in total (with x also beeing > 100)


A complete check of all other features might be appropriate as well.

If you delete an assurance in the SE console please make sure that you delete the corresponding "Expierence Points" assurance aswell. Otherwise the calculation of the Total assuracance points in the SE console will not be correct.

INOPIAE

2015-05-12 19:50

updater   ~0005389

Last edited: 2015-05-12 19:54

 Created account.
Added 49 assurance points via test mgr
Created client cert:
no class 3 selection => ok
duration 3 days => ok
become assurer

added assurance with 35 points via normal assurance
mail 35 points added you have now 35 points. => false should be 84 points
my points wot/10 shows 49 point => false should be 84 points
my points wot/15 shows 84 points => ok
SE interface shows 49 points => false should be 84 points
SE points wot/10 shows 49 points => false should be 84 points
SE points wot/15 shows 84 points => ok
created client cert:
class 3 enabled => ok
duration 3days => false should be 1 week
become assurer

stop testing until errors are fixed

Eva

2015-05-19 19:37

updater   ~0005396

I do not see that the big bunsh of entries are testable in a sensible manner so that it is documented in an understandable way. Protests against this combination of so many things into one bug-entry, especially when it is about as substancial things as assurances (and a lot of other things)

Please find another way how this tests should be done.

BenBE

2015-05-19 20:01

updater   ~0005397

The way these tests are handled is the only sensible one even if the bugs were split originally for review purposes. Re-combining the bugs was done on purpose as duplicating tests would have been much more trouble in regards to documentation as changes in one dependent bug/patch might introduce changes on a completely different location. Also: You were one of the people complaining to not want to test the whole system (range of effects single changes in this patch set) for every patch (result of not combining the test) in the patch set.

Furthermore: If we were not to test this change at all we wouldn't get any change of it online. There were similar patches like this in the past and while testing took some time to review the whole system (and yes, with the current software that is sometimes the only way) it has been managed.

Nobody forces you to test this patch. If you feel like you can't cope: Don't do it.

Testing is voluntary for the testers, yet compulsory for getting a change set into production. It's much preferable if the testers are confident in what they do instead of complaining.

This said: Tests can usually be split at the boundaries of the bugs while keeping in mind the features from other bugs they depend on. This can be roughly seen from the way the merges were performed while combining the change sets for this issue (some issues are merged explicitly into foreign branches despite them being merged into this bug anyway).

Eva

2015-05-19 20:16

updater   ~0005398

If there is such a big bug and big patch there should be at least one (if not multiple) descirptions of what is done on a "use case" or comparable level. Something that describes for someone not deeply into the software what this is all about. This is even the case if it should not lead to any visible changes.

Currently there are only quite random thing listed, that seem to belong to different original bug entries.

I do not complain about that "everything" needs to be tested. That is something that needs to be done, now and again.

But this "everything" cannot be actually everything as one would need indefinite time to do this. So one has to focus on something. To be able to do so one has to do this with the specific kind of change in mind. It is definitly not enough to only concentrate on those points that the coder has touched, as our tests are specificly done to find side effect of those changes, especially those that the coder did not have in mind.

So instead of more or less giving a list of changes test-instructions and/or bug descriptions should be done on a different level.

Also most big features can normally be split to smaller ones. It would be good to be able to focus on those with the tests, even if one would have to do the complete test multiple times.

INOPIAE

2015-05-27 05:37

updater   ~0005401

Last edited: 2015-06-02 20:30

 I created a new account.
Via TMS gave 100 AP and CATS
Started assuring
With the 6th assurance the max points stayed with 10 points.
=> fail

felixd

2015-05-27 08:40

updater   ~0005402

We tested and live-fixed that bug on another testsystem. The resulting commit is here:

https://github.com/yellowant/cacert-devel/commits/bug-1042

INOPIAE

2015-06-02 20:37

updater   ~0005403

Last edited: 2015-06-02 20:39

 I created a new account.
Via TMS gave 100 AP and CATS
Started assuring
The system shows for each successful 5 assurance the increase of the max points correct. => ok
After 25th assurance the max. point is on 35 points max. => ok
I deleted one assurance and the corresponding "Expierence Points" assuracne.
The the totals are correct. => ok
The max. points droped to 30 points max. => ok.
Adding a new assurance come back to 35 points max. again. => ok

janmaco

2015-06-06 10:52

updater   ~0005404

Generated a user and gave him 100 AP and CATS.
Generated 24 users and let the user assure each of them.
Maximum points to assure increases in the correct interval => OK
User got 50 EP and is now able to assure up to 35 AP => OK
Removed one assurance, the user made -> The user can only assure 30 AP => OK
Removed one assurance the user got -> The user isn't able to assure anyone AFTER RELOGIN (this is kind
 of "fatal", but is not part of this bug) => OK
Reassured user -> user is able again to assure up to 30 points => OK
Assured another user -> got 2 EP -> user has 150 points and is able to assure 35 points => OK

Revoked all assurances the user got (still has 50 EP (_NOT_ AP)) -> generated client cert including name
 using SPKAC -> name included => FAIL/WARN: Discuss which behavior is correct...
In the same scenario, only short validity periods are possible (so at least the signer seems to work
 correctly here) => OK

Mails to assurees displayed correctly => OK

An Assurer who isn't assurer anymore by revoked assurances the user got isn't listed as assurer to others
 => OK
An Assurer who isn't assurer anymore by revoked assurances the user got (but still has 50 AP and 50 EP
) isn't listed as assurer to others => OK
An Assurer who isn't assurer anymore by revoked assurances the user got (but still has 50 AP and 50 EP
) isn't listed as assurer to others and can't be mailed by changing the id in the GET-param, but the
 contactform with the name appears (not this bug) => OK

api/cemails.php isn't present => OK
api/ccsr.php isn't present => OK

=> (OK, may need discussion)

felixd

2015-06-06 16:38

updater   ~0005405

Last edited: 2015-06-06 16:39

 I patched the code that calculates the 'overall points' (459292a) to only include exp. points, if there are 100 assurance points.

this should fix "name included => FAIL/WARN: Discuss which behavior is correct"

lucasw

2015-06-06 17:20

reporter   ~0005406

Last edited: 2015-06-10 13:56

 I performed a test.

- Created user. Gave user three full assurances (100 AP).
  Gave user CATS. Assured 26 people.
  This was done by Felix using his script.
  That script always attempted to give 35 points;
  the software correctly truncated this to 5x10, 5x15, 5x20, 5x25, 5x30 and finally 1x35 points.
- Enabled the “Support Engineer” flag to be able to delete assurances.
- Revoked two assurances by the user. Now user has 48 EP.
- Attempted to re-assure the first of those users. Entered 35 AP.
  System displayed a maximum of 30 AP, and only 30 AP were granted.
- Attempted to re-assure the second of those users. Entered 35 AP.
  System displayed a maximum of 35 AP, and all 35 AP were granted.
- Created client cert, valid for 1 month.
- Revoked two of the assurances to the user. 87 points total, but only 35 AP.
- Created client cert, only valid for 3 days.
- Attempted to assure someone. Got error: User passed Assurer Challenge, but still needs 100 AP.
- Gave one more assurance to user and revoked one of the “Administrative increases” (2 EP from one of the assurances).
  120 points total, but only 70 AP.
- Attempted to assure someone. Entered 35 AP.
  System displayed a maximum of 0 AP, and only 0 AP were granted.
  (Note the difference to above, where user wasn’t able to assure at all.)
- Set my location, searched for assurers around that location.
  User was not listed.
- Logged out and logged in again.
- Attempted to assure someone. Menu item not present, but page reachable by entering URL manually.
  Entered 35 AP. System displayed a maximum of 0 AP, and only 0 AP were granted.
- felixd pushed two patches: Commits 99265c8 and 0adfd09.
- Gave two more assurances to user, revoked one of them.
  150 points total, 105 AP.
- Attempted to assure someone. Entered 35 AP.
  System displayed a maximum of 35 AP, and 35 AP were granted.
- Revoked one assurance to the user.
  120 points total, but only 70 AP.
- Accidentally logged out. Logged in again.
- Attempted to assure someone. Menu item not present.
  When entering URL manually, got error: User passed Assurer Challenge, but still needs 100 AP.
- Gave two more assurances to user, revoked one of them.
  150 points total, 105 AP.
- Began attempting to assure someone. Entered 35 AP.
  System displayed a maximum of 35 AP.
- Revoked one assurance to the user.
  120 points total, but only 70 AP.
- Attempted to complete the started assurance (see above; separate browser tab).
  Got error: User passed Assurer Challenge, but still needs 100 AP.
  The menu item is also hidden.

SUMMARY: With AP<100, but AP+EP>=100, the system used to allow issuing 0-point assurances (though after a relogin, the menu item was hidden).
This was fixed by felixd.
I am not aware of any further bugs related to this issue.

2015-06-10T15:53+0200 Edit: Felix asked me to check the additional commits 5ab9a73 and eadb033.

- Opened System Admin panel. Offers Revoke link. OK.
- Opened Account History panel. Shows revocation info. OK.
- Opened My Points panel. Does not show revocation info (neither old nor new calculation). OK.
- Removed Support Engineer flag from account. Logged out and logged in again.
- System Admin menu not present. Attempted to access it via URL. Got error. OK.
- Opened Account History panel. Shows revocation info. OK.
- Opened My Points panel. Does not show revocation info (neither old nor new calculation). OK.

Seeing as the commits only touched output code, I see no need to repeat the original test.

(Also available at https://lucaswerkmeister.de/cacert-1042.md, signed at https://lucaswerkmeister.de/cacert-1042.md.gpg)

INOPIAE

2015-06-09 20:40

updater   ~0005407

Last edited: 2015-06-09 21:26

 Create new account 1042.a@acme.com
Added 49 points via TMS
Created client cert, duration 3 days => ok
Created server cert, duration 3 days => ok
Added 1 AP, total 50 AP
Created client cert, duration 1 months => ok
Created server cert, duration 1 months => ok
GPG certs available => ok
Revoked the assurance 1 AP, total 49 AP
Certificates were not revoked, is this needed here?
Created client cert, duration 3 days => ok
Created server cert, duration 3 days => ok
GPG certs not vailable => ok
GPG.php?id=0 and id=2 redirected to account.php => ok
Added 35 AP and 15 AP, total 99 AP
Created client cert, duration 1 months => ok
Created server cert, duration 1 months => ok
GPG certs available => ok
Added code signing flag to account (should not be granted)
Client cert does not show the code signing option => ok
Added 1 AP, total 100 AP
Client cert does not show the code signing option => ok
Cannot assure => ok
Added CATS
Client cert shows the code signing option => ok
Cannot assure. After relogin can assure => ok
Assured 1 user with 10 points => ok
Revoked 1 AP, total 99 AP
Assure someone gives warning an no assurer option => ok
direct call of wot.php?id=5 shows same behaviour => ok
Client cert does not show code signing option => ok
In SE console Assurance Points shows 99 AP => ok
Added 1 AP, total 100
user is able to assure again => ok
Client cert shows the code signing option => ok
Added 5 more assurance 12 EP in total
Set location and allow my listing
User listed in Find Assurer with 15 AP => ok
Revoked 1 AP assurance, 99 AP in total
Assure someone gives warning an no assurer option => ok
direct call of wot.php?id=5 shows same behaviour => ok
Client cert does not show code signing option => ok
User not listed in Find Assurer => ok
Added 1 AP, total 100
user is able to assure again with 15 AP => ok
Client cert shows the code signing option => ok

mails to the assuree always show the desired behaviour => ok

=> ok

Eva

2015-07-12 20:51

updater   ~0005418

Arbitration notice from Arbitrator of a20140126.1:
This bug should not go productive until a question raised in the case related to this bug is answered and a possible issue is clarified.

Hopefully no issue will be detected and the block can be removed, soon.

Ted

2015-10-15 21:21

administrator   ~0005469

Last edited: 2015-10-15 21:24

 Commit 345eb2e771f6475e243f406fe37c41933a520c11 vs. eadb03311454c5dc6234c45a76eb5943612568e0?

All line numbers reference the files from eadb03311454c5dc6234c45a76eb5943612568e0?.


==============
|REVIEW FAILS|
==============

includes/notary.inc.php
=======================


function revoke_assurance and recalculate_old_assurance_points, lines 2213 and 2232:
The LIMIT clause should be removed, or a comment added why it is needed.

The LIMIT clause is not a standard SQL clause and redundant to the primary key constraint here. If there are
multiple primary keys in this table we're in deep trouble, regardless whether one or all rows are updated...


www/wot.php
===========

Line 417:

if(($drow_points + $awarded) >= 100 && $drow_points < 0 && !is_assurer(intval($_SESSION['_config']['notarise']['id'])) )

Am i completely stupid? Shouldn't this read "&& $drow_points > 0"??? As I see it, $drow_points will never be below zero!
Correct this, or explain me that I'm wrong...

==============
|Minor issues|
==============

CommModule/client.pl
====================

Line 444:
- Why is the expired data field ignored here? It was ignored before, but as I see it expired notaries should not be counted here.


includes/lib/account.php
========================
Lines 52 and 85:

Why "AND `n`.`from` != `n`.`to`" clause? It should not hurt, but how can "from" be equal to "to"?

pages/account/55.php
====================
Why "AND `n`.`from` != `n`.`to`" clause, see above?


includes/lib/general.php
========================

Lines 146ff:

Old code was explicitly false when handling temporary points ("AND `n`.`expire` < now()").
New code does not handle temporary points at all?


includes/notary.inc.php
=======================

Function get_received_experience_points, line 349:
Line "$res = get_received_assurances(intval($userid));" should be below the comment, since it is part of the logic that should be removed in the future


scripts/cron/refresh_stats.php
==============================
In several statements "expire" is not regarded.


pages/wot/1.php
===============
Statement Line 92ff, extremly ugly, see mail.


=============
|Other Notes|
=============

CommModule/readme.txt
=====================
OK


CommModule/usbclient.pl
=======================
(deleted)

According to mail from Benny the module is neither used nor supported anymore.


cgi-bin/siteseal.cgi
====================
(deleted)

According to mail from Benny, the Site Seal 7 Site Stamp feature has been deactivated for quite some time.


includes/account.php
====================
OK

includes/general.php
====================
OK



includes/loggedin.php
=====================
OK


pages/account/43.php
====================
OK


pages/wot/9.php
===============
OK. Quite ugly, but not worse than before.



scripts/cron/updatesort.php
===========================
OK

stamp/*
=======

deleted, see siteseal.cgi

www/api/ccsr.php
================

OK. API for requesting certificates removed.

www/api/cemails.php
===================

OK. API for querying own account information removed.

www/index.php
=============

OK

BenBE

2015-10-18 15:08

updater   ~0005474

Regarding the review fails:

- For the first issue in includes/notary.inc.php:
If you prefer SQL-standard compliant versions you can leave this clause out. It was primarily added for defense in depth if some conditional was screwed.

- For the second issue in www/wot.php line 417:
The conditional is wrong and despite my first look at it and some more backtracing it should read ($drow_points < 100) or to quote the full line:

if(($drow_points + $awarded) >= 100 && ($drow_points < 100) && !is_assurer(intval($_SESSION['_config']['notarise']['id'])) )

Thus, given my backtracing was correct, $drow_points at that location holds the old number of points issued to the user and the condition will succeed when the user first has 100 or more points, while having fewer previously.

- CommModule/client.pl:
The handling of expired points is indeed missing and should be added to be consistent with the WebDB software. Even though there should be no affected records (no current temporary increases, no such programs defined, old records cleaned by Cronjob) it's better to be safe here.

- include/lib/general.php:
Have to revisit the code changes there to say more on this change.

- refresh_stats.php
Intentionally ignored (as with deleted entries) to make stats more self-consistent.

@Ted: You can perform the changes required; I'll revisit the modified locations for my review afterwards.

felixd

2015-10-19 23:02

updater   ~0005475

Last edited: 2015-10-20 19:03

 Regarding www/wot.php line 417:

This is indeed unclear when which part has to be sent.
I changed the conditionals to have the following meaning:
- include "you have reached 50 points..." when the assuree now has more than 50 points and hadn't before
- include "You can now become an assurer" when the assuree now has more than 100 points and hadn't before and is no assurer yet.

Regarding the LIMIT clauses:
As BenBE said, we are already heavily depending on MySQL Syntax (evey time there is a backtick quote) and using mysql-specific functions (mysql_query).
The Limit clause helps to state the programmer's intent that only one line is to be modified and thereby beneficial to make the code understandable.

As to "expires":
As BenBE already told there should be no expired records.
Handling expired records consistently would include adding this extra clause in every SQL-query touched.
As there should not be expired records, I think, that we should not try to add extra complexity in so many different locations.

The "`n`.`from` != `n`.`to`"-clauses:
All "Administrative Increase" points should be of the structure that `from` = `to`.
We want to select only "regular" assurances and adding `from` != `to` keeps us safe against data entries similar to "Administrative Increase"es.

I added a commit that changes the bad conditional:
https://github.com/yellowant/cacert-devel/commits/bug-1042

I'd say all other things are fine.

Eva

2015-10-20 06:01

updater   ~0005476

Arbitration note from the Arbitrator of a20140126.1 - as stated above that case is blocking this bug. The blocking element for that case is - since over a quarter of a year(!) - the review and test for an appropriate SQL query to be able to inform affected useres about the change to their accounts/assurances (or the display of those).

As this mail has to be sent weeks prior to the installation of this bug, handle the requested SQL query with priority. There is an Arbitration request to do this for months.

The requirements about the query are quite clear.

I do not care how the query looks like, as long as the requirements are met. The current proposal from my side is:

1st:
---
SELECT count(*)
FROM `notary` AS `n`
WHERE `n`.`from` = `n`.`to`
AND `n`.`method` LIKE 'Administrative%'
AND ( `n`.`awarded` > 2 OR `n`.`points` > 2 )
AND `n`.`deleted` != 0;
---

2nd:
---
SELECT count(*)
FROM `notary` AS `n`
WHERE `n`.`from` != `n`.`to`
AND `n`.`method` LIKE 'Administrative%'
AND `n`.`deleted` != 0;

To be able to answer a question in that case, and to get an idea of the severity of the issue (and if there is a need to inform members, at all).

You may also provide another version, that also provides the Fname,
Lname and email of the assuree, for accounts that are not deleted and
any other parts which may be required to inform a member via a
mail-script, if you regard it to be likely that there are affected members.

As already stated, you may also provide different queries, that match the requirements (or update the above to fix syntactic or comparable issues).

If you think that you need to know if there are recent entries of higher
administrative increases on the production system you may add a grouping
for the years of the assurances. You may also provide a version for a counter per kind of assurances if you (Benny as claimant) regard it to be relevant to check this, by adjusting the "like" or whatever is needed, or a grouping for "points/awarded", or a counter per value.

However, my requirement is, that at the time being only counts and no specific values of affected accounts are provided. (Beside of possibly a version with name and email to contact affected users, probably via automated mail-script.)

The description about what the queries should provide by Benny:
"Regarding the first statement the reason is to see if there are any
administrative increases in the database where more than 2 points were
allocated to the columns points or awarded. There should be no such
records available as the administrative increase by default should be at
most 2 points.

The second statement is to see if there are any administrative increases
in the database where the person issuing points (`from`) is not the same
as receiving them (`to`). There should be no such records available as
the administrative increase as present in the software is always set to
make `from` equals `to`."



I also place a warning against Benny here, if this is not covered, soon. If you continue to insist on queries that will provide data that was not allowed by the Arbitrator, or if you continue to reject the decision of the Arbitrator of if you continue to delay the creation and review of this query, there will be consequences. You were warned before, multiple times. There were meetings about this. There were agreements, which seem to be waved by you, already.

Also: The review of the query is a lot easier than the review of this bug, so I definitly cannot understand why it is not done.

There was already a deadline for 2015-08-26 00:00 UTC, which was not met. Then there was a meeting where you promised to cover this, ASAP. Then I got a mail that this would be covered ASAP but not within the next weeks, because you decided that you would cover Arbitration requests in an order of your likeing (arbitration number). Then there were answers to other cases, with a higher number. But the only answers I got for this case were "rejected" because you insist that more informations should be gathered, at 2015-07-12.

Eva

2015-10-20 06:09

updater   ~0005477

Arbitration notice of Arbitrator of a20141024.1:
Please remove the assignement to Dirk. He is currently blocked to act as a Software Assessor, because of a decision in that case, to prevent conflicts with another role that he currently holds temporarly. The according part of the ruling is:

"Dirk is suspended from active regular Software Assessor work. He may
be active in emergency situations. (Situations where a necessary bug
cannot be installed in an acceptable amount of time, without his review.)"

The ruling can be found at: https://wiki.cacert.org/Arbitrations/a20141024.1
It was given at 2015-09-07.

Please also remove any other current assignement to Dirk for reviewing bugs that do not match the requirement of that ruling.

As this bug is currently blocked, based on an Arbitration decisions, the installation of this bug is currently not depending on a review by him.

Eva

2015-10-20 21:17

updater   ~0005478

Follow up notice: Any SA should be quite careful to place review assignments on people who are not SAs. Please think about what you are doing. For once it does not make sense but it also makes it harder to get those bugs found by the people who can review those bugs. But even more any SA should prevent the idea that they are trying to get bugs reviewed by persons who are no SAs by intention. - Even if the no process would be tried, it probably should not be done by assignement. And those people should at least be familiar with PHP.

To assign bugs for review to people who are not trained or at least familiar with the software, could be understood as a security issue - done by intention.

Please be a little bit more careful what you do.

Issue History

Date Modified Username Field Change
2012-05-31 03:50 INOPIAE New Issue
2012-05-31 03:50 INOPIAE Assigned To => egal
2012-12-27 06:11 Werner Dworak Relationship added related to 0001043
2012-12-27 06:11 Werner Dworak Relationship added related to 0001044
2012-12-27 06:12 Werner Dworak Relationship added related to 0001045
2012-12-27 06:12 Werner Dworak Relationship added related to 0001046
2012-12-27 06:13 Werner Dworak Relationship added related to 0001047
2012-12-27 06:14 Werner Dworak Relationship added related to 0001048
2012-12-27 06:15 Werner Dworak Relationship added related to 0001049
2012-12-27 06:15 Werner Dworak Relationship added related to 0001050
2012-12-27 06:16 Werner Dworak Relationship added related to 0001051
2012-12-27 06:16 Werner Dworak Relationship added related to 0001052
2012-12-27 06:17 Werner Dworak Relationship added related to 0001053
2012-12-27 06:20 Werner Dworak Relationship added related to 0001054
2012-12-27 06:21 Werner Dworak Relationship added related to 0001055
2012-12-27 06:21 Werner Dworak Relationship added related to 0001056
2012-12-27 06:22 Werner Dworak Relationship added related to 0001057
2012-12-27 06:22 Werner Dworak Relationship added related to 0001058
2012-12-27 06:23 Werner Dworak Relationship added related to 0001059
2012-12-27 06:24 Werner Dworak Relationship added related to 0001060
2012-12-27 06:24 Werner Dworak Relationship added related to 0001061
2012-12-27 06:25 Werner Dworak Relationship added related to 0001062
2012-12-27 06:26 Werner Dworak Relationship added related to 0001063
2012-12-27 06:26 Werner Dworak Relationship added related to 0001064
2012-12-27 06:34 Werner Dworak Relationship added related to 0000827
2013-01-09 04:10 Werner Dworak Relationship added related to 0001134
2015-01-04 10:50 BenBE Status new => needs work
2015-01-06 20:25 INOPIAE Summary Review the code regarding the new point calculation in ./scripts/addpoints.php => Review the code regarding the new point calculation
2015-01-20 21:03 felixd Status needs work => fix available
2015-01-20 21:04 felixd Status fix available => needs work
2015-04-15 23:17 felixd Relationship added related to 0001355
2015-05-05 21:59 felixd Note Added: 0005383
2015-05-05 21:59 felixd Test Instructions => https://bugs.cacert.org/view.php?id=1042#c5383
2015-05-05 22:00 felixd Status needs work => needs review & testing
2015-05-12 19:15 felixd Note Edited: 0005383
2015-05-12 19:50 INOPIAE Note Added: 0005389
2015-05-12 19:51 INOPIAE Note Edited: 0005389
2015-05-12 19:52 INOPIAE Note Edited: 0005389
2015-05-12 19:54 INOPIAE Note Edited: 0005389
2015-05-12 20:31 BenBE Relationship added parent of 0001316
2015-05-19 19:37 Eva Note Added: 0005396
2015-05-19 20:01 BenBE Note Added: 0005397
2015-05-19 20:16 Eva Note Added: 0005398
2015-05-26 20:08 INOPIAE Note Edited: 0005383
2015-05-27 05:37 INOPIAE Note Added: 0005401
2015-05-27 08:40 felixd Note Added: 0005402
2015-06-02 20:01 INOPIAE Note Edited: 0005383
2015-06-02 20:01 INOPIAE Note Edited: 0005383
2015-06-02 20:03 INOPIAE Note Edited: 0005383
2015-06-02 20:30 INOPIAE Note Edited: 0005401
2015-06-02 20:37 INOPIAE Note Added: 0005403
2015-06-02 20:39 INOPIAE Note Edited: 0005403
2015-06-06 10:52 janmaco Note Added: 0005404
2015-06-06 16:38 felixd Note Added: 0005405
2015-06-06 16:39 felixd Note Edited: 0005405
2015-06-06 17:20 lucasw Note Added: 0005406
2015-06-09 20:40 INOPIAE Note Added: 0005407
2015-06-09 20:41 INOPIAE Note Edited: 0005407
2015-06-09 20:50 INOPIAE Note Edited: 0005407
2015-06-09 21:00 INOPIAE Note Edited: 0005407
2015-06-09 21:02 INOPIAE Note Edited: 0005407
2015-06-09 21:02 INOPIAE Note Edited: 0005407
2015-06-09 21:26 INOPIAE Note Edited: 0005407
2015-06-10 13:56 lucasw Note Edited: 0005406
2015-06-10 13:56 lucasw Note Edited: 0005406
2015-07-12 20:51 Eva Note Added: 0005418
2015-10-15 21:21 Ted Note Added: 0005469
2015-10-15 21:24 Ted Note Edited: 0005469
2015-10-18 15:08 BenBE Note Added: 0005474
2015-10-19 23:02 felixd Note Added: 0005475
2015-10-20 06:01 Eva Note Added: 0005476
2015-10-20 06:09 Eva Note Added: 0005477
2015-10-20 17:14 BenBE Assigned To egal => Eva
2015-10-20 19:03 felixd Note Edited: 0005475
2015-10-20 21:17 Eva Note Added: 0005478