pleroma/pleroma-fe
0
0
Fork 0
Code Issues 343 Pull requests 27 Projects Releases Packages Wiki Activity

Moderation menu #310 #1865

Closed
eugenijm wants to merge 0 commits from gitlab-mr-iid-595 into develop
pull from: gitlab-mr-iid-595
merge into: pleroma:develop
Conversation 98 Commits - Files changed -
eugenijm commented 2019-02-18 15:11:45 +00:00
Member
Copy link

Implements dropdown menu as per #310 discussion.

Video: https://cl.ly/bdd468fe1e58,
menu auto-positioning: https://cl.ly/88373da97854 (the auto-positioning is optional FWIW)

Complementary backend MR for changing activation status API: pleroma/pleroma#4229

Additional backend MR needed for the "deactivated" status in the user view pleroma/pleroma#4260 (should be merged first, the FE depends on it)

Visibility table. If an action is not applicable to the given user type, FE doesn't show it in the menu.

I have run tests on internal and external users to see which actions are applicable to which user type but corrections are welcome!

Menu item Applicable to user type Video
Grant Admin local local user
Grant Moderator local local user
Deactivate account local and external local user external user
Delete account local and external local user external user from timeline
Force posts to be NSFW local and external local user external user
Force posts not to have media local and external local user external user
Force posts to be unlisted local and external local user external user
Force posts to be followers-only local and external local user external user
Disallow following user from remote instances local local user
Disallow following user at all local

"Disallow user posts from federating" - apparently it's not implemented yet, should we add it later?

Screenshots for different themes

Themed dropdown menu Themed Delete User dialog
Pleroma Dark Pleroma Dark
Pleroma Light Pleroma Light
Classic Dark Classic Dark
Bird Bird
Ir Black Ir Black
Monokai Monokai
Mammal Mammal
Remond XX Redmond XX
Breezy Dark Breezy Dark
Breezy Light Breezy Light

Mobile: Light menu, Dark menu, Light Delete User dialog, Dark Delete User dialog

Mobile Video: https://cl.ly/115b0517fe3f

Screen_Shot_2019-02-22_at_7.00.26_PM

Screen_Shot_2019-02-26_at_12.33.00_PM

Screen_Shot_2019-02-22_at_7.06.06_PM

Implements dropdown menu as per https://git.pleroma.social/pleroma/pleroma-fe/issues/310 discussion. Video: https://cl.ly/bdd468fe1e58, menu auto-positioning: https://cl.ly/88373da97854 (the auto-positioning is optional FWIW) Complementary backend MR for changing activation status API: https://git.pleroma.social/pleroma/pleroma/pulls/4229 Additional backend MR needed for the "deactivated" status in the user view https://git.pleroma.social/pleroma/pleroma/pulls/4260 (should be merged first, the FE depends on it) Visibility table. If an action is not applicable to the given user type, FE doesn't show it in the menu. I have run tests on internal and external users to see which actions are applicable to which user type but corrections are welcome! Menu item | Applicable to user type | Video | ----------------------------------------------|---------------------------|--------------------------------------------------------------------------------------| Grant Admin | local | [local user](https://cl.ly/bffe105e3787) | Grant Moderator | local | [local user](https://cl.ly/a2a439a293f1) | Deactivate account | local and external | [local user](https://cl.ly/64c8430698e5) [external user](https://cl.ly/0c32df721bc7) | Delete account | local and external | [local user](https://cl.ly/e2a09d100d16) [external user](https://cl.ly/877be92a1fac) [from timeline](https://cl.ly/3bd19f01b475) | Force posts to be NSFW | local and external | [local user](https://cl.ly/4cdc4dc6863e) [external user](https://cl.ly/c791513a1a2b) | Force posts not to have media | local and external | [local user](https://cl.ly/f6d89fff07bb) [external user](https://cl.ly/5afc67afd8d8) | Force posts to be unlisted | local and external | [local user](https://cl.ly/ebf80ac797cf) [external user](https://cl.ly/60b025a73d7e) | Force posts to be followers-only | local and external | [local user](https://cl.ly/47fac0f92835) [external user](https://cl.ly/d083d5092bd0) | Disallow following user from remote instances | local | [local user](https://cl.ly/e3b82f36d98e) | Disallow following user at all | local | | "Disallow user posts from federating" - apparently it's not implemented yet, should we add it later? Screenshots for different themes Themed dropdown menu | Themed Delete User dialog ------------|----------------------------- [Pleroma Dark](/attachments/afb71984-6027-4856-b3c8-74b325290ff1) | [Pleroma Dark](/attachments/ed581097-ed3c-4cfa-b59c-1ac4072a7e11) [Pleroma Light](/attachments/ea2b2186-f66c-4572-a8ac-1c5651d51c46) | [Pleroma Light](/attachments/5e95c65a-11cd-43ba-a24f-5171b7e6d4cc) [Classic Dark](/attachments/6f4eb08f-125e-48ec-8ce4-17a5afb1da02) | [Classic Dark](/attachments/59a9eabe-f13c-499a-8bab-001cef9aae06) [Bird](/attachments/947589b4-e8ac-44e9-a519-6c6aa098f08a) | [Bird](/attachments/08b00874-4d62-4a71-8dd8-bf25899c7de1) [Ir Black](/attachments/257eb1fe-175f-4a90-b3cc-8b4afd56657f) | [Ir Black](/attachments/90e997a6-0891-495d-a6c5-f758f18f7850) [Monokai](/attachments/3f2eb3d6-7ad4-4472-a513-4ed6ce0e275e) | [Monokai](/attachments/42f72a79-fdb3-4093-86fc-75f72ea2b85d) [Mammal](/attachments/8c770108-4c96-482f-b44a-6f341c9f0995) | [Mammal](/attachments/79d54435-dac4-48b4-aec2-00a01684435e) [Remond XX](/attachments/2b976094-d4fd-4cff-badf-856f4d1dc324) | [Redmond XX](/attachments/d594d008-f8c8-44cc-9eb9-cc95b4ab3b5e) [Breezy Dark](/attachments/87504fb6-f04a-4a37-b3b9-ba119b1f8c32) | [Breezy Dark](/attachments/647136f0-468e-4b1b-817f-6c87862308b1) [Breezy Light](/attachments/cf0ba587-1d59-47bb-be48-dc5686de7703) | [Breezy Light](/attachments/a6d79358-1eaf-4d31-a803-35dae24e6257) Mobile: [Light menu](/attachments/b1df1979-08de-472e-b3c5-b5f9e7520fb9), [Dark menu](/attachments/ff168e2a-59bb-4a5f-b76a-b1cf5ca08cd5), [Light Delete User dialog](/attachments/6665757d-9301-456a-ba52-3c090b6f1784), [Dark Delete User dialog](/attachments/2521a43c-6f03-4d82-9814-994767852f62) Mobile Video: https://cl.ly/115b0517fe3f ![Screen_Shot_2019-02-22_at_7.00.26_PM](/attachments/64582cd2-90cb-4923-858b-fae90667049b) ![Screen_Shot_2019-02-26_at_12.33.00_PM](/attachments/cc59409d-f620-41b1-9d4a-502de7e5df8e) ![Screen_Shot_2019-02-22_at_7.06.06_PM](/attachments/7fe75d61-b94e-46cf-a4df-74be8142f9c3)
Screen_Shot_2019-02-26_at_11.42.16_AM.png
2.7 MiB
Screen_Shot_2019-02-26_at_12.10.17_PM.png
2.1 MiB
Screen_Shot_2019-02-26_at_11.57.38_AM.png
2.2 MiB
Screen_Shot_2019-02-26_at_12.12.02_PM.png
2.2 MiB
Screen_Shot_2019-02-26_at_12.00.53_PM.png
2.6 MiB
Screen_Shot_2019-02-26_at_12.12.48_PM.png
2 MiB
Screen_Shot_2019-02-26_at_12.02.17_PM.png
2.6 MiB
Screen_Shot_2019-02-26_at_12.13.55_PM.png
2 MiB
Screen_Shot_2019-02-26_at_12.02.59_PM.png
2.6 MiB
Screen_Shot_2019-02-26_at_12.14.34_PM.png
2.1 MiB
Screen_Shot_2019-02-26_at_12.04.11_PM.png
2.7 MiB
Screen_Shot_2019-02-26_at_12.15.41_PM.png
2 MiB
Screen_Shot_2019-02-26_at_12.04.52_PM.png
2.6 MiB
Screen_Shot_2019-02-26_at_12.16.32_PM.png
2.2 MiB
Screen_Shot_2019-02-26_at_12.23.28_PM.png
2.6 MiB
Screen_Shot_2019-02-26_at_12.24.25_PM.png
2 MiB
Screen_Shot_2019-02-26_at_12.07.44_PM.png
2.5 MiB
Screen_Shot_2019-02-26_at_12.17.56_PM.png
2.1 MiB
Screen_Shot_2019-02-26_at_12.08.31_PM.png
2.7 MiB
Screen_Shot_2019-02-26_at_12.22.17_PM.png
2 MiB
mobile_light_menu.png
307 KiB
mobile_dark_menu.png
342 KiB
mobile_light_delete_user_dialog.png
286 KiB
mobile_dark_delete_user_dialog.png
290 KiB
Screen_Shot_2019-02-22_at_7.00.26_PM.png
2.3 MiB
Screen_Shot_2019-02-26_at_12.33.00_PM.png
2.6 MiB
Screen_Shot_2019-02-22_at_7.06.06_PM.png
649 KiB
hj commented 2019-02-18 19:55:43 +00:00
Owner
Copy link

