Should there be some kind of moderator on the site?

[yegor256]

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:16am

Should there be some kind of moderator on the site? Is there any sence to create this role? Who will keep an eye on the activity of the users? Who will be able to delete messages left by users in case if they don't satisfy the site conditions and limitations.

Please, clarify.

Source ticket: #8

[yegor256]

migrated from Trac, where originally posted by yegor256 on 16-Sep-2010 11:39am

The necessity of the ActorManager is clear and already documented in #22.

Here, in this ticket, I totally agree that we should document basic functionality of this actor. I would suggest to consider the following functionality of ActorManager:

• review a summary list of payments pending sending to ActorHelper-s
• register a new bank payment sent to ActorHelper
• CRUDL ActorHelper-s
• review a summary cashflow statement (all payments in/out)

I don't see why ActorManager may need to do anything with ActorUser-s.. No matter what are they doing - they are doing it between themselves. We shouldn't block their accounts no matter what they are discussing — their conversations are private. The only thing that can harm our system is spam — if some user will start contacting thousands of other users (with just emails provided) and netbout.com will have to send that emails, massively. In such a case we should automatically limit the user in amount of emails he/she can send. Not manually, but automatically. Here is a separate ticket for this problem: #47.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 16-Sep-2010 11:41am

Marko, the ticket is for you (to be resolved after #22, I suppose). In this ticket you will have to add listed functionality of ActorManager to the SRS. Beforehand, let's discuss it here.

The changes will have to be confirmed/commented by Yuri, the author of the ticket.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 23-Sep-2010 9:26pm

I'm thinking of defining ActorManager:

ActorManager is a ActorUser

ActorManager is a „owner and administrator of the NetBout web site, in charge of administering users, statistics, managing payment orders between ActorUser-s and ActorHelpers-, and charging ActorUser-s for using chargeable features of the NetBout“.

UC18 Where ActorManager (the admin) configures the helper.

1. admin creates helper.
2. admin reads helper-s.
3. admin updates helper-s.
4. admin deletes helper-s.
5. admin lists helper-s.

Coming back to your suggestion earlier in the ticket: please explain how admin reviews payments and registers bank payments to ActorHelper? Do you mean that SUD prepares incoming and outgoing bills, and admin has to confirm them before processing?

[yegor256]

migrated from Trac, where originally posted by yegor256 on 26-Sep-2010 2:14pm

I don't think that the manager should "delete" helpers, or do other operations you listed. The scenario would be like the following:

"Alex, a Java programmer, creates a new netbout.com account. He clicks 'Discover Helper API' and follows the instructions there. He starts to interact with netbout.com through a defined API, and in some time he gets the first incoming payment to his account. He goes to 'Payments' page and sees who paid him for the usage of his helper (who rented stages)."

"In some time John, a manager, logins to his netbout.com account and clicks 'Payouts'. He sees a list of users who have positive balances of over $200 (for example). He goes to PayPal.com, makes a payment to Alex. He clicks 'Register New Payout', enters Alex's email and $200 amount. Clicks 'Save' and Alex's balance becomes smaller for this two hundred."

That's it… About CRUDL of Helpers, I don't think we need it exactly like CRUDL. It's more like "view overall statistics and details". Let's use this wordings, it will be enough for now.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 27-Sep-2010 10:10pm

UC18 where ActorManager (the admin) enables ActorHelper (the helper):

1. "admin views list of helper-s offered".
2. "admin includes helper on the list".
3. "admin excludes helper from the list".

Other admin features discussed and described in #22. Please review.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 29-Sep-2010 2:23pm

How about this:

UC18 where ActorManager (the admin) controls ActorHelper (the helper):
 1. "The admin reviews the helper".
 2. "The admin bans the helper".

I just don't think that we need to enable any helper explicitly. Instead, we should enable all of them implicitly, by default. And sometimes we may need to disable some of them - to ban them.

Besides that, pay attention to the singular form of all verbs in flows.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 29-Sep-2010 10:22pm

OK, as we are creating a few use cases for the admin. I suggest that we review use case numbers for the admin (UC18, UC19; UC20, UC21 etc) and create new use case, let's say: where ActorManager operates: that would include in flows these use cases. In ticket #22 I would resolve admin functionalities with few use cases that would be steps in this main use case. Is that OK for you?

[yegor256]

migrated from Trac, where originally posted by yegor256 on 4-Oct-2010 12:07pm

Yes, it's a good idea. I agree.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 5-Oct-2010 9:12pm

As agreed inserted UC18, UC19, UC20 and UC21. Please check.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 11-Oct-2010 8:10pm

Looks good. Let's make UC19 properly formatted.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 12-Oct-2010 10:38pm

When I tried to insert UC19 properly:

UC19 where ActorManager (the admin) reviews payment:

 1. The admin lists user-s.
 2. The admin reads balance of the user.
 3. The admin registers payment to the user.
 UC19 3a) If balance of the user is negative:
 1. Failure "Payment cannot be registered".

