[MGNLSCH-29] Provide uuid parameter in Context Created: 17/Apr/12  Updated: 04/Oct/12  Resolved: 04/Oct/12

Status: Closed
Project: Scheduler
Component/s: None
Affects Version/s: 1.5
Fix Version/s: 1.5.3

Type: Bug Priority: Neutral
Reporter: Federico Grilli Assignee: Milan Divilek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File stacktrace-4.4.txt     Text File stacktrace.txt    
Issue Links:
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

If scheduled job provide parameters repository and path and doesn't provide uuid. Then try get uuid of node and put the parameter to the context.

Strangely this issue (see more in attached stacktraces) concerns only items in the Inbox which were added by a scheduled command, whereas if the inbox item was added by, say, manually activating a page in the website tree, then the error does not occur. Problem is here info.magnolia.module.workflow.inbox.new ListColumn()

{...}

.getValue() at line #172 where the call to

String uuid = "" + this.getListControl().getIteratorValue("uuid");

returns an empty string in case of an inbox item added by a scheduled command



 Comments   
Comment by Jan Haderka [ 25/Jul/12 ]

Can you please add a description of the scheduled job that would reproduce the issue?
Are you sure issue is not caused just by attempt to retrieve version that was already deleted? By default Magnolia keeps floating number of versions, not all of them, but only latest X items so it is possible that if some commands adds versions often enough, old ones would be already wiped out even if associated work item still exists.

Comment by Jan Haderka [ 04/Oct/12 ]

Since we are adding this info to the context, I would not limit it to only (de)activation, but would try to get uuid always. However you should first check if there is no such variable already defined in the context and retrieve and add uuid only if it is not in ctx yet (you would not want to override uuid from configuration in case it was set by user manually).

Generated at Mon Feb 12 10:45:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.