Identifying community administrators in jquery.postform.js

[purplecat]

I've been adding a stickies module to the entry post and edit pages as part of my work on Bug 2152 (multiple stickies). I had this set up so that if the user posts to a community all the sticky options quietly vanished and a little message appeared saying you couldn't sticky entries in communities. Unfortunately, as fu pointed out, administrators can sticky entries in communities.

My problem is I have no idea how to identify a community administrator from jquery.postform.js (which is where I'm controlling this from). Is that possible? If not is there an obvious work around?

If the worst comes to the worst I can always have the message direct people to Organise->Manage Accounts->Display but that wouldn't be optimal.

Comments

[allen]

Is user picking from a list of communities that they have posting access for? If so, you could find the code that generates the list of communities and add a data-administrator='1' to the ones that they're administrators of. Then when they select the community, you can use the jquery data API to check to see if the administrator flag is set on the list element. If it is, they can add stickies, and if not, they can't. (I assume that the backend code will also check for this at submit time, so that nobody does anything hinky.)

(Disclaimer: not looking at the code.)

[purplecat]

IIUC the list is generated from posting_access in Users.pm, but this just generates a list of journals, I'd guess I could iterate through that list in Entry.pm (I think) in order to identify those the user has administrator access to. As I understand matters this list is then passed on to module-journal.tt which jquery.postform.js acts on so I could try to encode the information about administrator access in the drop list in the select form errr... somehow... I dunno maybe in the value somehow or possibly by doing something clever with components - at the moment jquery.postform.js just assumes all journals apart from the first in the list are communities so there isn't any clever information passing there.

Is that what you had in mind.

My concern about that route is that its somewhat convoluted and I'm not entirely clear what the best way to encode the information in module-journal.tt so that jquery.postform.js could pick it up - I'm pretty new to both Template Toolkit and jQuery. Pointers would be welcomed.

[allen]

Yes, that's exactly what I had in mind. :)

So (looking at the code now) Entry.pm loads up @journallist and then it only gets used in module-journal.tt to populate that dropdown. So we have some freedom there. :) Unfortunately, module-journal.tt ends up calling form.select, which means it's calling LJ::html_select(), which is like 500 years old and not very flexible. We'll just make the HTML by hand; it's not that bad in TT.

(Ok, even though I have the code in front of me, I don't have beta features set up so I can't test this. Fingers crossed.)

In Entry.pm, we'll create a more limited hash for @journallist:


my @postables = $u->posting_access_list;
my @journallist;
# add in the user's journal
push @journallist, { label => "", value => $u->user, administrator => 1 };
foreach my $postable ( @postables ) {
push @journallist, { label => $postable->user, value => $postable->user, administrator => $u->can_manage( $postable ) ? "1" : "0" };
}


then in module-journal.tt we replace the section in [%- IF journallist.size > 1 %] to


<select name="usejournal" class="select" id="usejournal>
[% FOREACH journal = journallist %]
<option value="[%- journal.value | html %]" data-administrator="[%- journal.administrator %]">[%- journal.label | html %]</option>
[% END %]
</select>


...which should generate us the same select form as we had before, except we now have data-administrator values for each one. Then we should be able to check the value for the data attribute of the selected option in jquery using something like


var has_admin = $("#usejournal :selected").data("administrator");


And that might work? It's worth a try.

(Hmm, it's possible that you could also leave the current @journallist in Entry.pm and just do the can_manage in the TT, but I feel like this is cleaner...)

[purplecat]

Ooh! Thanks! That certainly looks plausible. I'll give it a try tomorrow.