Expected behavior for publish method with lists and nested sets

Showing 1-34 of 34 messages
Expected behavior for publish method with lists and nested sets Elin 12/29/11 5:22 PM
As people who follow the tracker know, recently we have been doing a lot of difficult work on nested tables. We did find a couple of platform bugs that solve some of these issues, but I think there are still more there. 
This post is about one of them. If we could document expected behavior I think we can be that much closer to not constantly responding to issue reports where people expect a different behavior and then switching back and forth. It's a platform issue as well, since much of this is controlled by the JTableNested class, but the platform is just a tool for the CMS and if the CMS wants something different there is no reason it can't have it.

Note: this post is only about changes in state, not about deletion.

Situation:
When we are in the backend grids Menus and Categories for tables that extend JTableNested I think we need to set and stick to a specification of behavior in the publish method when multiple items are selected. 
On the whole this is the pattern that currently exists.

1. Pick an item with no children. Change state (i.e. click publish, unpublish, trash and archive in categories), that item will change to the new state.
2. Pick an item with children. Change state (i.e. click publish, unpublish, trash and archive in categories), that item and all of its children will change to the new state.
3. Pick an item and one of  its children (or grandchildren etc) and only the selected items will be changed to the new state (other children/descendants do not change).

You can see examples of the three scenarios by going to the contact categories view and trying:

1. Select Uncategorised and change state.
2. Select Shop Site and change state.
3. Select Shop Site and Staff (a child) and/or Shop Site and A (a grandchild).


I can see valid arguments for the behavior in #3 being as it is and for #3 being wrong (that is since Shop Site is selected everything under it should be changed),   I could also see an argument that behavior #2 is wrong and should behave more like 3.  From my perspective, either way is fine as long as it is documented and behaves consistently across all user interfaces and JBS doesn't spend time debating it every couple of months.

I do wonder i in the case of behavior #2 it wouldn't make sense for the UI to automatically place check marks in the boxes for all items that are going to be changed. We had a big discussion about that when it came to menu assignment ALL for modules and I do think it is more understandable with all of them being checked in the UI.


Thoughts?

Elin
Re: Expected behavior for publish method with lists and nested sets Kevin 12/29/11 8:35 PM
My two pennith ...

"2. Pick an item with children. Change state (i.e. click publish, unpublish, trash and archive in categories), that item and all of its children will change to the new state."

With that option yes the children would also automatically receive a check mark.  The user could deselect any(or all) of the children if they then so desire ?
Would seem correct. 

But would add to ' (i.e. click publish, unpublish, trash and archive in categories)' 'Empty trash' as well ?



