[MAGNOLIA-581] Incorrect behavior when creating or modifying items and subscription server is down Created: 19/Oct/05  Updated: 23/Jan/13  Resolved: 27/Oct/05

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 2.1.2
Fix Version/s: 2.1.4, 3.0 Beta 1

Type: Bug Priority: Major
Reporter: Karsten Wintermann Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP2, Linux
JDK 1.5.0_04
Jackrabbit/Berkeley DB


Issue Links:
relation
is related to MAGNOLIA-583 Move, Copy and Delete commands should... Closed
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   

When a subscription server is down or not reachable, i can create new folders, content nodes, and node data, but I cannot modify them after that. That means, I can't give them a name (they stay as "untitled") and I can't remove them anymore. Once I set the subscription entry to "active:false", everything works again.

Also, there is no error message generated which hints at the cause of this problem.

For the user, the best solution would be if creating and modifying new entries is possible even when the subscription server is not reachable. I understand however that it's not possible to determine for sure if an entry was activated before. So, when a user tries to add or modify content when the subscription server(s) is/are not reachable, that action should be rejected with an appropriate error message.

I believe this is somehow related to MAGNOLIA-554, but different.



 Comments   
Comment by Philipp Bracher [ 25/Oct/05 ]

the same problem

Comment by Philipp Bracher [ 27/Oct/05 ]

resolved with the general fix: 584

Comment by Philipp Bracher [ 27/Oct/05 ]

sorry: fix 583

Generated at Mon Feb 12 03:18:51 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.