Improve the notification templates in order add the possibility to add a classification label

[evilaliv3]

It has been requested by Transparency-TI to improve the notification templates in order add the possibility to add a classification label.

The idea is that analyzing a tip the receiver(s) could assign a label to the tip in order to identify further submission in relation to an opened case.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[vecna]

assign a label from a defined group of possible labels, or assign an arbitrary string ? the second was requested also by @infosquatter

[fpietrosanti]

Their use-case is only to use a single label to receive the Subject line of notification to have the label they applied (if present) such as "ComuneRozzano" or "AppaltoXYZ": Subject: [Notification: $progressive $label]

[vecna]

Ok, good, than is the same requested from @infosquatter (use cases: when you deal with a lots of tip, you don't recognize them. this mean that also the "preview field" is not the proper solution, 'cos in the beginning has been planned for this reason)

[evilaliv3]

yep i confirm that the aim of this ticket is to simply assign a label to the tip chosen by receivers. the tip will have one and one only label that all the receivers will have the possibility to configure(initially) and edit (after first assignment).

the label when assigned will need to availably as templateing variable in mail notifications (%TipLabel%) and shown on preview.

the concept is that this will be used of assig cases IDs in reference to others db used by organizations (legal cases, etc..) and its different from the concept you had in past @vecna in order to assign labels.

[vecna]

just to be clear: editing is in the tip status page, and the label is display after in the tip list ? is a PUT operation in receivertip that influence internaltip ? can we keep track of the chanes with a system comment ? duplicated label are acceptable (I suggest:yes)

[fpietrosanti]

Displaying a label on tip-list shall be another ticket

[evilaliv3]

The label should be configurable by receivers on the tip page and and show on them too.

It showd be shown on the tip page, available on mail notifications and on tip list. No need to spawn multiple tickets as this is really few changes that relate to a sigle feature. I failed in opening the ticket due to mobility but the feature needed to address it are the one I've described till now.

I've already added a sigle variable to internaltip that I will push in next db change. When we will switch to e2e encryption the variable will be put in receivertip as probably fields like this will need to be always encrypted for each receiver. I will open a ticket in order to analyze and describe all the changes that will be needed for e2e encryption.

@vecna for what concern system comments the implementation we did was a fast hack that for various reasons cant work now. (E.g. When on tip page we show only private messages we are currently not able to show comments without additional logic. for this and other reasons i suggest to stop using them and opening a ticket where to discuss about logs and logs visibilities that are the generalization of this

[vecna]

@evilaliv3 verychiaro.it

[evilaliv3]

@vecna / @fpietrosanti : i want you to think to this doubts of mine:

1) do we dant this label to be unique per Tip or multiple for each receiver Tip? the first solution has drawbacks in multi stakeolder initiatives like Publeaks. the latter has drawback in single cohesive small groups like IRPI/TI

2) do we want this label to be internationalizable? i think not it would be realle difficult to be used by receivers. obviously not permitting this has a drawbacks but i would like to go for simplicity now.

[fpietrosanti]

1) I think that the request from TI of a label is "Per Receive on a single Tip" and it's something that the Receiver decide to type as a free-text when working on the Tip (e.g.:Giorgio decide that this tip is related to AppaltoXYZ and tag it as "AppaltoXYZ" or it's related to Comune di Rozzano, so he tag as "ComuneRozzano")

2) It's not internationalized because it's typed by the Receiver on the tip

[evilaliv3]

ok in case this is implemented per receiver i agree.

the issue is only if they want the label to be per Tip cause it will be a problem for multi stakeolder initiatives. for the moment so i modify the db so to accept a single per receiver and non internationalized "label".

[evilaliv3]

Db support for this ticket has been implemented adding an attribute 'label' to the receiverTip table so that now what is missing is basically the handler that would allow a user to apply a label to the tip.

[vecna]

clear, but I guess we want permit the editing from the single Tip and the display of the label in the tiplistpage ?

[evilaliv3]

Exactly, single tip, receiver specific (receiver tip) and so exported only in the receiver tip).

For what relates the api I would if I would use the same we are using for the postpone and delete that was thought by me on order to host other operations like this (assign_label)

Sounds good?

We can work on iterating on it a bit so that one can perform with a single request multiple operations in the following ux fashion: .

• I click on an edit button or I perform a certain input in an area
• as I edit things the clients logs the actions I want to perform
• when I click an explicit save all my edits are applied performing a request on this api with the ordered list of operations that I've executed

[vecna]

Yes, only "problem" I see, is in the notification side. We need to have a [%Label%] that sometime can be empty ? or better we can:

• use the number randomly assigned as Label by default
• when the Label is set, overwrite the number

And via graphical communication, we can make clear that the number can be changed (for example, is in grey, or stay inside a text area until changed)

[evilaliv3]

I think that keeping things separated would be best even for making people understand the fearures

Let me align you on what discussed with naif:

• the random number is going to be removed
• the random will be replaced with the yearmonthday-sequencenumberinside the day assigning so a protocol to the ticket not leaking the total number but only eventually the daily number
• the label would be addressed by this ticket and yes it would be possible for it to be empty

[vecna]

clear, I'm working on it.

[vecna]

I'm facing a very weird issue here with the validation, uploaded the code in the branch anti-dos-research at the moment.

[evilaliv3]

Nice @vecna but please make comments that add some value.

This comment addsu alarmism but does not tell anything at all

[vecna]

Intro

i've changed the DELETE operation to assign an hardcoded Label, was intended to test the hanlder before implement the client side. This operation, is not working:

The error is "InvalidInputFormat" (dict expected):

The content sent is:

  {"operation":"label","label":"ciaociaoXX"}

The validation works:

  2015-09-03 10:45:32+0200 [D] Authentication OK (receiver)
  2015-09-03 10:45:32+0200 [D] Updating ReceiverTip label from [] to ciaociaoXX
  2015-09-03 10:45:32+0200 [ ] 406 PUT /rtip/fda58a53-2aad-41ed-8fc4-bbe0f2efb4f5 (127.0.0.1): GLException
  2015-09-03 10:45:32+0200 [http] 406 PUT /rtip/fda58a53-2aad-41ed-8fc4-bbe0f2efb4f5 (127.0.0.1) 10.74ms

because the execution flow reach the transact:

    @transact
    def assign_rtip_label(store, user_id, tip_id, label_content):
        rtip = db_access_tip(store, user_id, tip_id)
        log.debug("Updating ReceiverTip label from [%s] to %s" % (rtip.label, label_content))
        rtip.label = unicode(label_content)

And the handler has this code:

     if request['operation'] == 'label':
         yield assign_rtip_label(self.current_user.user_id, tip_id, request['label']) 
     self.set_status(202)  # Updated
     self.finish()

so, I don't see much sense on what is happening, if some new kind of validation is in place, but the result is this:

  {"error_message": "Invalid Input Format [(label) dict expected]", "error_code": 10, "arguments": ["(label) dict expected"]}

[vecna]

Found, in the models you've declared the mock version of 'label' as Unicode(validator=shortlocal_v) but shortlocal is used only for localized JSON and don't apply to Unicode.

[vecna]

done, will be proposed PR along all the others improvement of anti-dos branch

[evilaliv3]

okay!

[evilaliv3]

@vecna unit test is missing here. can you implement it?

[vecna]

yes, today

[vecna]

done above

[evilaliv3]

well done @vecna

from my point of view this time you were be able to still continue working on the same branch ADI+1156 intregrating the pull request but thanks for trying to split the branches;

[evilaliv3]

@fpietrosanti / @vecna: do you find ok that we show the label info also to the whistleblower?

i'm thinking that this may help in whistleblower/receiver communication wherever the whistleblower has done multiple submissions and they want refer them.

[evilaliv3]

ah no, this is not possible at all as the label is per-receiver so every receiver will label it for it's personal use.

for refering to a submission while discussing with the whistleblower/other receivers a receiver may simply use the tip sequence number that will act as a globaleaks protocol number shared among all users: https://github.com/globaleaks/GlobaLeaks/issues/1158

[evilaliv3]

Here we go!

@vecna look at the commit to learn how to do the things that you wanted to do.

[fpietrosanti]

Sent from mobile

On 07/set/2015, at 10:53, Giovanni Pellerano notifications@github.com wrote: Fra @fpietrosanti / @vecna: do you find ok that we show the label info also to the whistleblower?

No, as we do not have a concept of multiple submissions from the same Whistleblower

[evilaliv3]

The label is now configurable; We simply miss to export it in mail templates.

When dealing with this ticket it would be easy to deal also with https://github.com/globaleaks/GlobaLeaks/issues/1158

[evilaliv3]

Feature implementation completed!

The traditional mail subject prefixed by [Tip NUM] is now replaced by [YYYYMMDD-SEQ] as done in ticket #1158

When the receiver configure also a label (e.g. Pino Cammino) the subject will appear like in the following examples:

[20151105-1] [Pino Cammino] New submission [20151105-1] [Pino Cammino] New comment [20151105-1] [Pino Cammino] New file attachment