positioning dropdown absolutely with JS to figure out position is the way to go with all tooltips/popups in web, i assume.

This is what i'd want in pleromafe, anyway.

positioning dropdown absolutely with JS to figure out position is the way to go with all tooltips/popups in web, i assume. This is what i'd want in pleromafe, anyway.
hj commented 2019-02-18 19:55:58 +00:00
Owner
Copy link

just return is enough

just `return` is enough
hj commented 2019-02-18 19:56:50 +00:00
Owner
Copy link

is this a call to cation or todo?

is this a call to cation or todo?
hj commented 2019-02-18 19:59:21 +00:00
Owner
Copy link

I don't think it's a good idea to use faint for button text.

I don't think it's a good idea to use faint for button text.
hj commented 2019-02-18 19:59:37 +00:00
Owner
Copy link

overwriting with wrong color?

overwriting with wrong color?
eugenijm commented 2019-02-19 16:21:07 +00:00
Author
Member
Copy link

Looks like a TODO leftover, removed it.

Looks like a TODO leftover, removed it.
eugenijm commented 2019-02-19 17:29:39 +00:00
Author
Member
Copy link

Yeah, I was thinking about doing it with JS eventually. I considered adding the popper.js lib. It's ~44.6kb non minimized (~13kb minimized) and should save some trouble maintaining the positioning logic. What do you think about this approach?

