CB Groupjive - [var2_id] not passed through

Hi Kyle,
I have found out now why I have been having so many problems creating my own notifications. [var2_id] does not seem to get passed through IF the asset is longer than groupjive.group.[var2_id] (ie groupjive.group.[var2_id].grouptodo).

Here is the explanation (made it into a video because it was too long to write):

1drv.ms/u/s!Ap2Qzya9x1hVj-l6ZDSeMhgp0TFqaw?e=abf2rc

That way, it will also show >[Groupname] next to posts that have the asset groupjive.group.x.xyz

The asset absolutely can be longer than that. Below is the REGEXP used to validate the asset as a GJ asset.


Next it must pass the type check if a subtype is supplied. So specifically "grouptodo" is a subtype. It's not in the below core subtype list.


This means your asset is not valid for GJ activity parsing. You can use the "custom" subtype to implement your own types. Example as follows.

groupjive.group.[var2_id].custom.todo

That was easy now with the custom subtype. Could I suggest to put it in a documentation somewhere? I hadnt found the documentation and I just spent the morning trying to find a way to get it to work...

A lot of things are undocumented and it's unfortunately entirely due to lack of time and this isn't exactly something anyone would be utilizing right now. Honestly the best documentation at this time is to just ask on the forums if X or Y is doable and how. Hopefully we can finally simplify a lot of things with CB 3.0 as I'm planning to rewrite pretty much all of CB and better utilize Joomla 4 framework.

In addition to that it's kind of temporary as a later release of CB Activity will be restructuring the database so REGEXP asset check won't be needed anymore and activity will always know where it came from regardless of the type of activity. When I implemented Asset it was great for configuration purposes, but it's not very good for storage behavior. If you want to read up on how Asset will be changed you can check out the details in the below ticket.

forge.joomlapolis.com/issues/8009

The plan is to follow a standardize stream schema.

Yeah sorry, I know about the problem with documentation. There is never enough time to program and make the documentation perfect, same here.
Sorry about the wording, I am ready to kick my computer all the way to the moon and beyond in frustration about the bloody website that does not want to work as it should.
Had a look at the streams and the assets, looks good . I hope that migration will work because I can see a lot of problems coming up.
I am using hundreds of different assets, filters and (asset filtered)streams...

I hope that migration will work because I can see a lot of problems coming up.
I am using hundreds of different assets, filters and (asset filtered)streams...

Yup, full migration is planned. Will be testing migration of all core assets in addition to custom cases to be sure it migrates properly. Asset basically needs to be split back up for storage. It'll remain as a parameter though as it's really useful for configuration purposes. I recommend following the below structure where possible.

TARGET.TARGET_ID.VERB.OBJECT.OBJECT_ID

CB GroupJive is a bit of an exception since it has an additional prefix. The below for example would be valid asset structure for new usage.

group.135.create

The target is a group and the target id is 135 with the verb being create. If there is no object then the target is API wise will also be the object. The plan for all GJ assets is to chop off the leading prefix. Specifically the above is created from the below.

groupjive.group.135.create

The leading groupjive part will just go away since we don't need to specify that. Another example is a CB Gallery upload to a group would have something like the below.

groupjive.group.10.gallery.photos.30361

Its asset will be turned in the following based off the new structure.

group.10.photo.30361

In this case target is group, target id is 10, the object is a photo, and the object id is the 30361 (the photos id).

The end result is SQL checks will SIGNIFICANTLY speed up since we know EXACTLY what an activity is and where it's at and since we know what it is at all times parsing out its display becomes trivial and 100% accurate.

So now with the above explained your custom usage would be something like the below.

group.135.todo

That gives a verb of todo, target of group, and target id of 135. This means it will always be aware it belongs to a group. How it displays will depend entirely on the target and the verb. Since there's no hardcoded display code for todo verb it'll display like a regular group post. This means you'll have unlimited usage of verb to supply whatever you like and it will simply just work.