I get following error warning:

    * The Wiki page field '5' is invalid: "`1. The admin lists user-s.`" - `Signature '{admin} lists user-s' is not recognized`
    * The Wiki page field '7' is invalid: "`3. The admin registers payment to the user.`" - `Signature '{admin} registers payment to {user}' is not recognized`
    * The Wiki page field '8' is invalid: "`UC19 3a) If balance of the user is negative:`" - `syntax error`
    * The Wiki page field '8' is invalid: "`UC19 3a) If balance of the user is negative:`" - `Statement ignored`
    * The Wiki page field '9' is invalid: "`1. Failure "Payment cannot be registered".`" - `Statement ignored`

Please advise what am I doing wrong. Thnx.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 24-Oct-2010 4:51pm

There are a few problems:

Signature {admin} lists user-s is not recognized. It means that the system can't find such UC anywhere in the wiki. You should define it first. If you're not ready to define it yet - quote this UC flow.

The same story with {admin} registers payment to {user}.

Here you forget to quote predicate: "balance of the user is negative".

Try this text:

UC19 where ActorManager (the admin) reviews payment:

 1. "The admin lists user-s".
 2. The admin reads balance of the user.
 3. "The admin registers payment to the user".

UC19 3a) If "balance of the user is negative":
 1. Failure "Payment cannot be registered".

Should work.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 27-Oct-2010 4:48pm

Yes now it's OK.
I understand for step 3, but for step 1 I presumed that 'list'' is one of generic use cases (CRUDL) and shouldn't be defined before... Please explain. Thanx.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 28-Oct-2010 8:55am

Yes, you're right, list is a pre-defined use case. But it should be defined as:

 1. The admin lists the ActorUser.

or

 1. The admin lists the user.

Singular form only.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 28-Oct-2010 5:33pm

Thanx for clarification.
However when I try, I get following exception:

The Wiki page field '5' is invalid: "`1. The admin lists the user.`" - `Signature '{admin} lists {user}' is not recognized` 

but when I try to insert:

The admin reads the user.

Then it is fine. Is there bug with list statement?

[yegor256]

migrated from Trac, where originally posted by yegor256 on 12-Nov-2010 2:31pm

Right, the problem is that list is not supported in RQDQL (see http://rqdql.com/rqdql.html). You should use read instead, which means exactly the same.

The reason for that is that listing is a specification of interface, not functionality.

[yegor256]

migrated from Trac, where originally posted by marko_lipo on 12-Nov-2010 10:54pm

Thanks, I updated first flow in UC19. Please check.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 15-Nov-2010 6:36am

Looks good for me. Yuri, please review and confirm/reject?

[yegor256]

migrated from Trac, where originally posted by yegor256 on 21-Feb-2011 7:33am

Yuri, any news here? Please update. If we have no answer in the next 7 days I will have to assign the ticket to someone else.

[yegor256]

migrated from Trac, where originally posted by y.vedenin on 22-Feb-2011 11:56am

I'll update the ticket till Wednesday, February 23, 2011

[yegor256]

migrated from Trac, where originally posted by y.vedenin on 24-Feb-2011 11:52pm

It's correct from my point of view. Thank you

[yegor256]

migrated from Trac, where originally posted by yegor256 on 25-Feb-2011 7:17am

Thanks, the ticket is closed.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 23-Nov-2011 9:06am

Milestone JUN11 deleted