A yellow violation should only be shown to the person responsible for that violation, rather than to all persons in that role. about rap HOT 14 OPEN

This implies a whole new way of handling roles. Any suggestions?

from rap.

No. But I realized that this is a necessary feature for RAP3.

from rap.

For RAP3, maybe we can change the corresponding rules to use _SESSION, such that there is only a violation if the person corresponding to the current session is responsible.

Note that this means that _SESSION should be allowed to occur in rules too (it currently is allowed in the type-checker, but I was going to disallow that).

In general, this problem becomes a bit easier to think about when yellow violations are seen as special cases of interfaces, rather than special cases of rules.

from rap.

In general, this problem becomes a bit easier to think about when yellow violations are seen as special cases of interfaces, rather than special cases of rules

I fully agree with @sjcjoosten. @RieksJ and I already experienced in our prototyping cases that that "yellow" rule expressions can be used to create todo lists in interfaces. There it is easy to add the session atom to your expression to have the required output.

A common pattern, replace:

RULE xyz : r |- s
ROLE todo MAINTAINS xyz

with

INTERFACE xyz FOR todo : r-s

from rap.

When we've merged the VIOLATIONs and INTERFACEs this issue will also be solved I guess.

from rap.

Per definition, yellow violations are shown to the ROLE(s) that must work with them. If you have other violations showing up, then you may have defined the wrong rule. One way of solving this that does not require waiting for the solution of @sjcjoosten and @Michiel-s would be to add a property-term (i.e. a construct (I /\ expression) somewhere in the left side expression of the rule that indicates the user's relation to the violation you have. If @stefjoosten provides an example of a rule, then I'll show how to fix it.

from rap.

You guys are making me Think Hard... 😥 I don't understand Sebastiaan's remark. What does it mean that a violation is an interface? Michiel already understands, but I need some help. (Thumbs up, Michiel 😁)

from rap.

Rieks' s solution sounds like what Han came up with in a telephone conversation. I assume this solution is Ampersand-only. That is: it does not require PHP or Haskell programming. Is that correct, Rieks?

from rap.

@stefjoosten: Yes. Please provide a concrete example of what you want to do.

from rap.

I'll do that after oct 22nd, when I return from Holiday. Until then I only have my phone and most of the time no internet.

from rap.

@rieks: In RAP3 you introduced a rule that password of an account shouln't be 'welcome' if there is a script attatched to that account. Your intention probably was that only the user who is logged in with such an account would be signalled with a single violation. However, currently any user with the rule 'student' will get all violations, regardless of the account.

from rap.

Check! There is you example, @rieks. Thanks for bringing that up, @hanjoosten.

from rap.

I just checked that rule. It reads as follows:

ROLE User MAINTAINS "Wilt u uw wachtwoord veranderen?"
RULE "Wilt u uw wachtwoord veranderen?": '_SESSION';sessionAccount;accPassword;'welkom' |- -V
MESSAGE "Het wachtwoord 'welkom' dient te worden aangepast."
VIOLATION (TXT "U dient uw wachtwoord te wijzigen in de interface 'My Account' in de menubalk.")

There is nothing that should be changed there, since every violation (when computed) can at most contain one pair, being ('_SESSION','welkom'), and this violation pertains to that user's account. This should work.

@stefjoosten: please provide a proper example for this ticket.

from rap.

I'm marking this as ampersand coding required based on Rieks' solution for this rule. If he wants nice Ampersand syntax for rules like this (and I agree that would be a nice feature) @stefjoosten can ask for that in a separate ticket, but it will be less urgent since RAP3 does not depend on that.

from rap.