Re: [jbs] Re: Expected behavior for publish method with lists and nested sets Samuel Moffatt 12/29/11 10:37 PM
My suggestion is by default changing the state using the list select
options should only change those items selected. Changing the
individual item should only change the individual item. If a batch
change state is required, then this should be another batch operation
(change state of this item and all children) through our existing
batch UI at the bottom (though it is slightly different behaviour,
nothing that can't be reasonably explained).

This provides you with the ability to individually change selected
items without accidentally resetting the state of all of it's children
(#3; personally my preferred option) while also providing you with an
option to change the current items state and all of its children in a
single operation (#2).

Personally #2 scares me, I can just imagine a large site accidentally
unpublishing then republishing a single root and then all deleted,
draft or archived items magically being reset…manually changing that
back would be a PITA and you'd want to restore from backups but even
then…risky!). By shifting where it is in the UI and the metaphor you
can have a "change state for selected items to <state dropdown> and
for all children up to <levels> deep." Where levels is none (default),
all, then 1 through n levels. Or it could much simpler (current item
and direct children, current item and grand children, current item and
all children).

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! bug Squad" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/joomlabugsquad/-/E6Y75FATk8gJ.
>
> To post to this group, send email to joomlab...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsqua...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.

RE: [jbs] usage of @$ to hide messages rgjoyce 12/30/11 1:27 AM
Not sure if it's worth mentioning or not.... But.
Two of my senior developers mentioned to me today that they're seeing a lot
of developers starting to prefix their variables, functions and arrays with
the @ symbol to hide messages.
Eg: echo @$myvar['xyz'];
If this isn't set, then it will display a notice.

They tell me that this will also suppress warnings and fatal errors, which I
don't think is a very good idea.

I just wonder if this is in the joomla conding standards. There are 133
files using this in 2.5.0b1

Rob

Re: [jbs] usage of @$ to hide messages Samuel Moffatt 12/30/11 1:36 AM
It depends.

So if it's in front of a variable in Joomla! then it's likely a
laziness thing more than anything and probably needs to be reviewed.
There are however points where putting it in front of a variable is a
legitimate use case, particularly for internal PHP functions. Many
internal PHP functions have this annoying "feature" of returning FALSE
in an error case (yay!) and then also spitting out a notice as well
(not so yay). The problem of course is if you don't have error
reporting disabled, this notice then becomes potentially part of an
information disclosure vulnerability. There's no efficient way of
disabling this functionality either that works consistently across all
environments (particularly those that enable all of the features to
disable everything else!).

A great example of this was for me today writing a library which
wrappers OpenSSL. There are particular ways you can call the various
OpenSSL functions where it will gleefully spit out a notice if the
variables are incorrect. Unfortunately displaying an error to the end
user that the IV length is insufficient is next to useless
programatically however I did validate the return value. In that
particular case I could attempt to duplicate what ever error checking
OpenSSL is doing, or I can just let OpenSSL do what it does best and
if it returns an error code I communicate that back up. However to
prevent it from spamming out these mostly useless messages for anyone
but me in a way that I know will work across platforms safely, I've
got to use the error suppression operator. JFile/JFolder live in a
similar situation as well.

Certainly there are times when it's bad (at the top of an execution
chain that loads plenty more PHP), however generally when it's applied
individually to PHP internal functions it should be a reasonable use.

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
> To post to this group, send email to joomlab...@googlegroups.com.
> To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.
>

RE: [jbs] usage of @$ to hide messages rgjoyce 12/30/11 1:41 AM
Well a further problem can be if you're using it to prefix function names so
that you don't see errors they return.
You can be supressing fatal errors too. Eg: if you mistype the function
name, you'll never see it.
Re: [jbs] usage of @$ to hide messages Samuel Moffatt 12/30/11 1:45 AM
The rest of your code stops running after a fatal error as well,
usually easy to notice that your site stops rendering after you just
wrote some code and hit refresh. However the chances that code written
in Joomla! has a mistyped function behind an error suppression
operator and has survived this long seems unlikely. Not to mention
hard to do while developing.

Cheers,

Sam Moffatt
http://pasamio.id.au

Re: [jbs] usage of @$ to hide messages Kevin 12/30/11 6:30 AM
If a folder on a computer is moved or deleted then all the subfolders are moved/deleted as well. 
  1. Why should Categories with their subfolders(children) be treated differently ?
  2. If a parent is Trashed but not any of it's children then what happens to the child items ?  Do they automatically get assigned to another parent ?
  3. Surely if a user creates a hierarchical structure then that structure should be treated/manipulated as a unit ?
  4. If a child item is not to be moved/deleted/trashed with the parent then why should a user make it a dependent of the parent in the first place ?
Re: usage of @$ to hide messages James Brice 12/30/11 8:04 AM
Another contribution of two pennith ...  (c) Kevin acknowledged.

Hmmm - there are a number of deep-rooted issues that make this one
difficult to solve in a clean and satisfactory manner without making
some significant changes to the way Joomla works.
Firstly there is the one seriously over-worked property that defines
published/unpublished/archive/trashed. Perhaps there should be at
least two properties to choose for each category (and maybe content
items also?) - e.g. published/unpublished and normal/trashed/archived.
Or should that be three: published/unpublished, trashed/available and
current/archived?
Using this sort of property pattern would make it possible to archive
or trash a branch of categories and recover them (if - say - done so
by mistake) with the pattern of publication status intact.

Secondly Joomla could employ employ inheritance to great effect - e.g.
category publication status could be published/unpublished/inherited -
and this would do away with the decision as to whether subordinate
categories should change status when the parent status is changed.
Make the default publication state "inherited" and let the site
administrator choose by over-riding this to published/unpublished
wherever he/she wished. As Kevin points out, it only makes sense to
trash or archive complete branches of categories.

Wouldn't it also be nice to have available the option of inherited
menu item properties in place of having to rely on global or tedious
individual item settings?

James B.
Re: [jbs] usage of @$ to hide messages Samuel Moffatt 12/30/11 3:58 PM
On Fri, Dec 30, 2011 at 6:30 AM, Kevin <in...@weblinksonline.co.uk> wrote:
> If a folder on a computer is moved or deleted then all the subfolders are
> moved/deleted as well.

So there are two things at play here. Moving isn't so much a problem,
however deleting is a problem. However deleting itself is not such a
simple comparison. Issuing a delete call to the underlying file system
and deleting a file in Mac OS X Finder, Windows Explorer or GNOME
Nautilus are two different behaviours. In the first case what actually
ends up happening is the reference to the data is unlinked and the
blocks added to the free map. In the second case the first delete is a
move and the second delete actually triggers the first delete to
occur.

I feel you're confusing these two behaviours. The behaviour of the
data being purged and the behaviour of a GUI in deleting a file and
merely changing where it is linked without realistically changing the
state of anything but the item being "deleted".

>
> Why should Categories with their subfolders(children) be treated differently
> ?

Because our model is different. In a file system, "deleting" a file is
a matter of unlinking it from where it is referenced and marking it's
used blocks as free. In Joomla!, deleting an item changes the state
from either draft, active or archived to deleted - destroying the
previous values.  If using a GUI tool, deleting is merely a move (our
first "delete" operation) that can be reverted - which is much more
similar to our model. You can't reliably do a revert if all of the
children have their state wiped as well. Once you delete it again, the
data is actually purged which is analogous to our methodology - and at
that point the children should be purged as well.

> If a parent is Trashed but not any of it's children then what happens to the
> child items ?  Do they automatically get assigned to another parent ?

They remain with their parent. Someone can reassign them if they wish
but when the parent is in state trashed then all that happens is we
change the state of the category. If at some point you actually delete
it again then I agree the children should be purged as well.

> Surely if a user creates a hierarchical structure then that structure should
> be treated/manipulated as a unit ?

But in a file system, again, they're not necessarily treated as a
unit. The state of a file being deleted is merely where it is linked
or if it is not linked and it's blocks are available.

> If a child item is not to be moved/deleted/trashed with the parent then why
> should a user make it a dependent of the parent in the first place ?

Unless you're purging the item, then changing the state is something
that happens to the individual item level. Changing the state field,
without it being an explicit operation (deleting an item twice, in my
mind, is explicit enough), in a bulk way for their children shouldn't
be the default behaviour.

Cheers,

Sam

Re: [jbs] Re: usage of @$ to hide messages Samuel Moffatt 12/30/11 5:21 PM
On Fri, Dec 30, 2011 at 8:04 AM, James Brice <wsj....@gmail.com> wrote:
> Another contribution of two pennith ...  (c) Kevin acknowledged.
>
> Hmmm - there are a number of deep-rooted issues that make this one
> difficult to solve in a clean and satisfactory manner without making
> some significant changes to the way Joomla works.
> Firstly there is the one seriously over-worked property that defines
> published/unpublished/archive/trashed. Perhaps there should be at
> least two properties to choose for each category (and maybe content
> items also?) - e.g. published/unpublished and normal/trashed/archived.
> Or should that be three: published/unpublished, trashed/available and
> current/archived?

The side effect is that each of these will require an index for the
efficient operation, not to mention a field to store it in. I'm not
entirely opposed to the idea however instead of three fields there are
alternatives (bit mask) that might deliver a much better balance for
power versus performance. Alternatively a more robust but simplistic
workflow system could handle some of this more elegantly as well.

Each solution (including our own), has various pros and cons for
different scenarios. While we can take inspiration from many different
systems we have to understand their design limitations as well as our
own.

> Using this sort of property pattern would make it possible to archive
> or trash a branch of categories and recover them (if - say - done so
> by mistake) with the pattern of publication status intact.
>
> Secondly Joomla could employ employ inheritance to great effect - e.g.
> category publication status could be published/unpublished/inherited -
> and this would do away with the decision as to whether subordinate
> categories should change status when the parent status is changed.
> Make the default publication state "inherited" and let the site
> administrator choose by over-riding this to published/unpublished
> wherever he/she wished. As Kevin points out, it only makes sense to
> trash or archive complete branches of categories.

Having inherited params (versus the much simpler use global) would
require two things to happen:
1) when creating a new child, you calculate the "effective" params and
cache that in the object.
2) when altering a parent, you need to propagate the changes to all children

