Code tour: 2018-07-15 to 2018-09-01

[kaberett]

Tiiiiiiiiiiny code tour!

Issue 2227: [#2227] remove remaining references to AIM (pull request)
Category:
Patch by: kareila
Description: If it looks familiar, this is because it was previously mostly fixed! Display of AIM usernames was removed... but it was still possible to specify what your AIM username had been on the Edit Profile page. Whereupon it would be swallowed into the depths of the database and digested, silently, never to be seen again, which doesn't do anyone much good. The Edit Profile field was, therefore, pruned.

Issue 2228: Link to image hosting pages from Site Map (pull request)
Category:
Patch by: rshatch
Description: Dreamwidth has image hosting! It... is optimal to actually provide links to it from the site menus, so it's easier to find and manage. Ta-da.

Issue 2329: 1661 banned behaviour (pull request)
Category:
Patch by: swaldman3
Description: Hilariously, what exactly happens when user A bans user B is that user B gets banned from user A's journal, not from... replying to A in other people's journals, or in communities. This is not as intended -- bans are supposed to apply to the person who made the ban, not the journal. Because of the number of different ways Dreamwidth provides to reply to comments, the logic for this is a bit convoluted, but banning functionality has now been extended. There is a some tidying up left to do, but this is progress and progress is good.


3 total issues resolved
Contributors: kareila, rshatch, swaldman3

Comments

Re: Issue 2329

[pan_2]

Hello again.

The second 20_00's proposal looks interesting:

ban the person from communicating with me everywhere option will retain the new/current ability to completely cut off harassers;

ban the person from communicating with me only in my journal option will give the ability for the ban recipient to still contact the user in other journals and communities; also it can be changed later to the total ban if the need will arise.

For the regular communities this will not change anything, and for those who choose to refrain from using the total ban for it's members - this is a matter for that community members only.

Both options don't need the involvement of the ToS/Abuse team in any way.

From my POV this is interesting proposal, and it is in the spirit of the "freedom of expression".

Re: Issue 2329

[lxe]

I wholeheartedly side with the second proposal. It doesn't introduce hidden state/context variables (such as community settings) and presents the user a clearly "aforeexplained" set of options. The extra cost would be, I presume, one extra boolean filed in the [banner, banned] association table (provided the backend is an RDB) and an extra condition term in the WHERE clause.