Yeah, I was thinking about doing it with JS eventually. I considered adding the [popper.js](https://github.com/FezVrasta/popper.js) lib. It's ~44.6kb non minimized (~13kb minimized) and should save some trouble maintaining the positioning logic. What do you think about this approach?
hj commented 2019-02-20 08:08:32 +00:00
Owner
Copy link

Not exactly liking it's size, but it has zero dependencies so it's ok I guess.

Not exactly liking it's size, but it has zero dependencies so it's ok I guess.
eugenijm commented 2019-02-21 09:10:15 +00:00
Author
Member
Copy link

Yup, I'm not sure what are the alternatives when it comes to doing positioning with JS. I'd like to avoid adding too much code because of the cost associated with parsing and compiling it (bandwidth-wise, popper.js is only 6kb gzipped). But writing positioning logic ourselves while handling all the edge cases properly would probably result in something of a similar size I think.

Yup, I'm not sure what are the alternatives when it comes to doing positioning with JS. I'd like to avoid adding too much code because of the cost associated with parsing and compiling it (bandwidth-wise, popper.js is only 6kb gzipped). But writing positioning logic ourselves while handling all the edge cases properly would probably result in something of a similar size I think.
eugenijm commented 2019-02-21 09:11:13 +00:00
Author
Member
Copy link

I've refactored the styling a bit removing redundant rules.

I've refactored the styling a bit removing redundant rules.
eugenijm commented 2019-02-21 09:22:31 +00:00
Author
Member
Copy link

With regards to colors, is there a consensus on which colors should be used for the menu elements?

In the prototype, I went with the general background color to be consistent with the background color of a pressed button so that there is a visual connection between the two elements.

Also, the indicator appearance: Screen_Shot_2019-02-21_at_10.27.05_AM

I figured that for long labels, it might be clearer if we add the "ON" badge than if we change text (like in "Grant Admin" / "Revoke Admin").

The screenshots of how the menu looks in different themes:

With regards to colors, is there a consensus on which colors should be used for the menu elements? In the prototype, I went with the general background color to be consistent with the background color of a pressed button so that there is a visual connection between the two elements. Also, the indicator appearance: [Screen_Shot_2019-02-21_at_10.27.05_AM](/attachments/28abe1f9-d5c7-440e-8770-5c158bff6497) I figured that for long labels, it might be clearer if we add the "ON" badge than if we change text (like in "Grant Admin" / "Revoke Admin"). The screenshots of how the menu looks in different themes: * [Pleroma Dark](/attachments/d9167255-9c62-4dd7-ba3f-e06faec81198) * [Pleroma Light](/attachments/25068b4e-7090-47a0-be50-05f0467f76a0) * [Classic_Dark](/attachments/8985378a-f2b1-48f0-8422-99a44488b7e7) * [Bird](/attachments/801fdae8-3dec-4009-beda-e40a32178765) * [Ir_Black](/attachments/16866d41-4594-4341-b6b1-42c6e50773fa) * [Monokai](/attachments/115b7103-dd82-4481-8ea9-1d8825294faf) * [Mammal](/attachments/1eebe36a-90a7-44f8-9eee-783eb68f0e17) * [Redmond XX](/attachments/9b775c0e-ac95-4359-8b5f-027a5f2f2cac) * [Breezy Dark](/attachments/e3f3031b-be31-45b3-88c2-fff78564392a) * [Breezy Light](/attachments/b035a117-a98b-4e19-ba4f-9a48d6fddb32)
Screen_Shot_2019-02-21_at_10.27.05_AM.png
74 KiB
Pleroma_Dark.png
2.2 MiB
Classic_Dark.png
2.2 MiB
Bird.png
2.1 MiB
Ir_Black.png
2.1 MiB
Monokai.png
2.1 MiB
Mammal.png
2.2 MiB
Redmond_XX.png
2.2 MiB
Breezy_Dark.png
2.2 MiB
Breezy_Light.png
2.1 MiB
Pleroma_Light.png
2.1 MiB
eugenijm commented 2019-02-21 17:30:46 +00:00
Author
Member
Copy link

Prototyping the user deletion confirmation dialog. Any suggestions on the UX? I considered having something like "Enter the user nickname" to prevent admins from deleting a user by accident. Some platforms (e.g. heroku, github) have that extra protection when you're deleting a repo or app since this cannot be undone. But not sure if necessary. /cc @feld @shpuld @hj

Screen_Shot_2019-02-21_at_8.20.21_PM

Prototyping the user deletion confirmation dialog. Any suggestions on the UX? I considered having something like "Enter the user nickname" to prevent admins from deleting a user by accident. Some platforms (e.g. heroku, github) have that extra protection when you're deleting a repo or app since this cannot be undone. But not sure if necessary. /cc @feld @shpuld @hj ![Screen_Shot_2019-02-21_at_8.20.21_PM](/attachments/6ae4444e-ec2a-4719-93f4-8dc2017c2d1b)
Screen_Shot_2019-02-21_at_8.20.21_PM.png
703 KiB
hj commented 2019-02-21 18:17:20 +00:00
Owner
Copy link

header looks weird in modal.Should match panels in height.

selection in dropdown should use different color instead of border

header looks weird in modal.Should match panels in height. selection in dropdown should use different color instead of border
hj commented 2019-02-21 18:18:03 +00:00
Owner
Copy link

I figured that for long labels, it might be clearer if we add the "ON" badge than if we change text (like in "Grant Admin" / "Revoke Admin").

can't we reuse checkbox styles for them tho?

>I figured that for long labels, it might be clearer if we add the "ON" badge than if we change text (like in "Grant Admin" / "Revoke Admin"). can't we reuse checkbox styles for them tho?
eugenijm commented 2019-02-22 13:59:12 +00:00
Author
Member
Copy link

Updated the header appearance, making it look more like panel:

Video: https://cl.ly/12739bd06e72

Updated selection in dropdown. This piggybacks on the already existing contrast between a pressed and regular button and works across different themes.

  • Menu element: pressed button background.
  • Selected menu element: regular button background.

Screen_Shot_2019-02-22_at_7.28.01_PM

Also, added modal component, ready for preliminary review

modal.vue, moderation_tools.js

can't we reuse checkbox styles for them tho?

Update: Would something like this do?

Screen_Shot_2019-02-24_at_8.58.49_PM

Updated the header appearance, making it look more like panel: * [Pleroma Dark](/attachments/dcdf7274-d935-46ad-bbd6-c7baf3dc5c0c) * [Pleroma Light](/attachments/aeaf9619-97ff-4b20-ac8a-a4ccbbf81e58) * [Classic Dark](/attachments/c4714772-3f89-40a3-9fde-3f5319a56fef) * [Bird](/attachments/ec25fb71-f012-4d7b-bb8b-091b35d5cf7d) * [Ir Black](/attachments/81b67fce-e80a-4a09-a039-b78f453623fa) * [Monokai](/attachments/3790a774-d7fc-4849-90eb-216b81c7448a) Video: https://cl.ly/12739bd06e72 Updated selection in dropdown. This piggybacks on the already existing contrast between a pressed and regular button and works across different themes. * Menu element: pressed button background. * Selected menu element: regular button background. ![Screen_Shot_2019-02-22_at_7.28.01_PM](/attachments/df83b657-e7ee-4fbc-b937-aa19290b55d5) * [Pleroma Dark](/attachments/65e4dfe9-396f-4a1e-bd57-ee0cecc049f8) * [Pleroma Light](/attachments/1f7794b8-c3f3-46af-9f34-8bf7beb9d398) Also, added modal component, ready for preliminary review [modal.vue](https://git.pleroma.social/pleroma/pleroma-fe/pulls/1865/diffs#8420440059b793843b18c895722058b1bef1a797_0_1), [moderation_tools.js](https://git.pleroma.social/pleroma/pleroma-fe/pulls/1865/diffs#6188abce194b2d64d6dc80ae25cee44c4dc23b69_0_19) > can't we reuse checkbox styles for them tho? Update: Would something like this do? ![Screen_Shot_2019-02-24_at_8.58.49_PM](/attachments/7e2bd734-0627-4215-8bdf-ddfc0c1cd8c3)
Screen_Shot_2019-02-22_at_7.10.45_PM.png
662 KiB
Screen_Shot_2019-02-22_at_7.11.58_PM.png
828 KiB
Screen_Shot_2019-02-22_at_7.13.38_PM.png
693 KiB
Screen_Shot_2019-02-22_at_7.14.27_PM.png
628 KiB
Screen_Shot_2019-02-22_at_4.57.00_PM.png
825 KiB
Screen_Shot_2019-02-22_at_7.16.00_PM.png
598 KiB
Screen_Shot_2019-02-22_at_7.28.01_PM.png
146 KiB
Screen_Shot_2019-02-22_at_5.30.02_PM.png
900 KiB
Screen_Shot_2019-02-22_at_5.31.44_PM.png
1.1 MiB
Screen_Shot_2019-02-24_at_8.58.49_PM.png
26 KiB
eugenijm commented 2019-02-24 19:08:24 +00:00
Author
Member
Copy link

Also, regarding the checkbox style, which alignment style would be better:

Right after the text:

checkbox1

Before the text:

checkbox3

Aligned on the right side:

Screen_Shot_2019-02-24_at_9.54.42_PM

Also, should we display the nonchecked state or is it better to omit it? Example when the nonchecked state is not displayed:

Screen_Shot_2019-02-24_at_9.55.32_PM

/cc @hj @shpuld

Also, regarding the checkbox style, which alignment style would be better: Right after the text: ![checkbox1](/attachments/08a6172f-f944-4a2c-ab84-219f81d3f05a) Before the text: ![checkbox3](/attachments/ffefdcc2-2f1b-4976-9d72-3623bc465293) Aligned on the right side: ![Screen_Shot_2019-02-24_at_9.54.42_PM](/attachments/296751a4-371e-4b4a-81eb-63162522756f) Also, should we display the nonchecked state or is it better to omit it? Example when the nonchecked state is not displayed: ![Screen_Shot_2019-02-24_at_9.55.32_PM](/attachments/fe31fbe5-7b95-4bb6-b100-48d5e4bc4aa7) /cc @hj @shpuld
checkbox1.png
461 KiB
checkbox3.png
506 KiB
Screen_Shot_2019-02-24_at_9.54.42_PM.png
552 KiB
Screen_Shot_2019-02-24_at_9.55.32_PM.png
539 KiB
eugenijm commented 2019-02-25 11:00:33 +00:00
Author
Member
Copy link

I was debating whether it's better to insert modal in this way versus having it inserted somewhere at the root (like it's done with MediaModal).