Otherwise on each access you need to walk up the tree to access the
defaults and merge them all in which is itself an expensive operation
because if you are 10 levels deep, you've got to merge 11 sets of
params (base params + your 9 ancestors + your own) to get the
effective params.

Ideally this would be done when an item is saved or updated but also
could be shifted lazily into the view but in the case of situation 2,
you need a flag to mark that the cached effective params for the item
is stale.

>
> Wouldn't it also be nice to have available the option of inherited
> menu item properties in place of having to rely on global or tedious
> individual item settings?

Sounds good in theory, just need an effective implementation.

Cheers,

Sam Moffatt
http://pasamio.id.au

Re: [jbs] usage of @$ to hide messages Kevin 12/30/11 5:56 PM
@Samuel

That explains a lot, thanks for taking the time to explain.
Re: Expected behavior for publish method with lists and nested sets Elin 12/30/11 8:21 PM
As stated in the initial post, I'm not asking about delete (empty trash).  That's a separate issue--and separate method-- that we also have to resolve but it could possibly be handled with separate logic. Batch processing is also a separate issue. 

My question is specifically about the publish method (which despite its name covers all changes in the state/published field i.e. changing to 2 for archive, 1 for published, 0 for unpublished, -1 for trashed, with a few other possibilities).  

The publish method actually has an argument that allows you to choose to include children or not. Currently we are using #2 most of the time except in the scenario outlines in #3. However, what is confusing it scenario 3.

