On the holdings table of the bibliographic record detail page, we have a special behaviour: we hide columns if there is no data to display. Indeed we have a lot of column and we want to limit the number of columns displayed. This behaviour conflicts with "Save state": when the columns are hidden the state is modified. If you leave the page and come back, the column will stay hidden, even if the global settings does not have it as hidden and even if the user didn't explicitly hide it. We want to implement something correctly to prevent a conflict with those 2 behaviours, but 24.11.00 is coming and we need a quick fix: here we are going to remove save state for these 2 tables.
Created attachment 174764 [details] [review] Bug 38482: Remove save state for the holdings tables On the holdings table of the bibliographic record detail page, we have a special behaviour: we hide columns if there is no data to display. Indeed we have a lot of column and we want to limit the number of columns displayed. This behaviour conflicts with "Save state": when the columns are hidden the state is modified. If you leave the page and come back, the column will stay hidden, even if the global settings does not have it as hidden and even if the user didn't explicitly hide it. We want to implement something correctly to prevent a conflict with those 2 behaviours, but 24.11.00 is coming and we need a quick fix: here we are going to remove save state for these 2 tables. Test plan: Apply this patch, restart_all Go to the tables settings admin, jump to holdings_table Notice that "Save configuration state on page change" is turned off by default Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item has call number) => "Call number" column is displayed Go to the tables settings admin, jump to holdings_table Turn on "Save configuration state on page change" Go to catalogue/detail.plbiblionumber=1 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is still not displayed This can be considered a bug, that why we are disabling the feature for this table.
It doesn not work for me. Tested in a sandbox and "Save configuration state on page change" is still turned on by default
Created attachment 174784 [details] [review] Bug 38482: Remove save state for the holdings tables On the holdings table of the bibliographic record detail page, we have a special behaviour: we hide columns if there is no data to display. Indeed we have a lot of column and we want to limit the number of columns displayed. This behaviour conflicts with "Save state": when the columns are hidden the state is modified. If you leave the page and come back, the column will stay hidden, even if the global settings does not have it as hidden and even if the user didn't explicitly hide it. We want to implement something correctly to prevent a conflict with those 2 behaviours, but 24.11.00 is coming and we need a quick fix: here we are going to remove save state for these 2 tables. Test plan: Apply this patch, restart_all Go to the tables settings admin, jump to holdings_table Notice that "Save configuration state on page change" is turned off by default Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item has call number) => "Call number" column is displayed Go to the tables settings admin, jump to holdings_table Turn on "Save configuration state on page change" Go to catalogue/detail.plbiblionumber=1 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is still not displayed This can be considered a bug, that why we are disabling the feature for this table. Signed-off-by: joubu <xxx@example.org>
I think this is the right idea for now. Thanks!
Fixed the sandbox with Joubu and testet it. "Save configuration state on page change" is now turned off by default for admin tables settings > holdings_table and otherholdings_table Change status to signed off. Further tests are welcome!
Created attachment 174785 [details] [review] Bug 38482: Remove save state for the holdings tables On the holdings table of the bibliographic record detail page, we have a special behaviour: we hide columns if there is no data to display. Indeed we have a lot of column and we want to limit the number of columns displayed. This behaviour conflicts with "Save state": when the columns are hidden the state is modified. If you leave the page and come back, the column will stay hidden, even if the global settings does not have it as hidden and even if the user didn't explicitly hide it. We want to implement something correctly to prevent a conflict with those 2 behaviours, but 24.11.00 is coming and we need a quick fix: here we are going to remove save state for these 2 tables. Test plan: Apply this patch, restart_all Go to the tables settings admin, jump to holdings_table Notice that "Save configuration state on page change" is turned off by default Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item has call number) => "Call number" column is displayed Go to the tables settings admin, jump to holdings_table Turn on "Save configuration state on page change" Go to catalogue/detail.plbiblionumber=1 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is still not displayed This can be considered a bug, that why we are disabling the feature for this table. Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Created attachment 174786 [details] [review] Bug 38482: Remove save state for the holdings tables On the holdings table of the bibliographic record detail page, we have a special behaviour: we hide columns if there is no data to display. Indeed we have a lot of column and we want to limit the number of columns displayed. This behaviour conflicts with "Save state": when the columns are hidden the state is modified. If you leave the page and come back, the column will stay hidden, even if the global settings does not have it as hidden and even if the user didn't explicitly hide it. We want to implement something correctly to prevent a conflict with those 2 behaviours, but 24.11.00 is coming and we need a quick fix: here we are going to remove save state for these 2 tables. Test plan: Apply this patch, restart_all Go to the tables settings admin, jump to holdings_table Notice that "Save configuration state on page change" is turned off by default Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item has call number) => "Call number" column is displayed Go to the tables settings admin, jump to holdings_table Turn on "Save configuration state on page change" Go to catalogue/detail.plbiblionumber=1 (item does not have call number) => "Call number" column is not displayed Edit the item, set a call number Go to catalogue/detail.plbiblionumber=13 (item does not have call number) => "Call number" column is still not displayed This can be considered a bug, that why we are disabling the feature for this table. Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu> Signed-off-by: PhilipOrr <philip.orr@lmscloud.de>
Created attachment 174791 [details] [review] Bug 38482: Deactivate 'save state' for holdings tables This is too complicated (at least for 24.11.00) to have everything works in all situations. This table has this specific "hide when empty" behaviour which complicated how we deal with/restore the state
Pushed for 24.11! Well done everyone, thank you!