I made the header sections above all our settings
panel lists more consistent.
Before this change:
* some lists had titles, others didn't
* the placement of the filter box was random
* alerts strangely went between the filter box
and the list
* filter boxes were too large
* CSS was haphazard
* forms were squished against tables
Now all the settings with list have consistent
HTML, CSS, and look-and-feel in the area directly above
their list of items.
With the exception of Custom Profile Fields, all the
lists with headers above them happen to be based on
ListWidget, but the header styling is not coupled
to ListWidget, because we want consistent headers
even if Custom Profile Fields has a non-ListWidget
list (due to its drag&drop features).
Introduce a new class "table-sticky-headers" in the settings
and organisation settings HTML table tags and it is used
to make the table headers fix at the top. This commit also
add the background-color and hover properties to the
settings and organisation settings table to make them look
similar to the recent_topics_table.
There was a bug where invite users link is shown in the Invitations
section of settings overlay, irrespective if the user is allowed to
invite or not based on the realm settings. So here we just use the
'can_invite_others_to_realm' field of page_params, that was added in
previous commit itself to hide the link accordingly.
Also added the code in server_events_dispatch.js for this field.
Though it doesn't do live update when the overlay is opened similar
to other policies like create_stream_policy, but it ensures that the
visibility of link is correct if the overlay is opened after the
settings has changed.
We should probably do the complete live update in future of the
elements related to such realm settings.
Member of the org can able see list of invitations sent by him/her.
given permission for the member to revoke and resend the invitations
sent by him/her and added tests for test member can revoke and resend
the invitations only sent by him/her.
Fixes#14007.
We already know which list widget a `<th>`
tag is associated with when we set up the
event handler, so it's silly to read data
from the DOM to find that widget again
when the handler runs.
This commit eliminates a whole class of possible
errors and busy work.
Before this fix, we'd get a traceback if you looked
at invites in the settings (and if one of them was
a multi-user invite link). This commit fixes
that problem by adding a custom sort.
We also rename the "Email" column to "Invitee",
since it's often the case the invitee isn't an
actually an email, but it's instead a multi-use
link.
Note that the invites UI only works the first time you
enter settings. Many of the controls break the second
time you enter it. You can't sort by column header
or use the text filter.
I'll fix that in a subsequent commit.
Ganesh Pawar
Steve Howell
Johan Ehinger
akshatdalton
Nikhil Maske
sahil839
jagansivam28
Steve Howell
Thomas Ip
Anders Kaseorg