With that option yes the children would also automatically receive a check mark.  The user could deselect any(or all) of the children if they then so desire ?

We could possibly do that. That is what happens now if click the select all check box (i.e. you can deselect specific items).

Elin
Re: Expected behavior for publish method with lists and nested sets Kevin 12/31/11 7:24 PM
"As stated in the initial post, I'm not asking about delete (empty trash)"

But should not 'empty trash' be consistent 'trashing' an item and its children ? 

Re: [jbs] Re: Expected behavior for publish method with lists and nested sets Samuel Moffatt 12/31/11 10:53 PM
Emptying the trash purges it from the database, trashing an item from
another state merely changes a single field.

You can't recover from purging, you can however recover from a state
change. Inherently the behaviour doesn't necessarily need to be
consistent because it's two different operations - one of which is
reversible and the other not.

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! bug Squad" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/joomlabugsquad/-/xZOdPzaUaUMJ.

>
> To post to this group, send email to joomlab...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsqua...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.

Re: [jbs] Expected behavior for publish method with lists and nested sets oc666 1/1/12 1:44 AM
Hey Elin

This topic raised in few bugs that I fixed.
IMHO, we should change state only for the items are marked.
In addition, we need to offer shortcut for users that want to select item with all the its nested items. Suggestion: double click on item check-box would select the item and its sub-items. What do you say about that?

Thanks
Ofer Cohen


Elin

--
You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
To view this discussion on the web visit https://groups.google.com/d/msg/joomlabugsquad/-/Y-kLhGaBYQ4J.

To post to this group, send email to joomlab...@googlegroups.com.
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.

Re: [jbs] Expected behavior for publish method with lists and nested sets Elin 1/1/12 4:50 AM
Ofer, I think that a short cut is a great idea and then also as Kevin suggested earlier we could let people uncheck specific items.

Kevin, as Sam said, it's a totally different and much more serious thing to actually delete items from the database than is to change one field which can easily be changed back. Technically it's also a separate method. 

In fact experienced users know how to use the trashed state in reorganizing their sites or working on new parts of their sites taking advantage of the fact that the front end will treat anything in a trashed category as trash when it comes to searching and displaying.

Elin
Re: [jbs] Expected behavior for publish method with lists and nested sets Andrea Tarr 1/1/12 5:44 AM
The problem with the double click is that I don't believe there is an accessible alternative for those that don't have a mouse. 

Andrea Tarr

Sent from mobile


--
You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
To view this discussion on the web visit https://groups.google.com/d/msg/joomlabugsquad/-/5qQuZx0MBmoJ.

