As a developer, I can configure and/or extend content app components to work with non-JCR data sources, so that I can integrate other services into apps easily. (MGNLUI-2569)

[MGNLUI-2760] Streamline availability checking. Created: 19/Mar/14  Updated: 29/Apr/15  Resolved: 27/Mar/14

Status: Closed
Project: Magnolia UI
Component/s: content app, workbench
Affects Version/s: None
Fix Version/s: 5.3

Type: Sub-task Priority: Major
Reporter: Aleksandr Pchelintcev Assignee: Christoph Meier
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-3395 WritePermissionRequiredRule incorrect... Closed
relates to MGNLUI-2778 Create tests for jcr-agnostic-content... Closed
causality
is causing MGNLPN-40 Adapt action availability to new JcrI... Closed
supersession
supersedes MGNLUI-1589 Action availability should operate on... Closed
Template:
Date of First Response:
Sprint: 5.3 Preparation 2, 5.3 Sprint 3, 5.3 Sprint 4

 Description   
  • AvailabilityChecker extracted from ActionExecutor.
  • Item ids instead of javax.jcr.Items
  • Adapt availability rules.


 Comments   
Comment by Magnolia International [ 21/Mar/14 ]

Review of update tasks:

  • Good job on making good task descriptions; task names should be more concise, though ("update availability class names", for example)
  • If you use slf4j, have a static final logger instance. (change your class template in your ide?), e.g.
    private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(RenameContentConnectorPathPropertyTask.class);
    

    instead of

    private Logger log = LoggerFactory.getLogger(getClass());
    
  • Don't catch/log. Rethrow (if you have a RepositoryException you can't treat, you probably should stop the update altogether). And if you need to log something ("hey, we noticed your config is outdated, blablabla"), then do that via InstallContext#warn()/#error()/#info()
  • In ChangeJcrDependentAvailabilityRuleClassesFqcnTask
    } catch (RepositoryException e) {
      log.error("Unable to process app node ", e);
    
    • rethrow or treat.
    • either way, make sure the message is accurate ("unable to process app node", is neither precise nor correct)
  • Couldn't MigrateRuleClassToAvailabilityRuleDefinitionCollectionTask be merged with the above ? They run the same query - i.e operate on all 'availability' nodes.
  • For tasks aren't meant to be re-used by other modules, mark them as such (i.e by not making them public)
  • If MigrateWorkspaceAndPathToContentConnector is meant to be re-used, make it explicit (javadoc?)
    • I'm on the fence regarding that one being reused or doing the job for other modules. Modules will have to update their bootstraps, so they might as well handle their updates. No strong feeling.
Comment by Christoph Meier [ 25/Mar/14 ]

I refactored the Tasks according to comments and added some tests, too.

Comment by Eric Hechinger [ 26/Mar/14 ]

ContentAppModuleVersionHandler calls MigrateJcrPropertiesToContentConnectorTask --> that migrate nodeTypes...

Issue is that ContentAppModuleVersionHandler run before AdmincentralModuleVersionHandler!
There you have update task like (.addTask(new NewPropertyTask("Set main node type in configuration app as strict", "Sets main node type as strict, i.e. its substypes won't be included in list and search views.", RepositoryConstants.CONFIG, "/modules/ui-admincentral/apps/configuration/subApps/browser/workbench/nodeTypes/mainNodeType", "strict", true)))
that try to handle property into this area..

Comment by Christoph Meier [ 27/Mar/14 ]

In order to finish a sprint we will close that ticket.
The migration-issue now is tackled by the follow-up-ticket: => MGNLUI-2775

Generated at Mon Feb 12 08:59:53 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.