Couple Item Questions

[Midnight Modding]

Just a couple more. ?

1. where is the method for displaying moderator permissions for our app in the acp? I was going to see if it's set up in a way where I can easily change which options show up for my app because for 1 content item I have all of the "can" methods return FALSE as it uses a dummy container and then my other content item only uses featuring and unfeaturing basically... and really even then I may just not want mod permissions even for that. For editing/deleting I do my own checks because they're to be done in a different place than moderator panel.

2. Is the built in featuring/unfeaturing only to change the db column, but it's up to us to actually "do" anything with featured content? Once someone marks it as featured, it doesn't really display the content automatically anywhere does it? (edit: I'm not so sure what featuring does. I wonder if it affects using Table\Content or if pinning changes ordering in that as well... I'm getting off of here for the night, so no time to look yet).

Thanks

edit: actually, would omitting $modPerm actually disable them? Or no?
(obviously I could confirm that myself, but not able to right now and also wouldn't know if leaving it out causes any other issue... I actually need a few permissions, possibly, for one content item type)

[Adriano Faria]

3 hours ago, Midnight Modding said:

where is the method for displaying moderator permissions for our app in the acp?

Add the ContentModeratorPermissions extension. It doesn't appear in the extensions list and I always forget to report it as a bug and I end up adding it manually, by copying same extension from Forums app.

@Daniel F can confirm it (doesn't appearing in extensions list)?

3 hours ago, Midnight Modding said:

Is the built in featuring/unfeaturing only to change the db column, but it's up to us to actually "do" anything with featured content? Once someone marks it as featured, it doesn't really display the content automatically anywhere does it?

There's a widget FEED in each app with an option to display featured items. If you're not going to have this widget in your app, then remove the ability to people feature items, since it won't have any effect.

[Daniel F]

Thx, I have fixed this for an upcoming release.

[Midnight Modding]

7 hours ago, Adriano Faria said:

Add the ContentModeratorPermissions extension. It doesn't appear in the extensions list and I always forget to report it as a bug and I end up adding it manually, by copying same extension from Forums app.

@Daniel F can confirm it (doesn't appearing in extensions list)?

There's a widget FEED in each app with an option to display featured items. If you're not going to have this widget in your app, then remove the ability to people feature items, since it won't have any effect.

Thanks

[Midnight Modding]

@Adriano Fariathat extension is only to add permissions, whereas I wanted to remove some. I do see where the permissions are set up in ContentGenerator.php, but I assume that would be an ordeal to override because it's not like overriding something on a content item form, where our own class is already going to be called. It would be calling the existing class only through the links to get to the acp page.

I guess it's no big deal, anyway, but for my personal situation a lot of them need to just always return false. in fact all of them do... as the person doesn't want any of those actions doable on the front end. So there would be permissions set up, yet all returning false, anyway, in the moderator panel. Maybe I should comment out the array set up in the nod model and see if that disables them... but I have a feeling it won't.

[Midnight Modding]

Also, in relation to extensions, I was looking over MemberSync docs and it says data is handled automatically for content items. But when i look in MemberSync\System.php.... there is nothing in there where it's updating our content items. If it does update it, in some other file, I sure hope we can have control over it, because I don't know if it updates the author id to 0 or if it deletes the content, but I do not want their content deleted. My guess is it wouldn't delete it by default, but who knows.

[bfarber]

The admin gets to choose when deleting the member what to do with their content (delete or retain).

It's handled by a background task DeleteOrMoveContent.

[Adriano Faria]

9 hours ago, Midnight Modding said:

that extension is only to add permissions, whereas I wanted to remove some.

In your contente item:

/**
 * File Model
 */
class _File extends \IPS\Content\Item implements
\IPS\Content\Permissions,
\IPS\Content\Tags,
\IPS\Content\Followable,
\IPS\Content\ReadMarkers,
\IPS\Content\Views,
\IPS\Content\Hideable, \IPS\Content\Featurable, \IPS\Content\Pinnable, \IPS\Content\Lockable,
\IPS\Content\Shareable,
\IPS\Content\Searchable,
\IPS\Content\Embeddable,
\IPS\Content\MetaData
{

If you remove, for example:

\IPS\Content\Hideable, \IPS\Content\Featurable, \IPS\Content\Pinnable, \IPS\Content\Lockable,

People won't hide, feature, pin or lock.

[Midnight Modding]

7 hours ago, bfarber said:

The admin gets to choose when deleting the member what to do with their content (delete or retain).

It's handled by a background task DeleteOrMoveContent.

Thanks. There wouldn't be an easy way for me to disallow deleting it as even a choice for my content item, would there? Another of those situations where it would be too big of a chain of changes if I were to try to change that behavior.

I run into real problems because I need it where content items can flat out not be deleted at times. It would still call my delete() though, right? So i could work around it in there, i guess. I guess that is my way around allowing content item deletion when a node is removed, too... but then there would be orphaned content items in that case.

7 hours ago, Adriano Faria said:

In your contente item:

/**
 * File Model
 */
class _File extends \IPS\Content\Item implements
\IPS\Content\Permissions,
\IPS\Content\Tags,
\IPS\Content\Followable,
\IPS\Content\ReadMarkers,
\IPS\Content\Views,
\IPS\Content\Hideable, \IPS\Content\Featurable, \IPS\Content\Pinnable, \IPS\Content\Lockable,
\IPS\Content\Shareable,
\IPS\Content\Searchable,
\IPS\Content\Embeddable,
\IPS\Content\MetaData
{

If you remove, for example:

\IPS\Content\Hideable, \IPS\Content\Featurable, \IPS\Content\Pinnable, \IPS\Content\Lockable,

People won't hide, feature, pin or lock.

yes, I know as far as those. That's why I removed them. But I have a weird situation where I really don't need "any" moderator abilities. No edit, move, delete, etc... So I just have those methods all return false, but of course they are still going to show on the moderator form (I actually have never even looked at the moderator form ever, I think lol). Basically for this item all management is in the acp.

Not a big deal, either way, because the perosn using this app won't ever set to allow moderator permissions, so I guess it doesn't really matter if it's there or not.

[Midnight Modding]

Yeah, I see where that background task calls delete() (I was originally going to say it's for nodes, but I realized even though it's called $node, it's probably not always actual nodes). So i could just do a check in delete() for my content item to disallow it even if it were to be selected on the form. (my app has some unusual situations... it would mess a lot up if the items are deleted when the member is because it's not typical content items).

[bfarber]

You can always just override the delete() method in your content item class and make it ... not delete.

[Midnight Modding]

Interesting you say that and @Aiwa laughs at it/me, considering that's exactly what I posted in my post right above that.

And it's still not an ideal situation, due to needing checks (as I mentioned above), I guess to get the class the call is from (which most recommend against), as obviously deleting is allowed in some situations. Or I could make another class extending my content item class, override delete, let THAT one be my real delete() and have the one in the main content item class always do no deleting.

It's not like I can just make my delete method never delete. It's only some automatic calls to it by ip.suite that I am trying to avoid.

And an even worse situation is the feature allowing deletion of content when a node is deleted. Without overriding practically all of those methods, it would have to just keep having the option on it, while not honoring it. And if I override enough to only give the "move" option, that probably still wouldn't work. (I'll have to look back, but there were a lot of complications). I basically worked around it by just not letting a category be deleted when it has content in it, thus the option not showing up.