To post to this group, send email to joomlab...@googlegroups.com.
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.
Re: [jbs] Expected behavior for publish method with lists and nested sets oc666 1/1/12 6:00 AM
Hey Andrea
Thanks for feedback.
Is there accessible shortcut for such behavior? Maybe keyboard shortcut ctrl+space? (space when check-box focused make regular enable/disable)
Thanks
Unsubscribe Farid 1/1/12 6:49 AM
Re: [jbs] Expected behavior for publish method with lists and nested sets Andrea Tarr 1/1/12 7:03 AM
"Clicking" a checkbox isn't a problem, but there isn't a keyboard alternative to Javascript's onDblClick.  So if you are thinking of using different behaviors based on clicking vs. double clicking, that would be a problem.

Andy

Andrea Tarr

Tarr Consulting




Re: [jbs] Unsubscribe betweenbrain 1/1/12 7:38 AM
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.

Best,

Matt Thomas
Founder betweenbrain
Phone: 203.632.9322
Twitter: @betweenbrain




On Sun, Jan 1, 2012 at 9:49 AM, Farid <farid_...@yahoo.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
To post to this group, send email to joomlab...@googlegroups.com.
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.

Re: [jbs] Expected behavior for publish method with lists and nested sets Elin 1/1/12 8:33 AM
So the concept is good but using double click won't work. What WOULD be a good UI for this functionality? Any one have ideas?

Elin
Re: [jbs] Expected behavior for publish method with lists and nested sets oc666 1/1/12 9:21 AM

The regular sequence to triggered check-box is to focus on it and click space.
Would it be convenience to make ctrl+space to select the item and all its  nested items?

Ofer Cohen

On 01/01/2012 06:33 PM, Elin wrote:
So the concept is good but using double click won't work. What WOULD be a good UI for this functionality? Any one have ideas?

Elin
--
You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
To view this discussion on the web visit https://groups.google.com/d/msg/joomlabugsquad/-/t2EhhEiD0EQJ.

To post to this group, send email to joomlab...@googlegroups.com.
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.
Re: [jbs] Expected behavior for publish method with lists and nested sets Elin 1/1/12 9:25 AM
That would work for me.  What do others have to say?

Elin
Re: [jbs] Expected behavior for publish method with lists and nested sets Samuel Moffatt 1/1/12 2:29 PM
What happens if you have a particular max levels set or if all
children are not visible in the list?

Sam Moffatt
http://pasamio.id.au

On Sun, Jan 1, 2012 at 9:25 AM, Elin <elin....@gmail.com> wrote:
> That would work for me.  What do others have to say?
>
> Elin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! bug Squad" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/joomlabugsquad/-/G8nwYlApBY0J.
>
> To post to this group, send email to joomlab...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomlabugsqua...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomlabugsquad?hl=en.

Re: [jbs] Expected behavior for publish method with lists and nested sets oc666 1/1/12 2:39 PM

IMHO, If we are assuming that:

  1. Only that visible items would be available for state changing, and
  2. This select action done on the item and its children items.

It supposed to be available only for the items that visible and unvisible items ignored. Means that unvisible nested items would be ignored.
The selection would be done on client side, so javascript would use simple recursive selection function.

If it's would be confirmed, I'll make a patch to fix this issue.

Ofer Cohen
Re: [jbs] Expected behavior for publish method with lists and nested sets Kevin 1/1/12 6:17 PM
Hi Elin
"Kevin, as Sam said, it's a totally different and much more serious thing to actually delete items from the database than is to change one field which can easily be changed back. Technically it's also a separate method. "

Yes I understand what is being said about the 'mechanics' of what actually happens, but that is not what I meant.  It is my contention that although the data is handled differently .. that the average use will want the same 'keystroke methods' with emptying Trash as with Trashing the item.  I think most of us non-programmers are aware of the difference in that emptying trash is unrecoverable(except by reinstating a backup). 

If all child items are select when Trashing (with the option to be deselected individually) .... then surely the average user will expect the same when emptying the Trash ?  After all the Empty Trash option is only a safe guard against accidental deletion is it not ?  So if the user accidentally Trashes something it can be recovered.  But if they wish to delete it then would they really want to mess around selecting individual items rather than than just selecting the Parent like they did in the first place ?


