Adding data item to state restore is breaking "Current Active" state
Adding data item to state restore is breaking "Current Active" state
desperado
Posts: 159Questions: 33Answers: 4
I don't know how to create a good test case for this so I would like to try to describe what I am doing and hope that it makes sense.
I am enhancing StateRestore with an ability to share the states to others by making it "public".
But I don't want public states to be modified by anyone other than the original creator.
I am close to making this work but I am having one issue I can't think of a way to resolve.
To implement this I add the owner of the state to the saved state data using stateSaveParams.
stateSaveParams: function (setting, data) {
data.owner = _currentUser;
}
_currentUser is the login name of the user viewing the page.
I then modified the state buttons by adding an init function to hide the buttons to modify the state if the user is not the owner of the current state being initialized.
function savedStateActionInit(dt, node, config) {
var stateId = config.parent._stateRestore.s.identifier;
if (config.parent._stateRestore.s.savedState.owner != _currentUser) {
node.addClass('hidden-important');
}
}
This all works fine so I am almost successful implementing this feature.
The problem I have is that "Current Active States" thinks the state is not active when the user is NOT the owner.
I think this happens because "Current Active States" logic creates a temp saved state of the current view and compares it to each of the saved states to see which match. Since the temp saved state will have a different "owner" value they will never match. The temp will have the _currentUser as owner but the loaded state shared by someone else will have that person listed as the owner.
Is there a way I tell this logic to ignore the "owner" field when comparing the states to detect if a state is active?
This question has an accepted answers - jump to answer
Answers
I suspect the StateRestore code is doing a full object comparison, so as the name is different, it's not matching. We'll take a look and report back next week, probably towards the end of the week,
Colin
@colin Thanks for the feedback. I suspect same except for the fact that the object contains a time stamp so that would always be different as well so it must at least ignore that part of the json.
This is the json that gets saved by StateRestore made pretty and collapsed to first level elements. You can see the timestamp and my "owner" element.
@colin I was able to implement my change by storing the state/owner in a separate map outside of the StateRestore data so I no longer need solution to this issue.
I am still interested if it is possible to add something to the state restore data without it being used for the active state comparison. If not then no need to implement unless you see it as being useful, if you can already exclude something I would be interested in knowing how for future reference.
Cheers!
We'll see what Sandy says when he's back in. I can see it being useful to have a "don't compare" section of the object, where you can store private information, such as user name or time of change, that isn't used to determine if that state is active. He'll back mid-week so he can give us his insights then
Colin
Hi @desperado ,
You are correct in thinking that StateRestore does remove some properties when doing its comparison such as time. It also removes any "private" property that starts with a "_". So, you could store your info prefixed with an "_".
Hope this helps,
Sandy
@Sandy Thanks that's perfect!