I went with this approach eventually because it seemed convenient to be able to pass header, content, and footer via slots. Not having to add additional state to the store was another point in favor of this approach. But please let me know if you would rather have it inserted in App.vue.

I was debating whether it's better to insert modal in this way versus having it inserted somewhere [at the root](https://git.pleroma.social/pleroma/pleroma-fe/blob/8f0e6b50454a3b8e776640a895519cdc57872a92/src/App.vue#L24) (like it's done with `MediaModal`). I went with this approach eventually because it seemed convenient to be able to pass header, content, and footer via slots. Not having to add additional state to the store was another point in favor of this approach. But please let me know if you would rather have it inserted in `App.vue`.
eugenijm commented 2019-02-25 21:26:12 +00:00
Author
Member
Copy link

Update: added popper.js https://cl.ly/88373da97854 (auto-positioning is optional by the way, in case it's preferable to have the menu fixed at the bottom)

Update: added popper.js https://cl.ly/88373da97854 (auto-positioning is optional by the way, in case it's preferable to have the menu fixed at the bottom)
hj commented 2019-02-26 18:09:46 +00:00
Owner
Copy link

re: checkboxes

Aligned on the right side, always show is the best option IMO.

P.S. why are they round for you is that a theme or broken styles?

re: checkboxes Aligned on the right side, always show is the best option IMO. P.S. why are they round for you is that a theme or broken styles?
eugenijm commented 2019-02-27 16:38:52 +00:00
Author
Member
Copy link

Updated checkboxes (removed rounding, it was due to style overlap)

Updated checkboxes (removed rounding, it was due to style overlap) * [Pleroma Light](/attachments/a06eba0a-818c-4258-b7d2-5c58c9a64e47) * [Pleroma Dark](/attachments/734dee7b-0483-4ae3-aab3-d950224e70ac)
Screen_Shot_2019-02-27_at_7.36.11_PM.png
473 KiB
Screen_Shot_2019-02-27_at_7.36.32_PM.png
446 KiB
hj commented 2019-02-27 20:02:44 +00:00
Owner
Copy link

image

![image](/attachments/03ebf99f-7e4a-4335-a2e5-69f5fde39b3c)
image.png
214 KiB
kaniini commented 2019-02-28 10:31:51 +00:00
Member
Copy link

I would like to test this on pleroma.site is it usable yet?

I would like to test this on pleroma.site is it usable yet?
eugenijm commented 2019-02-28 10:52:26 +00:00
Author
Member
Copy link

Yes, tested it on my instance

It requires this MR on backend pleroma/pleroma#4260

Yes, tested it on my instance It requires this MR on backend https://git.pleroma.social/pleroma/pleroma/pulls/4260
kaniini commented 2019-02-28 11:18:24 +00:00
Member
Copy link

Deployed on pleroma.site.

Some observations:

Screenshot_from_2019-02-28_05-17-09

Moderation menu from the sidebar is a little odd (see above screenshot).

Also, remote users should not have the "disable federation" option, as we wouldn't be federating their posts anyway.

Deployed on pleroma.site. Some observations: ![Screenshot_from_2019-02-28_05-17-09](/attachments/4cb4d48c-02cc-49c3-9120-5cae1caefe61) Moderation menu from the sidebar is a little odd (see above screenshot). Also, remote users should not have the "disable federation" option, as we wouldn't be federating their posts anyway.
Screenshot_from_2019-02-28_05-17-09.png
378 KiB
kaniini commented 2019-02-28 11:19:44 +00:00
Member
Copy link

I think changing the NSFW and media stripping options to:

  • Mark all posts as NSFW
  • Remove media from posts

would be more explanatory.

I think changing the NSFW and media stripping options to: * Mark all posts as NSFW * Remove media from posts would be more explanatory.
eugenijm commented 2019-02-28 12:03:22 +00:00
Author
Member
Copy link

Removed "disable federation" from the menu for remote users and updated the naming.

Re: the screenshot, wasn't sure about displaying the menu in the sidebar. Is it better to remove it completely from there? The lack of space makes it difficult to display it properly; the UI feels slightly overloaded.

Removed "disable federation" from the menu for remote users and updated the naming. Re: the screenshot, wasn't sure about displaying the menu in the sidebar. Is it better to remove it completely from there? The lack of space makes it difficult to display it properly; the UI feels slightly overloaded.
kaniini commented 2019-02-28 12:15:41 +00:00
Member
Copy link

I think it's fine to not have the moderation button in sidebar.

I think it's fine to not have the moderation button in sidebar.
kaniini commented 2019-02-28 12:55:19 +00:00
Member
Copy link

Another issue: as far as I can tell, trying to set MRF tags on users is not actually working: clicking the item does nothing (does not even close the menu), and no API calls are made.

Another issue: as far as I can tell, trying to set MRF tags on users is not actually working: clicking the item does nothing (does not even close the menu), and no API calls are made.
kaniini commented 2019-02-28 12:57:32 +00:00
Member
Copy link

Seems it works for local users, but not remote.

Seems it works for local users, but not remote.
kaniini commented 2019-02-28 13:01:15 +00:00
Member
Copy link

Seems to be related to accounts which do not have tags yet:

Screenshot_from_2019-02-28_07-00-46