Re: [jbs] Expected behavior for publish method with lists and nested sets Elin 1/1/12 9:49 PM
I think that's why we're thinking about how to do multiselect usefully. However, if it comes to a choice between having some percentage of users potentially permanently and unexpectedly lose their data and some other users have to handle things in a safer but more annoying way then I go with safety.

Remember too that in this case you are looking at a category screen .. you may not be thinking about the fact that are articles (or whatever) in that category. 

Offer I think that Sam's point about the issue of more subcategories on the next page is a good one to think about, aren't you going to potentially end up with orphan items if you just ignore them? I guess they will just move up? Maybe we could have a message that says there are more children of that haven't been deleted?

Elin
Re: [jbs] Expected behavior for publish method with lists and nested sets oc666 1/2/12 1:22 AM
Hey
Could we popup notice with js like the controller->redirect do?
In addition, for 2.5, IMHO, we require to fix the regular bug - publish 1 selected item with nested items change the state of the sub-items. For 3.0 we'll do the auto-select. 

Thanks
Ofer Cohen

--
You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
To view this discussion on the web visit https://groups.google.com/d/msg/joomlabugsquad/-/SoMnxBA10RwJ.

To post to this group, send email to joomlab...@googlegroups.com.
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.

Re: [jbs] Expected behavior for publish method with lists and nested sets Elin 1/2/12 4:54 AM

A message would be good.
Do you see how scenario 3 is working right now -- how it changes the behavior by just changing the selected items?  
Maybe with a message for the other scenario

Elin
Re: [jbs] Expected behavior for publish method with lists and nested sets oc666 1/2/12 5:53 AM
The third scenario is wrong behavior. For all three scenarios - it should change state only for the selected items no matter if they have child-items or not. This will go for 2.5 and I'll make a patch for the three scenarios.
For 3.0 I'll make a feature of magic selection which include shortcut to select sub-items, and popup if there are sub-items in the next-previous page (maybe with UCM implementation :)


Elin

--
You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
To view this discussion on the web visit https://groups.google.com/d/msg/joomlabugsquad/-/5bM_gmb_r_AJ.

To post to this group, send email to joomlab...@googlegroups.com.
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.

Re: [jbs] Expected behavior for publish method with lists and nested sets Elin 1/2/12 2:50 PM
Scenario 3 is actually the current behavior. 

Elin
Re: [jbs] Expected behavior for publish method with lists and nested sets oc666 1/3/12 4:07 PM

@Elin & JBS,

I've fix all three scenrios. See new patch in the bug tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27499

Some explanations:

I notice why this bug was produce. There is a check before publish, to verify that publish item doesn't have parent item unpublish. Here is the code from publish method in tablenested.php line ~#950):

$query = $this->_db->getQuery(true)->select('n.' . $k)->from($this->_db->quoteName($this->_tbl) . ' AS n')
                    ->where('n.lft < ' . (int) $node->lft)->where('n.rgt > ' . (int) $node->rgt)->where('n.parent_id > 0')
                    ->where('n.published < ' . (int) $compareState);

That's make sense that all sub-items of unpublish item should be unpublish also, and this is the reason the update query took all node and the sub-items (same method, little bit after):
$query = $this->_db->getQuery(true)->update($this->_db->quoteName($this->_tbl))->set('published = ' . (int) $state)
                ->where('(lft > ' . (int) $this->lft . ' AND rgt < ' . (int) $this->rgt . ')' . ' OR ' . $k . ' = ' . (int) $pk);

I've removed all the node left&right arguments from the query and that fixed the problem (in addition of making  publish method consistently in all use cases)

Nevertheless, when parent-item is unpublish and one of its sub-items is unpublish also, user cannot publish the sub-item before publish the parent-item. The next error message raised when doing this action: "Cannot change the published state when the parent menu item is of a lesser state".

Please advise and test the patch

Best Regards,

Ofer Cohen

On 01/03/2012 12:50 AM, Elin wrote:
Scenario 3 is actually the current behavior. 

Elin
--
You received this message because you are subscribed to the Google Groups "Joomla! bug Squad" group.
To view this discussion on the web visit https://groups.google.com/d/msg/joomlabugsquad/-/XBVHlJ5Gpt0J.

To post to this group, send email to joomlab...@googlegroups.com.
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomlabugsquad?hl=en.
More topics »