![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
(no subject)
I'm working on a bug (well, a trio of bugs) that, I will admit, are not open beta blockers -- which also means I'm not going to pout (too much *G*) if the questions don't get answered immediately -- but I've gotten to a place where I can't totally proceed on my own.
So I'm working on giving community maintainers more toys to play with when editing entries (other than their own). At this point, I have a) edited bin/upgrading/proplists.dat to add entry logprops for the various actions, and b) edited cgi-bin/weblib.pl tp provide an interface. (And editjournal.bml to pass in the appropriate props.) The logprops save fine.
Problem is, I am stuck at c) making those options do what they want to do. Since that's usually the point :)
Specifically, my issues are these:
* maintainer-defined security. I found sub visible_to in cgi-bin/LJ/Entry.pm (line 830), but that is only a binary 1/0; changes will affect who can see the entry, but not how it shows up (i.e. it'll look like a public entry even though it's not behaving like one). Where is the rest of the this-entry-is-friends-only type logic?
* security continuied: for sub_visible, and/or for wherever else that needs poking with a stick, I can change it from using the actual security to using a local variable that initially is actual security but, if the entry is in a community and if the relevant prop is set, switch to the maintainer-defined security instead; I don't know if that's the best way to do it. (Maybe just my $security = $maintainerdefined ? $maintainerdefined : $userdefined - but dunno.) or is it sub security (294) that I should change?
* maintainer-defined lj-cut. Do I want to poke around with one or all of the event-* subs (event_html and following subs) by something like $event="$event"? or do I do something in LJ::CleanHTML instead?
* similarly I want to add a [$action added by maintainer] thing at the end of the entry. it would basically be the same sort of thing as the lj-cut: not in the text of the entry itself. but as a thing that gets added between grabbing the entry from the database and displaying it wherever. (and yes, I use the word thing too much. :D ) But I don't know how/where to do this.
* maintainer-defined comment disabling. dunno where that logic is. 'fu says it's spread around in various locations, and suggests making a method to check for comments being disabled (either by user or maintainer), and replace various sorts of $blah->prop( 'opt_nocomments' ) with calls to that function. Would that work?
* the adult content flag/reason, which I'm using as a model, has separate functions for determining what the flag is and who it was set by. which I can model for the above options but I don't know if I should. or can. or... did I mention I'm kind of in over my head? *sheepish look*
(I know y'all can't spare time for extensive handholding right now, but any pointers would be helpful. <3 )
So I'm working on giving community maintainers more toys to play with when editing entries (other than their own). At this point, I have a) edited bin/upgrading/proplists.dat to add entry logprops for the various actions, and b) edited cgi-bin/weblib.pl tp provide an interface. (And editjournal.bml to pass in the appropriate props.) The logprops save fine.
Problem is, I am stuck at c) making those options do what they want to do. Since that's usually the point :)
Specifically, my issues are these:
* maintainer-defined security. I found sub visible_to in cgi-bin/LJ/Entry.pm (line 830), but that is only a binary 1/0; changes will affect who can see the entry, but not how it shows up (i.e. it'll look like a public entry even though it's not behaving like one). Where is the rest of the this-entry-is-friends-only type logic?
* security continuied: for sub_visible, and/or for wherever else that needs poking with a stick, I can change it from using the actual security to using a local variable that initially is actual security but, if the entry is in a community and if the relevant prop is set, switch to the maintainer-defined security instead; I don't know if that's the best way to do it. (Maybe just my $security = $maintainerdefined ? $maintainerdefined : $userdefined - but dunno.) or is it sub security (294) that I should change?
* maintainer-defined lj-cut. Do I want to poke around with one or all of the event-* subs (event_html and following subs) by something like $event="$event"? or do I do something in LJ::CleanHTML instead?
* similarly I want to add a [$action added by maintainer] thing at the end of the entry. it would basically be the same sort of thing as the lj-cut: not in the text of the entry itself. but as a thing that gets added between grabbing the entry from the database and displaying it wherever. (and yes, I use the word thing too much. :D ) But I don't know how/where to do this.
* maintainer-defined comment disabling. dunno where that logic is. 'fu says it's spread around in various locations, and suggests making a method to check for comments being disabled (either by user or maintainer), and replace various sorts of $blah->prop( 'opt_nocomments' ) with calls to that function. Would that work?
* the adult content flag/reason, which I'm using as a model, has separate functions for determining what the flag is and who it was set by. which I can model for the above options but I don't know if I should. or can. or... did I mention I'm kind of in over my head? *sheepish look*
(I know y'all can't spare time for extensive handholding right now, but any pointers would be helpful. <3 )
no subject
no subject
* security continuied:
Yeah, try LJ::Entry::security -- that should do all the required "magic", even in visible_to (But DW probably has calls to other weird obscure things)
* maintainer-defined lj-cut.
* similarly I want to add a [$action added by maintainer] thing at the end of the entry.
I would base both on how the adult "lj-cut" is inserted (DW::Logic::AdultContent::transform_post).
* maintainer-defined comment disabling.
That should be reasonable.
* the adult content flag/reason, which I'm using as a model, has separate functions for determining what the flag is and who it was set by.
It's really a good idea to not access props directly (except from one place)
See what you'll have to do with comment disabling -- we want to avoid future devs having to do that.
This enough of a start for you?