Seems to be related to accounts which do not have tags yet: ![Screenshot_from_2019-02-28_07-00-46](/attachments/a21aaad1-88a7-403f-990f-190db1b2a5ea)
Screenshot_from_2019-02-28_07-00-46.png
55 KiB
eugenijm commented 2019-02-28 13:20:06 +00:00
Author
Member
Copy link

Added default value for tags on the frontend just in case. Looks like backend always provides tags in user view, and there is also a default empty array in Ecto scheme https://git.pleroma.social/pleroma/pleroma/blob/develop/lib/pleroma/user.ex#L51. Could be a pure FE issue. Will try to reproduce it (tried to reproduce it on a remote user so far without luck https://cl.ly/b3903565e5d2)

Added default value for tags on the frontend just in case. Looks like backend always provides tags [in user view](https://git.pleroma.social/pleroma/pleroma/blob/develop/lib/pleroma/web/twitter_api/views/user_view.ex#L133), and there is also a default empty array in Ecto scheme https://git.pleroma.social/pleroma/pleroma/blob/develop/lib/pleroma/user.ex#L51. Could be a pure FE issue. Will try to reproduce it (tried to reproduce it on a remote user so far without luck https://cl.ly/b3903565e5d2)
eugenijm commented 2019-02-28 14:03:02 +00:00
Author
Member
Copy link

Added moderation in order to be able to display the menu only when the card is displayed in user profile or status (in TL). hideBio is null when the card is displayed in the notifications sidebar hence doesn't appear to be suitable for this case.

flag notifications user panel timeline profile
switcher false false false true
selected null null null null
hideBio null true null null
Added `moderation` in order to be able to display the menu only when the card is displayed in user profile or status (in TL). `hideBio` is null when the card is displayed in the notifications sidebar hence doesn't appear to be suitable for this case. flag | notifications | user panel | timeline | profile ---------|---------------|------------|----------|-------- switcher | false | false | false | true selected | null | null | null | null hideBio | null | true | null | null
eugenijm commented 2019-02-28 15:31:59 +00:00
Author
Member
Copy link

With regards to the issue with a remote user. So far, I've tried:

  • creating a new Mastodon account, mentioning admin account on my instance
  • creating a new Plaroma account on a different instance, mentioning admin account on my instance

This created fresh remote users without tags on my instance, and in both cases, MRF tags worked (w/o page refresh). Not sure what to conclude from this yet but I added empty array fallbacks for extra safety directly in the function that updates tags
and in the entity_normalizer which parses data coming from backend

Also, removed the Moderation button from the sidebar

With regards to the issue with a remote user. So far, I've tried: * creating a new Mastodon account, mentioning admin account on my instance * creating a new Plaroma account on a different instance, mentioning admin account on my instance This created fresh remote users without tags on my instance, and in both cases, MRF tags worked (w/o page refresh). Not sure what to conclude from this yet but I added empty array fallbacks for extra safety directly in the [function that updates tags](https://git.pleroma.social/pleroma/pleroma-fe/pulls/1865/diffs#8278bcb9f4439cb7d6eb66b5fa68d18cb89410c1_40_42) and in the [entity_normalizer](https://git.pleroma.social/pleroma/pleroma-fe/pulls/1865/diffs#31ffa7ec4281d31ca048ed7bc96e69d90b4d03a2_124_125) which parses data coming from backend Also, removed the Moderation button from the sidebar
hj commented 2019-02-28 16:21:15 +00:00
Owner
Copy link

Added default value for tags on the frontend just in case.

could also be problem with MastoAPI usage in FE. Just saying.

>Added default value for tags on the frontend just in case. could also be problem with MastoAPI usage in FE. Just saying.
hj commented 2019-02-28 16:22:19 +00:00
Owner
Copy link

I'd keep moderation button in sidebar, we're gonna put it into dots menu anyway so added complexity of showing/hiding it is bad.

I'd keep moderation button in sidebar, we're gonna put it into dots menu anyway so added complexity of showing/hiding it is bad.
kaniini commented 2019-02-28 17:25:52 +00:00
Member
Copy link

Yeah in my case it was all old accounts which lacked the tags being initialized to an array. I solved it with an SQL query, but it means the API can possibly return null (we could perhaps solve this with a migration over there if it makes lives easier over here).

Yeah in my case it was all old accounts which lacked the tags being initialized to an array. I solved it with an SQL query, but it means the API can possibly return null (we could perhaps solve this with a migration over there if it makes lives easier over here).
feld commented 2019-02-28 22:24:08 +00:00
Owner
Copy link

I'm OK with requiring a migration that should be in the BE long before this gets merged to stable branch and bundled with the BE

I'm OK with requiring a migration that should be in the BE long before this gets merged to stable branch and bundled with the BE
eugenijm commented 2019-03-01 17:28:47 +00:00
Author
Member
Copy link

Update: tags are fixed via BE MR pleroma/pleroma#4264

I'd keep moderation button in sidebar, we're gonna put it into dots menu anyway so added complexity of showing/hiding it is bad.

So, eventually, the moderation menu will be accessible via the dots menu in the notifications sidebar? I'd need to make a few changes to the current MR in this case. (Looks like the user record from notification.action.user is not updated via store for follow notifications. For status notifications, it works fine though. I will have a look.)

Update: tags are fixed via BE MR https://git.pleroma.social/pleroma/pleroma/pulls/4264 > I'd keep moderation button in sidebar, we're gonna put it into dots menu anyway so added complexity of showing/hiding it is bad. So, eventually, the moderation menu will be accessible via the dots menu in the notifications sidebar? I'd need to make a few changes to the current MR in this case. (Looks like the user record from `notification.action.user` is not updated via store for `follow` notifications. For `status` notifications, it works fine though. I will have a look.)
eugenijm commented 2019-03-03 19:49:48 +00:00
Author
Member
Copy link

Update: fixed the issue with the changes to the user not being propagated for follow notifications in the sidebar: notification.vue, notification.js (enforces the user passed down to user-card-content to be taken from user store. I'm not sure if it's the best way, or we should make sure that notification.action.user refers to the user from store. This change was easier to make and I wasn't sure if it's a good idea to expand the scope of the MR too much.)

There is another issue with menu in the sidebar: the User Delete Dialog appears to be overlapped by the main panel.

This can be fixed in two ways:

  • change sidebar / panel styling (e.g. adding z-index to .sidebar-flexer.mobile-hidden fixes it).
  • or mount modal dialog at root so that it doesn't depend on existing styling (downside is that we need to add additional state to the store).

Both approaches carry additional complexity, which may be bigger than the complexity of hiding the Moderation button. What do you think? Should we have moderation button in the sidebar anyways?

/cc @shpuld @hj

Update: fixed the issue with the changes to the user not being propagated for `follow` notifications in the sidebar: [notification.vue](https://git.pleroma.social/pleroma/pleroma-fe/blob/575476de68741422d7c8885b71ffe78c46c69b16/src/components/notification/notification.vue#L9), [notification.js](https://git.pleroma.social/pleroma/pleroma-fe/blob/575476de68741422d7c8885b71ffe78c46c69b16/src/components/notification/notification.js#L25) (enforces the user passed down to `user-card-content` to be taken from user store. I'm not sure if it's the best way, or we should make sure that `notification.action.user` refers to the user from store. This change was easier to make and I wasn't sure if it's a good idea to expand the scope of the MR too much.) There is another issue with menu in the sidebar: the User Delete Dialog appears to be overlapped by the main panel. This can be fixed in two ways: - change sidebar / panel styling (e.g. adding z-index to `.sidebar-flexer.mobile-hidden` fixes it). - or mount modal dialog at root so that it doesn't depend on existing styling (downside is that we need to add additional state to the store). Both approaches carry additional complexity, which may be bigger than the complexity of hiding the Moderation button. What do you think? Should we have moderation button in the sidebar anyways? /cc @shpuld @hj
eugenijm commented 2019-03-04 18:57:19 +00:00
Author
Member
Copy link

Ping @hj @shpuld

At this point, the question about whether or not to display the Moderation button in the sidebar is only remaining issue. Other than that, the MR is ready for final review

Ping @hj @shpuld At this point, the question about whether or not to display the Moderation button in the sidebar is only remaining issue. Other than that, the MR is ready for final review
hj commented 2019-03-04 19:12:49 +00:00
Owner
Copy link

leave it in there, i don't think it's that bad, and logic to determine if we should display it is an unnecessary complexity imo.

leave it in there, i don't think it's that bad, and logic to determine if we should display it is an unnecessary complexity imo.
eugenijm commented 2019-03-04 19:20:46 +00:00
Author
Member
Copy link

Alright, done

Alright, done
hj commented 2019-03-04 20:04:26 +00:00
Owner
Copy link

add a comment TODO add better color variable pls

add a comment `TODO add better color variable` pls
eugenijm commented 2019-03-04 20:36:29 +00:00
Author
Member
Copy link

Done

Done
maxf commented 2019-03-06 12:05:15 +00:00
Member
Copy link
      store.commit('updateActivationStatus', {user: this.user, status: !this.user.deactivated})
      store.state.api.backendInteractor.setActivationStatus(this.user, !this.user.deactivated)

Instead of branching here?

```suggestion store.commit('updateActivationStatus', {user: this.user, status: !this.user.deactivated}) store.state.api.backendInteractor.setActivationStatus(this.user, !this.user.deactivated) ``` Instead of branching here?
shpuld commented 2019-03-07 16:13:50 +00:00
Owner
Copy link

Should this component be called a DialogModal? just to not confuse it with MediaModal for example, and because it's not a 100% generic one

Should this component be called a DialogModal? just to not confuse it with MediaModal for example, and because it's not a 100% generic one
shpuld commented 2019-03-07 16:15:37 +00:00
Owner
Copy link

No need to use a hard coded color here

No need to use a hard coded color here
shpuld commented 2019-03-07 16:16:11 +00:00
Owner
Copy link

why a fixed width? sounds too wide for mobile too

why a fixed width? sounds too wide for mobile too
shpuld commented 2019-03-07 16:16:56 +00:00
Owner
Copy link

better make it use panel shadow variable I think

better make it use panel shadow variable I think
shpuld commented 2019-03-07 16:18:49 +00:00
Owner
Copy link

What's this for?

What's this for?
eugenijm commented 2019-03-07 16:58:15 +00:00
Author
Member
Copy link

Since I used buttons for menu items (some style elements were similar), it inherited box-shadow which is defined for buttons globally in App.scss . Would it be better to use something else instead of a button to avoid overwriting it? (FWIW updated it to: box-shadow: none;)

Since I used buttons for menu items (some style elements were similar), it inherited `box-shadow` which is defined for buttons globally in [App.scss ](https://git.pleroma.social/pleroma/pleroma-fe/blob/f54eb757398c07954c11875a70c915e5fedd971f/src/App.scss#L68). Would it be better to use something else instead of a button to avoid overwriting it? (FWIW updated it to: `box-shadow: none;`)
hj commented 2019-03-08 00:13:47 +00:00
Owner
Copy link

deja vu. at least add TODO unify with other modals.

this is one of the holy trinity of MRs that add some sort of modals to FE

deja vu. at least add `TODO unify with other modals.` this is one of the holy trinity of MRs that add some sort of modals to FE
hj commented 2019-03-08 00:14:17 +00:00
Owner
Copy link

just 0 is enough

just `0` is enough
hj commented 2019-03-08 00:14:27 +00:00
Owner
Copy link

just one zero is enough

just one zero is enough
hj commented 2019-03-08 00:15:01 +00:00
Owner
Copy link

i'm not sure why you're using div in some places and not the others.

i'm not sure why you're using `div` in some places and not the others.
hj commented 2019-03-08 00:15:57 +00:00
Owner
Copy link

use .5 instead, i already had hellish bugs in chromium related to it rounding stuff inconsistently due to .6 fraction

use `.5` instead, i already had hellish bugs in chromium related to it rounding stuff inconsistently due to `.6` fraction
hj commented 2019-03-08 00:18:30 +00:00
Owner
Copy link

also you don't need to write & .something you can write just .something as far as I can see. You only need ampersand if you want to glue it together.

.a {
  .b {
    rule: value
  }
}

/* becomes */
.a .b { rule: value }

.a {
  & .b {
    rule: value
  }
}

/* becomes */
.a .b { rule: value } /* i.e. same as above */

.a {
  &.b {
    rule: value
  }
}

/* becomes */
.a.b { rule: value } /* no space */

i might be sleepy and wrong tho

also you don't need to write `& .something` you can write just `.something` as far as I can see. You only need ampersand if you want to glue it together. ```scss .a { .b { rule: value } } /* becomes */ .a .b { rule: value } ``` ```scss .a { & .b { rule: value } } /* becomes */ .a .b { rule: value } /* i.e. same as above */ ``` ```scss .a { &.b { rule: value } } /* becomes */ .a.b { rule: value } /* no space */ ``` i might be sleepy and wrong tho
hj commented 2019-03-08 00:22:40 +00:00
Owner
Copy link

make it flexible and adjusting to content automatically. Maybe also add max-width: 100vw for good measure.

labels should properly overflow if there's not enough space. Don't forget that translations might take more (or less) space than English labels.

make it flexible and adjusting to content automatically. Maybe also add `max-width: 100vw` for good measure. labels should properly overflow if there's not enough space. Don't forget that translations might take more (or less) space than English labels.
eugenijm commented 2019-03-08 12:27:19 +00:00
Author
Member
Copy link

Thanks for the info, updated it using this style

Thanks for the info, updated it using this style
eugenijm commented 2019-03-08 12:33:35 +00:00
Author
Member
Copy link

Removed divs for consistency

Removed `div`s for consistency
eugenijm commented 2019-03-08 13:17:49 +00:00
Author
Member
Copy link

Made it adjustable:

Screen_Shot_2019-03-08_at_4.02.48_PM

Screen_Shot_2019-03-08_at_4.00.46_PM

Screen_Shot_2019-03-08_at_4.13.46_PM

(320x568)

Made it adjustable: ![Screen_Shot_2019-03-08_at_4.02.48_PM](/attachments/83e512a0-a947-4b19-a2d7-4a57b04d9d25) ![Screen_Shot_2019-03-08_at_4.00.46_PM](/attachments/60028798-9882-4585-badf-e3a492808ba6) ![Screen_Shot_2019-03-08_at_4.13.46_PM](/attachments/addb88c0-d3d0-4f43-962d-20f40c4c0c23) (320x568)
Screen_Shot_2019-03-08_at_4.02.48_PM.png
600 KiB
Screen_Shot_2019-03-08_at_4.00.46_PM.png
551 KiB
Screen_Shot_2019-03-08_at_4.13.46_PM.png
245 KiB
riking commented 2019-03-08 17:29:28 +00:00
Member
Copy link

Suggestion: The delete-user modal should count up the number of objects this will delete.

Delete Account

You are about to delete the account @TerribleSpammer@pleroma.example.com, including 2 posts and 501 follow records.

Delete / Cancel

This allows admins to check themselves before they wreck the wrong person's day.

Suggestion: The delete-user modal should count up the number of objects this will delete. >### Delete Account > >You are about to delete the account **@TerribleSpammer@pleroma.example.com**, including **2** posts and **501** follow records. > >Delete / Cancel This allows admins to check themselves before they wreck the wrong person's day.
kaniini commented 2019-03-14 02:00:03 +00:00
Member
Copy link

Can this go in before we tag 0.9.9999?

Can this go in before we tag 0.9.9999?
hj commented 2019-03-14 19:53:52 +00:00
Owner
Copy link

no need for &

no need for `&`
hj commented 2019-03-14 20:02:28 +00:00
Owner
Copy link

are you sure you even need name? I feel like you always only need screen_name
image

are you sure you even need `name`? I feel like you always only need `screen_name` ![image](/attachments/82e1076f-7068-40c9-8ee4-7f9675972b02)
image.png
33 KiB
eugenijm commented 2019-03-14 20:05:48 +00:00
Author
Member
Copy link

Good point, removed that comment

Good point, removed that comment
hj commented 2019-03-14 20:11:20 +00:00
Owner
Copy link

should be using background-color: transparent or something, looks bad on transparent themes
image

should be using `background-color: transparent` or something, looks bad on transparent themes ![image](/attachments/1a2f7157-6c82-4b95-af66-58c703ad3272)
image.png
34 KiB
hj commented 2019-03-14 20:12:42 +00:00
Owner
Copy link

looks bad on breezy themes, but you can just leave a // TODO there

looks bad on breezy themes, but you can just leave a `// TODO` there
eugenijm commented 2019-03-14 20:17:03 +00:00
Author
Member
Copy link

Sure

Sure
hj commented 2019-03-14 20:18:33 +00:00
Owner
Copy link

По моему "Управление" выглядит ну очень непонятно. Может "Опции модератора"?

Где опция упырить мел :DDDDDDDDDDDDDDD

По моему "Управление" выглядит ну очень непонятно. Может "Опции модератора"? ~~Где опция упырить мел :DDDDDDDDDDDDDDD~~
hj commented 2019-03-14 20:30:03 +00:00
Owner
Copy link

no need for .json as far as i can see

no need for `.json` as far as i can see
hj commented 2019-03-14 20:31:42 +00:00
Owner
Copy link

you don't need to remove the comment, you need to fix other endpoints that are using name instead of screen_name. it doesn't work.

you don't need to remove the comment, you need to fix other endpoints that are using `name` instead of `screen_name`. it doesn't work.
eugenijm commented 2019-03-14 20:31:57 +00:00
Author
Member
Copy link

IIRC it was needed for remote users because parser was confused by a dot in the instance name and treated it as extension. Let me double check though

IIRC it was needed for remote users because parser was confused by a dot in the instance name and treated it as extension. Let me double check though
hj commented 2019-03-14 20:32:17 +00:00
Owner
Copy link
    put("/activation_status/:nickname", AdminAPIController, :set_activation_status)
```elixir put("/activation_status/:nickname", AdminAPIController, :set_activation_status) ```
hj commented 2019-03-14 20:32:35 +00:00
Owner
Copy link

at least in my current local copy

at least in my current local copy
hj commented 2019-03-14 20:32:49 +00:00
Owner
Copy link

also i got error when i tried to deactivate someone

also i got error when i tried to deactivate someone
hj commented 2019-03-14 20:33:51 +00:00
Owner
Copy link

API calls do not check respond status so if user got moderation rights revoked, it will look like their action have an effect but in reality there's 403 everywhere but not reported to UI.

API calls do not check respond status so if user got moderation rights revoked, it will look like their action have an effect but in reality there's 403 everywhere but not reported to UI.
eugenijm commented 2019-03-14 20:37:49 +00:00
Author
Member
Copy link

Oh, will fix that. Additionally, we can also broadcast right updates?

Oh, will fix that. Additionally, we can also broadcast right updates?
eugenijm commented 2019-03-14 20:43:30 +00:00
Author
Member
Copy link

Confirmed, backend requires .json in order to work with remote users. (Removed it and got 406 when trying to deactivate one)

Confirmed, backend requires `.json` in order to work with remote users. (Removed it and got 406 when trying to deactivate one)
eugenijm commented 2019-03-14 20:54:09 +00:00
Author
Member
Copy link

Done

Done
hj commented 2019-03-14 21:09:02 +00:00
Owner
Copy link

ok, will write that off as me having outdated backend

ok, will write that off as me having outdated backend
hj commented 2019-03-14 21:14:37 +00:00
Owner
Copy link

image

![image](/attachments/d09de53f-1949-4d3c-992b-29e8a29598be)
image.png
894 KiB
kaniini commented 2019-03-14 21:17:32 +00:00
Member
Copy link

Deploying newest version of this to pleroma.site.

Deploying newest version of this to pleroma.site.
eugenijm commented 2019-03-14 21:21:02 +00:00
Author
Member
Copy link

also i got error when i tried to deactivate someone

FWIW I'm getting a 502 error from local FE dev server [HPM] Error occurred while trying to proxy request /api/pleroma/admin/activation_status/testuser.json from localhost:8080 to http://localhost:4000/ (HPE_INVALID_CONSTANT) (https://nodejs.org/api/errors.html#errors_common_system_errors).

BE sends 204 according to logs and it does update the activation status as expected though.

> also i got error when i tried to deactivate someone FWIW I'm getting a 502 error from local FE dev server `[HPM] Error occurred while trying to proxy request /api/pleroma/admin/activation_status/testuser.json from localhost:8080 to http://localhost:4000/ (HPE_INVALID_CONSTANT) (https://nodejs.org/api/errors.html#errors_common_system_errors)`. BE sends 204 according to logs and it does update the activation status as expected though.
hj commented 2019-03-14 21:28:49 +00:00
Owner
Copy link

yeah that's what i got

yeah that's what i got
eugenijm commented 2019-03-14 21:30:07 +00:00
Author
Member
Copy link

Updated the backend so that it returns 200 instead of 204 and it fixed it. Not sure why it couldn't proxy 204 though

Updated the backend so that it returns 200 instead of 204 and it fixed it. Not sure why it couldn't proxy 204 though
eugenijm commented 2019-03-14 22:02:11 +00:00
Author
Member
Copy link

Disabled optimistic updates. Now it will update the UI only after successful response. Should the errors be reported somehow?

Disabled optimistic updates. Now it will update the UI only after successful response. Should the errors be reported somehow?
hj commented 2019-03-14 22:09:11 +00:00
Owner
Copy link

image

![image](/attachments/ce71280d-96b9-49a7-adca-d667d6dd649c)
image.png
811 KiB
eugenijm commented 2019-03-14 22:20:13 +00:00
Author
Member
Copy link

Any preferences on how to display the authorization errors?

Any preferences on how to display the authorization errors?
hj commented 2019-03-14 22:44:06 +00:00
Owner
Copy link

no idea at the time, sorry. show a modal? overlay over moderation menu? Can't think of good solution right now.

no idea at the time, sorry. show a modal? overlay over moderation menu? Can't think of good solution right now.
eugenijm commented 2019-03-15 07:10:39 +00:00
Author
Member
Copy link

What about broadcasting user-related events to update the UI accordingly and hide the moderation button? This also allows for deactivated / deleted users to be gracefully logged out instead of being left with a non-responsive page.

What about broadcasting user-related events to update the UI accordingly and hide the moderation button? This also allows for deactivated / deleted users to be gracefully logged out instead of being left with a non-responsive page.
hj commented 2019-03-15 08:39:17 +00:00
Owner
Copy link

would be nice too obviously, but not necessary in scope of this mr

would be nice too obviously, but not necessary in scope of this mr
shpuld commented 2019-03-21 15:30:25 +00:00
Owner
Copy link

Should be ready to merge as soon as conflicts are resolved I think?

Should be ready to merge as soon as conflicts are resolved I think?
eugenijm commented 2019-03-22 09:47:11 +00:00
Author
Member
Copy link

Resolved the conflicts and updated the user rights-related logic in accordance with MastoAPI account format #1865/diffs.

Resolved the conflicts and updated the user rights-related logic in accordance with MastoAPI account format https://git.pleroma.social/pleroma/pleroma-fe/pulls/1865/diffs?commit_id=4c8e12f46e6c214cafa54011f8183b6e41fb4d24.
eugenijm commented 2019-03-22 09:49:57 +00:00
Author
Member
Copy link

Note, the current BE MastoAPI implementation includes is_admin and is_moderator under pleroma object regardless of the user's role visibility preferences (show_role). That would need to be updated on BE.

Note, the current BE MastoAPI implementation includes `is_admin` and `is_moderator` under `pleroma` object regardless of the user's role visibility preferences (`show_role`). That would need to be updated on BE.
feld commented 2019-03-24 15:09:38 +00:00
Owner
Copy link

I'm not sure that's feasible as things like the AdminFE rely on that visibility to check if a user is an admin before attempting to log them in. Otherwise the login would work but queries to Admin API would fail and it would be a mess...

edit: of course I suppose it could be visible to self after authenticating ... that could work

I'm not sure that's feasible as things like the AdminFE rely on that visibility to check if a user is an admin before attempting to log them in. Otherwise the login would work but queries to Admin API would fail and it would be a mess... edit: of course I suppose it could be visible to self after authenticating ... that could work
eugenijm commented 2019-03-25 05:11:07 +00:00
Author
Member
Copy link

Yeah, I thought to make it visible to self and other admins. For not-authenticated or non-superusers, to make it visible depending on the user's show_role preference. Otherwise, I guess it would be better to remove that setting from the UI.

Yeah, I thought to make it visible to self and other admins. For not-authenticated or non-superusers, to make it visible depending on the user's `show_role` preference. Otherwise, I guess it would be better to remove that setting from the UI.
succfemboi commented 2019-03-30 09:57:37 +00:00
Member
Copy link

Could there also be some moderation tools for normal users as well?
I would also want to have images hidden from a user without needing to block or mute

Could there also be some moderation tools for normal users as well? I would also want to have images hidden from a user without needing to block or mute

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
BE Request

   
Backlog

   
Better behavior

   
Blocked by deps

   
Bug

   
Code Review

   
Discussion

   
Doing

   
Feature Request / Enhancement

   
In the shining bright future maybe

   
It's complicated

   
MS Edge

   
Mememoon (or other niche browsers)

   
Missing API

   
Missing feature

   
Missing l10n/i18n

   
NL1

Instance Admin Dashboard

  
NL2

Improved Mobile Experience

  
NL4

Improved instance customization and QoL options

  
Need to verify on develop

   
RELEASE BLOCKER

   
Reassign or Close

   
Refactor

   
Regression

   
Safari

   
To Do

   
User story

   
Waiting on godot

   
accessibility

https://git.pleroma.social/pleroma/pleroma-fe/-/snippets/7746

  
better documentation

   
chore

   
confirmed

   
easy ticket

   
incident

Denotes a disruption to IT services and the associated issues require immediate attention

  
l10n update

   
mastoapi

   
mobile

   
needs design

   
needs-info

   
needs-review

   
stupid
No labels
BE Request
Backlog
Better behavior
Blocked by deps
Bug
Code Review
Discussion
Doing
Feature Request / Enhancement
In the shining bright future maybe
It's complicated
MS Edge
Mememoon (or other niche browsers)
Missing API
Missing feature
Missing l10n/i18n
NL1
NL2
NL4
Need to verify on develop
RELEASE BLOCKER
Reassign or Close
Refactor
Regression
Safari
To Do
User story
Waiting on godot
accessibility
better documentation
chore
confirmed
easy ticket
incident
l10n update
mastoapi
mobile
needs design
needs-info
needs-review
stupid
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
8 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe!1865
No description provided.